🪙 La gestion des cartes tokenisées

PAN en clair, token PSP, network token : trois objets différents

Le PAN (Primary Account Number, 13-19 chiffres) est le numéro qui identifie le compte de carte chez l'émetteur. Sa compromission ouvre la voie à la fraude, et son stockage impose au commerçant le périmètre PCI DSS complet. Deux niveaux de tokenisation permettent de le remplacer dans les systèmes marchands. Le token PSP (ou token acquéreur) est une référence interne générée par le prestataire. Le network token (DPAN) est émis par le scheme via son TSP, avec l'accord de l'émetteur. Ce TSP est VTS (Visa Token Service) chez Visa, MDES (Mastercard Digital Enablement Service) chez Mastercard.

Card-on-file : la carte enregistrée

Le card-on-file (COF) désigne le stockage d'un credential de paiement pour des usages futurs, tels que le paiement en 1 clic, les abonnements, la recharge automatique et les wallets marchands. Il forme le socle économique des modèles à revenus récurrents. Sur ce segment, la qualité de la tokenisation détermine la part des prélèvements qui échouent, donc le niveau de churn constaté.

• Consentement explicite au moment de l'enregistrement (case dédiée, mention claire), exigé par les règles schemes sur les stored credentials ;
• La transaction d'enrôlement doit être authentifiée SCA (même pour 0 € : account verification), car c'est elle qui fonde la chaîne MIT ultérieure ;
• Afficher au client la carte enregistrée (marque + 4 derniers chiffres + expiration) et permettre la suppression en un clic ;
• Sur carte proche de l'expiration : bannière proactive + account updater, plutôt que d'attendre l'échec du prélèvement ;
• Ne stocker côté marchand que la référence du token, jamais le PAN, jamais le CVV (dont le stockage est interdit dans tous les cas).

Le framework CIT/MIT et le marquage réseau obligatoire

Le marquage d'une transaction sur credential stocké indique au réseau qui a déclenché l'opération, du porteur ou du marchand. Il s'impose à toute transaction de ce type. Deux marquages existent. Le CIT (Customer-Initiated Transaction) couvre le cas où le porteur est présent et agit. Le MIT (Merchant-Initiated Transaction) couvre celui où le marchand déclenche seul, en vertu d'un mandat donné lors d'un CIT initial authentifié. Cette obligation vient du Stored Credential Framework de Visa (2017), repris par Mastercard, puis de la DSP2. Les MIT sont hors du champ de la SCA, mais uniquement si la chaîne de marquage est correcte.

Le chaînage réseau relie chaque MIT au CIT qui l'a autorisé. Le CIT initial, authentifié par SCA, retourne un identifiant de transaction scheme, nommé Transaction ID chez Visa et Trace ID chez Mastercard. Le marchand doit le stocker et le référencer dans chaque MIT ultérieur, avec l'indicateur du type de MIT. Cette référence prouve à l'émetteur l'existence du mandat et justifie de ce fait l'absence de SCA sur le prélèvement.

{
  "amount": { "value": 1399, "currency": "EUR" },
  "paymentMethod": { "storedPaymentMethodId": "tok_8f3a2b" },  // token vaulte
  "shopperInteraction": "ContAuth",         // transaction sans porteur present
  "recurringProcessingModel": "Subscription",  // type de MIT : recurring
  "additionalData": {
    "networkTxReference": "015821943260929" // Transaction ID du CIT initial
  }
}
// Regles d'or :
// 1. Le CIT d'enrolement a ete authentifie 3DS (preuve du mandat).
// 2. Chaque MIT reference le networkTxReference du CIT initial.
// 3. Pas de CVV sur un MIT (il n'est pas stockable) : c'est normal
//    et l'emetteur ne doit pas le penaliser si le marquage est correct.

Account updater : RTAU, VAU et ABU

Un account updater est un service de scheme qui communique au marchand, par l'intermédiaire de son PSP, les nouvelles coordonnées d'une carte réémise. Quand une carte est réémise, à la suite d'une expiration, d'une perte, d'un vol ou d'une migration de gamme, les PAN stockés deviennent obsolètes. Les schemes opèrent des services de mise à jour, VAU (Visa Account Updater) en batch et RTAU (Real-Time Account Updater) en temps réel côté Visa, ainsi que ABU (Automatic Billing Updater) côté Mastercard. Le PSP interroge le service la nuit sur l'ensemble du stock, ou à la volée au moment d'une autorisation qui échouerait. Le vault est ensuite mis à jour.

• Nouveau PAN : la carte a été réémise, remplacer le credential stocké ;
• Nouvelle date d'expiration : PAN inchangé, prolonger ;
• Compte clos : arrêter les tentatives, notifier le client (éviter les retries facturés) ;
• Contact cardholder : l'émetteur demande que le marchand fasse remettre à jour la carte par le porteur.

Cycle de vie du network token

Un network token est un objet à états, géré conjointement par le TSP, l'émetteur et le token requestor. Ce dernier désigne le PSP agissant pour le compte du marchand, identifié par son TRID (Token Requestor ID). Le token passe d'un état à l'autre au fil de la vie de la carte sous-jacente, et le marchand doit traiter ces événements de cycle de vie pour tenir son vault à jour.

Ces événements sont transmis par les webhooks/notifications de cycle de vie du PSP. Une intégration qui ne les traite pas laisse s'accumuler dans son vault des tokens suspendus ou résiliés, et le changement d'état n'apparaît qu'au moment où le prélèvement échoue. Le marchand se retrouve alors dans la situation d'échec que la tokenisation devait précisément prévenir.

Paramétrages côté PSP et gains mesurés

L'activation des network tokens relève d'un paramétrage effectué chez le PSP. Il couvre l'enrôlement du marchand comme token requestor, le PSP mutualisant en général son TRID, ainsi que le choix des périmètres par marque, par BIN range et par canal. Il fixe également la politique de fallback vers le PAN et les règles d'affichage du moyen de paiement. La table qui suit récapitule les options usuelles.