Tokenisation et paiements récurrents. 7 chapitres et un QCM final.

Chapitre 1. Du PAN au network token.

Le PAN (Primary Account Number) est le numéro de carte à 16-19 chiffres imprimé sur le plastique. Stocké tel quel, c'est un actif toxique dont la compromission permet la fraude partout et dont la simple présence dans un système d'information déclenche l'essentiel des exigences PCI DSS. La tokenisation remplace le PAN par un substitut sans valeur intrinsèque hors de son contexte d'usage. Deux familles coexistent, aux propriétés très différentes.

Le token PSP (ou token acquéreur)

Le PSP stocke le PAN dans son coffre-fort (vault) et remet au marchand une référence opaque (par exemple tok_9f2a...). Simple et efficace pour sortir le PAN du SI marchand, mais propriétaire, car le token n'est utilisable que chez le PSP qui l'a émis. Cette exclusivité crée une dépendance (lock-in). Changer de PSP impose une migration de vault, c'est-à-dire l'export conforme PCI des PAN vers le nouveau prestataire. L'opération est lourde et encadrée.

Le network token (token de scheme)

Le network token est émis par le TSP (Token Service Provider) du réseau, VTS (Visa Token Service, lancé en 2014) ou MDES (Mastercard Digital Enablement Service, 2014). Ce numéro adopte le format PAN et « BINne » comme une carte, le mapping vers le PAN réel vivant dans le réseau lui-même, avec l'accord de l'émetteur. Chaque transaction embarque un cryptogramme à usage unique (TAVV chez Visa, équivalent DSRP/UCAF chez Mastercard). Le token est aussi restreint à un domaine d'usage : un marchand, un device ou un canal donné. Volé, il est inutilisable ailleurs.

Chapitre 2. Le flux de tokenisation de bout en bout.

Trois rôles structurent l'écosystème, à commencer par le token requestor, qui demande le token, marchand via son PSP ou wallet comme Apple Pay. Le TSP (VTS/MDES) génère le token, stocke le mapping token↔PAN et gère le cycle de vie. L'émetteur approuve le provisioning et garde la main, avec pouvoir de suspension et de révocation. Le marchand ne voit jamais le PAN après le provisioning initial. Il ne manipule plus que le token.

{
  "network_token": {
    "token_value": "4895370000000000",       // format PAN : "BINne" comme une carte Visa
    "token_expiry": "12/2031",               // decorrele de l'expiration de la carte reelle
    "token_status": "ACTIVE",                // ACTIVE | SUSPENDED | DELETED
    "token_requestor_id": "40010030273",     // identite du demandeur aupres du TSP
    "token_domain": {
      "merchant_scope": "MERCHANT_XYZ",      // restriction : inutilisable ailleurs
      "channel": "ECOM"
    },
    "par": "V0010013022280293102960375319",  // Payment Account Reference : relie tous les
                                             // tokens d'un meme PAN sans exposer celui-ci
    "cryptogram_type": "TAVV"                // cryptogramme a usage unique par transaction
  }
}

Les événements du cycle de vie sont notifiés par le TSP au token requestor. Carte réémise, le token est remappé automatiquement vers le nouveau PAN, sans action du marchand. Compte clos, le token est supprimé ; une opposition le suspend temporairement. L'effet est direct sur le récurrent. Là où un PAN stocké meurt à chaque réémission de carte, le network token survit. L'expiration du token est elle-même distincte de celle de la carte.

Chapitre 3. Card-on-file et framework CIT/MIT.

Le card-on-file (COF) désigne le stockage des identifiants de paiement pour des usages futurs. Les schemes imposent de qualifier chaque transaction. Le framework Visa est devenu obligatoire par paliers entre 2017 et 2020, avec des règles équivalentes chez Mastercard. CIT (Cardholder Initiated Transaction) quand le porteur participe activement à la session, même en un clic sur une carte enregistrée. MIT (Merchant Initiated Transaction) quand le commerçant initie seul, en vertu d'un mandat préalable. Cette qualification conditionne la SCA, puisque les MIT sont hors champ, et gouverne aussi le comportement des émetteurs et la répartition des responsabilités.

Le ciment du framework est le chaînage, la transaction initiale (CIT avec SCA) retournant un identifiant réseau, Transaction ID chez Visa, Trace ID chez Mastercard. Le marchand doit le stocker et le référencer dans chaque MIT ultérieure. Ce lien prouve à l'émetteur qu'un mandat authentifié existe. Une MIT « orpheline » (sans référence valide) est de plus en plus souvent refusée ou soft-declinée.

{
  "amount": 1399,
  "currency": "EUR",
  "payment_method": "ntk_4895370000000000",   // network token stocke (card-on-file)
  "initiator": "merchant",                     // MIT : le porteur n'est pas en session
  "stored_credential": {
    "usage": "subsequent",                     // "first" pour la CIT initiale de mandat
    "reason": "recurring",                     // recurring | installment | unscheduled |
                                               // incremental | delayed | no_show |
                                               // resubmission | reauthorization
    "network_transaction_id": "590123456789012"
    //                          ^ Transaction ID (Visa) / Trace ID (Mastercard)
    //                            retourne par la CIT initiale authentifiee SCA
  }
}

• CIT initiale toujours authentifiée : l'enregistrement de carte ou le premier paiement du mandat passe par 3DS2 (ou un flux 3RI/zero-value avec authentification), et fonde juridiquement toute la chaîne MIT.
• Stocker systématiquement le network transaction ID de l'initiale et de chaque MIT (certains émetteurs attendent le chaînage sur la dernière transaction de la série).
• Recueillir un mandat explicite : montant ou méthode de calcul, fréquence, conditions de résiliation. Exigences schemes et protection consommateur convergent.
• Un one-click est une CIT : le porteur est en session et clique ; il relève de la SCA (avec exemptions possibles), pas du régime MIT.

Chapitre 4. Account updater : garder les cartes fraîches.

Un parc de cartes stockées se dégrade en permanence, entre expirations, réémissions après perte/vol ou compromission, clôtures de comptes et migrations de gamme. De l'ordre de 20 à 30 % des cartes en portefeuille changent chaque année. Sans mécanisme de mise à jour, chaque changement devient un échec de prélèvement, puis un churn involontaire. Les account updaters des schemes synchronisent le vault du PSP avec les référentiels émetteurs.

Trois limites à connaître. Tous les émetteurs ne participent pas aux programmes updater, la couverture étant forte en Europe de l'Ouest et aux États-Unis, inégale ailleurs. Les réponses « compte clos » doivent déclencher une campagne de récupération vers le client, pas un simple retry. L'updater ne corrige pas les échecs pour provision insuffisante. Ce rôle revient au dunning, objet du chapitre suivant.

Chapitre 5. Abonnements et dunning : récupérer les échecs.

Dans l'économie de l'abonnement, le churn involontaire représente couramment 20 à 40 % du churn total. Le client est perdu non parce qu'il résilie, mais parce que son paiement échoue. Le dunning est le processus organisé de relance des paiements échoués : requalification du refus, retries programmés, mise à jour de la carte, communication client. Un bon dunning récupère typiquement 10 à 30 % des échecs. Ce levier de rétention offre souvent le meilleur ROI de toute l'entreprise.

dunning_policy:
  max_attempts: 4                 # au total, bien sous la limite Visa de 15/30 jours
  schedule:
    - attempt: 1
      delay_hours: 24             # J+1 : elimine les indisponibilites transitoires
    - attempt: 2
      delay_days: 3               # J+4
      prefer_day_of_month: [1, 2] # viser le debut de mois (solde reapprovisionne)
    - attempt: 3
      delay_days: 7               # J+11, apres passage account updater
      run_account_updater: true
    - attempt: 4
      delay_days: 10              # J+21, derniere tentative avant suspension
  hard_decline_codes: ["14", "41", "43", "57"]   # arret immediat, aucune tentative
  on_exhaust:
    action: suspend_subscription
    grace_period_days: 7          # acces maintenu le temps de la relance client
  notifications:
    pre_dunning: true             # email J-7 avant expiration de la carte
    each_failure: true            # lien de mise a jour de carte a chaque echec

• Smart retry : les moteurs des grands PSP choisissent par apprentissage le meilleur moment (jour, heure) et le meilleur routage par émetteur, avec des gains de plusieurs points de récupération vs un calendrier fixe.
• Pré-dunning : prévenir le client avant l'échec (carte expirant le mois prochain) coûte un e-mail et évite tout le cycle de relance.
• Mise à jour en libre-service : chaque notification d'échec doit contenir un lien direct de mise à jour de carte (nouvelle CIT authentifiée = nouveau mandat propre).
• Grace period : maintenir le service quelques jours pendant la relance préserve la valeur client ; suspendre brutalement transforme un incident de paiement en résiliation.
• Respect des règles schemes : Visa plafonne à 15 tentatives sur 30 jours glissants pour une même transaction (frais au-delà) ; Mastercard publie des Merchant Advice Codes, et un MAC 03 « do not try again » doit stopper net les retries.

Mesurer : taux de récupération global (échecs finalement encaissés / échecs initiaux), délai moyen de récupération, churn involontaire résiduel, coût complet par euro récupéré (frais de tentatives + updater + remises schemes). Segmenter par code de refus et par émetteur, car les gains se cachent là.

Chapitre 6. One-click, wallets et DPAN.

Le one-click est l'usage CIT du card-on-file, où le client en session choisit sa carte enregistrée et confirme. Il relève donc de la SCA, avec toutes les exemptions du cours 3DS2 (TRA, LVP). S'y ajoute un atout, car un client connu doté d'un historique riche (acctInfo) maximise le frictionless. Amazon a bâti une part de son avance sur cette mécanique, quand network tokens et exemptions TRA offrent aujourd'hui à tout marchand un one-click quasi sans friction.

Wallets : le DPAN et la SCA déléguée

Apple Pay et Google Pay reposent sur la tokenisation réseau, le TSP émettant au provisioning de la carte dans le wallet un DPAN (Device PAN) lié à l'appareil. Il est stocké dans le Secure Element chez Apple, géré via HCE et les serveurs Google côté Android. Le PAN réel (FPAN, Funding PAN) ne transite jamais chez le marchand. Chaque paiement produit un cryptogramme unique, déverrouillé par la biométrie ou le code de l'appareil. Ce CDCVM (Consumer Device Cardholder Verification Method) combine possession (device) et inhérence (biométrie), soit une SCA complète, déléguée au wallet.

Chapitre 7. PCI DSS : réduire le périmètre grâce à la tokenisation.

PCI DSS (Payment Card Industry Data Security Standard) est le référentiel de sécurité imposé par les schemes à toute entité qui stocke, traite ou transmet des données de cartes. La version 4.0 a remplacé la 3.2.1 le 31 mars 2024, la révision 4.0.1 datant de juin 2024. Ses exigences « future-dated » sont devenues obligatoires le 31 mars 2025. Le principe stratégique n'a pas changé. La conformité coûte proportionnellement au périmètre, c'est-à-dire aux systèmes qui touchent aux données carte, si bien que l'objectif d'architecture est de réduire ce périmètre au strict minimum.

• Ne jamais stocker le PAN : déléguer le vault au PSP (token PSP) ou au réseau (network token) fait sortir le stockage du périmètre marchand.
• Champs hébergés / iframe : le PAN saisi par le client part directement chez le PSP sans toucher les serveurs du marchand, condition du SAQ A.
• Tokeniser les flux internes : CRM, service client, anti-fraude et data doivent travailler sur tokens et PAR, jamais sur PAN (même tronqué au-delà du 6+4 autorisé).
• MOTO et call-centers : la saisie téléphonique ramène brutalement en SAQ D ; les solutions de type DTMF masqué ou lien de paiement la font ressortir du périmètre.
• Le token n'est pas une donnée carte : sa compromission n'expose pas le PAN. Toute la valeur de l'architecture tient là, y compris en cas d'incident (obligations de notification réduites).

La tokenisation réduit le périmètre sans l'annuler, puisque le point d'entrée du PAN reste une zone sensible à gouverner (la page ou l'app où le client saisit sa carte, même via iframe). Les processus de migration de vault aussi. L'état de l'art 2026 pour un e-commerçant : champs hébergés + network tokens pour le card-on-file + PAR pour la donnée analytique. Le PAN n'existe alors tout simplement nulle part dans le SI marchand.