Tokenization and recurring payments. 7 chapters and a final quiz.

Chapter 1. From PAN to network token.

The PAN (Primary Account Number) is the 16- to 19-digit card number printed on the plastic. Stored as is, it is a toxic asset: a breach enables fraud anywhere, and its mere presence in a company's systems triggers most PCI DSS requirements. Tokenization replaces the PAN with a substitute that has no intrinsic value outside its context of use. Two families coexist, with very different properties.

The PSP token (or acquirer token)

The PSP stores the PAN in its vault and gives the merchant an opaque reference (for example, tok_9f2a...). It is a simple, effective way to get the PAN out of the merchant's systems, but it is proprietary: the token works only with the PSP that issued it. That exclusivity creates dependency (lock-in). Switching PSPs requires a vault migration, meaning a PCI-compliant export of the PANs to the new provider. It is a heavy, tightly regulated operation.

The network token (scheme token)

Network tokens are issued by the network's TSP (Token Service Provider): VTS (Visa Token Service, launched in 2014) or MDES (Mastercard Digital Enablement Service, 2014). The token uses the PAN format and routes on a BIN like a card, while the mapping to the real PAN lives within the network itself, with the issuer's consent. Each transaction carries a single-use cryptogram (TAVV at Visa, the DSRP/UCAF equivalent at Mastercard). The token is also restricted to a domain of use: a specific merchant, device, or channel. If stolen, it is useless anywhere else.

Chapter 2. The end-to-end tokenization flow.

Three roles shape the ecosystem. First, the token requestor, which requests the token: a merchant through its PSP, or a wallet such as Apple Pay. The TSP (VTS/MDES) generates the token, stores the token-to-PAN mapping, and manages the life cycle. The issuer approves provisioning and stays in control, with the power to suspend and revoke. After the initial provisioning, the merchant never sees the PAN again. It handles only the token.

{
  "network_token": {
    "token_value": "4895370000000000",       // PAN format: "BIN-routed" like a Visa card
    "token_expiry": "12/2031",               // independent of the real card's expiration date
    "token_status": "ACTIVE",                // ACTIVE | SUSPENDED | DELETED
    "token_requestor_id": "40010030273",     // requestor's identity at the TSP
    "token_domain": {
      "merchant_scope": "MERCHANT_XYZ",      // restriction: unusable elsewhere
      "channel": "ECOM"
    },
    "par": "V0010013022280293102960375319",  // Payment Account Reference: links all
                                             // tokens for the same PAN without exposing it
    "cryptogram_type": "TAVV"                // single-use cryptogram per transaction
  }
}

The TSP notifies the token requestor of life cycle events. When a card is reissued, the token is automatically remapped to the new PAN, with no action by the merchant. When the account is closed, the token is deleted; a lost/stolen block suspends it temporarily. The impact on recurring payments is direct. A stored PAN dies with every card reissue, but the network token survives. The token's expiration date is itself separate from the card's.

Chapter 3. Card-on-file and the CIT/MIT framework.

Card-on-file (COF) means storing payment credentials for future use. The schemes require every transaction to be flagged. Visa's framework became mandatory in phases between 2017 and 2020, and Mastercard has equivalent rules. A CIT (Cardholder Initiated Transaction) is one where the cardholder actively takes part in the session, even with a single click on a saved card. An MIT (Merchant Initiated Transaction) is one the merchant initiates alone, under a prior mandate. This flag determines whether SCA applies, since MITs are out of scope, and it also governs issuer behavior and the allocation of liability.

The glue of the framework is chaining: the initial transaction (a CIT with SCA) returns a network identifier, the Transaction ID at Visa or the Trace ID at Mastercard. The merchant must store it and reference it in every subsequent MIT. That link proves to the issuer that an authenticated mandate exists. An “orphan” MIT (with no valid reference) is increasingly declined outright or soft-declined.

{
  "amount": 1399,
  "currency": "EUR",
  "payment_method": "ntk_4895370000000000",   // stored network token (card-on-file)
  "initiator": "merchant",                     // MIT: the cardholder is not in session
  "stored_credential": {
    "usage": "subsequent",                     // "first" for the initial mandate CIT
    "reason": "recurring",                     // recurring | installment | unscheduled |
                                               // incremental | delayed | no_show |
                                               // resubmission | reauthorization
    "network_transaction_id": "590123456789012"
    //                          ^ Transaction ID (Visa) / Trace ID (Mastercard)
    //                            returned by the initial SCA-authenticated CIT
  }
}

• Always authenticate the initial CIT: card enrollment or the first payment under the mandate goes through 3DS2 (or a 3RI/zero-value flow with authentication), and it provides the legal basis for the entire MIT chain.
• Always store the network transaction ID from the initial transaction and from every MIT (some issuers expect chaining to the latest transaction in the series).
• Collect an explicit mandate: amount or calculation method, frequency, cancellation terms. Scheme requirements and consumer protection rules point the same way.
• One-click is a CIT: the cardholder is in session and clicks, so it falls under SCA (with exemptions available), not under the MIT regime.

Chapter 4. Account updater: keeping cards fresh.

A portfolio of stored cards degrades constantly: expirations, reissues after loss, theft, or compromise, account closures, and product changes. Roughly 20 to 30% of stored cards change every year. Without an update mechanism, each change becomes a failed charge, then involuntary churn. The schemes' account updaters sync the PSP's vault with issuer records.

Three limitations to know. Not all issuers participate in updater programs: coverage is strong in Western Europe and the US, and uneven elsewhere. “Account closed” responses should trigger a customer win-back campaign, not a simple retry. And the updater does not fix insufficient-funds failures. That is the job of dunning, covered in the next chapter.

Chapter 5. Subscriptions and dunning: recovering failed payments.

In the subscription economy, involuntary churn commonly accounts for 20 to 40% of total churn. The customer is lost not because they cancel, but because their payment fails. Dunning is the structured process of recovering failed payments: diagnosing the decline, scheduling retries, updating the card, and communicating with the customer. Good dunning typically recovers 10 to 30% of failures. It is often the retention lever with the best ROI in the entire business.

dunning_policy:
  max_attempts: 4                 # in total, well below Visa's limit of 15 per 30 days
  schedule:
    - attempt: 1
      delay_hours: 24             # D+1: rules out temporary outages
    - attempt: 2
      delay_days: 3               # D+4
      prefer_day_of_month: [1, 2] # target the start of the month (balance topped up)
    - attempt: 3
      delay_days: 7               # D+11, after the account updater run
      run_account_updater: true
    - attempt: 4
      delay_days: 10              # D+21, last attempt before suspension
  hard_decline_codes: ["14", "41", "43", "57"]   # immediate stop, no attempt
  on_exhaust:
    action: suspend_subscription
    grace_period_days: 7          # access kept while the customer is contacted
  notifications:
    pre_dunning: true             # email at D-7 before the card expires
    each_failure: true            # card update link with every failure

• Smart retry: the engines at major PSPs use machine learning to pick the best time (day, hour) and the best routing for each issuer, gaining several points of recovery over a fixed schedule.
• Pre-dunning: warning the customer before the failure (a card expiring next month) costs one email and avoids the entire recovery cycle.
• Self-service updates: every failure notification should include a direct link to update the card (a new authenticated CIT means a new, clean mandate).
• Grace period: keeping the service running for a few days during recovery preserves customer value; cutting it off abruptly turns a payment incident into a cancellation.
• Follow scheme rules: Visa caps retries at 15 attempts over a rolling 30 days for the same transaction (with fees beyond that); Mastercard publishes Merchant Advice Codes, and a MAC 03 “do not try again” must stop retries immediately.

Measure: overall recovery rate (failures eventually collected / initial failures), average time to recovery, residual involuntary churn, and fully loaded cost per euro recovered (attempt fees + updater + scheme fees). Segment by decline code and by issuer, because that is where the gains are hidden.

Chapter 6. One-click, wallets, and DPANs.

One-click is the CIT use of card-on-file: the customer, in session, picks a saved card and confirms. It therefore falls under SCA, with all the exemptions covered in the 3DS2 course (TRA, LVP). It has one more advantage: a known customer with a rich history (acctInfo) maximizes the frictionless rate. Amazon built part of its lead on this mechanism; today, network tokens and TRA exemptions give any merchant a near-frictionless one-click.

Wallets: the DPAN and delegated SCA

Apple Pay and Google Pay are built on network tokenization: when a card is provisioned into the wallet, the TSP issues a DPAN (Device PAN) bound to the device. At Apple, it is stored in the Secure Element; on Android, it is managed through HCE and Google's servers. The real PAN (FPAN, Funding PAN) never passes through the merchant. Each payment generates a unique cryptogram, unlocked by the device's biometrics or passcode. This CDCVM (Consumer Device Cardholder Verification Method) combines possession (the device) and inherence (biometrics), which amounts to full SCA delegated to the wallet.

Chapter 7. PCI DSS: reducing scope with tokenization.

PCI DSS (Payment Card Industry Data Security Standard) is the security standard the schemes impose on any entity that stores, processes, or transmits card data. Version 4.0 replaced 3.2.1 on March 31, 2024, and revision 4.0.1 followed in June 2024. Its “future-dated” requirements became mandatory on March 31, 2025. The strategic principle has not changed: compliance costs scale with scope, meaning the systems that touch card data. The architectural goal is therefore to shrink that scope to the bare minimum.

• Never store the PAN: delegating the vault to the PSP (PSP token) or to the network (network token) takes storage out of the merchant's scope.
• Hosted fields / iframe: the PAN the customer enters goes straight to the PSP without touching the merchant's servers, which is the condition for SAQ A.
• Tokenize internal flows: CRM, customer service, fraud, and data teams should work on tokens and PARs, never on PANs (not even truncated beyond the permitted first 6 and last 4 digits).
• MOTO and call centers: taking cards over the phone drops you straight back into SAQ D; solutions such as DTMF masking or payment links take it back out of scope.
• A token is not card data: compromising it does not expose the PAN. That is the whole value of the architecture, including when an incident occurs (lighter notification obligations).

Tokenization shrinks scope without eliminating it, because the PAN's point of entry remains a sensitive area to govern (the page or app where the customer enters their card, even via an iframe). So do vault migration processes. The 2026 state of the art for an online merchant: hosted fields + network tokens for card-on-file + PAR for analytics data. The PAN then simply does not exist anywhere in the merchant's systems.