🪙 Managing tokenized cards

Clear PAN, PSP token, network token: three different things

The PAN (Primary Account Number, 13 to 19 digits) is the number that identifies the card account at the issuer. A compromised PAN opens the door to fraud, and storing it puts the merchant in full PCI DSS scope. Two levels of tokenization can replace it in merchant systems. The PSP token (or acquirer token) is an internal reference generated by the provider. The network token (DPAN) is issued by the card network through its token service provider (TSP), with the issuer's approval. At Visa, the TSP is VTS (Visa Token Service); at Mastercard, it's MDES (Mastercard Digital Enablement Service).

Card-on-file: the stored card

Card-on-file (COF) means storing a payment credential for future use, such as one-click checkout, subscriptions, auto top-up, and merchant wallets. It is the economic foundation of recurring revenue models. In this segment, the quality of tokenization determines the share of charges that fail, and therefore the level of churn.

• Explicit consent at the time of storage (a dedicated checkbox, clear wording), required by network rules on stored credentials;
• The enrollment transaction must be authenticated with SCA (even at €0, as an account verification), because it anchors the subsequent MIT chain;
• Show the customer the stored card (brand + last 4 digits + expiry date) and allow one-click deletion;
• When a card is close to expiry: a proactive banner + account updater, rather than waiting for the charge to fail;
• Store only the token reference on the merchant side, never the PAN, and never the CVV (storing it is prohibited in all cases).

The CIT/MIT framework and mandatory network flagging

Flagging a stored-credential transaction tells the network who triggered it: the cardholder or the merchant. The flag is mandatory on every such transaction. There are two flags. A CIT (Customer-Initiated Transaction) covers cases where the cardholder is present and acting. An MIT (Merchant-Initiated Transaction) covers cases where the merchant acts alone, under a mandate given during an initial, authenticated CIT. The requirement comes from Visa's Stored Credential Framework (2017), later adopted by Mastercard, and then from PSD2. MITs are out of scope for SCA, but only if the flagging chain is correct.

Network chaining links each MIT to the CIT that authorized it. The initial SCA-authenticated CIT returns a network transaction identifier, called the Transaction ID at Visa and the Trace ID at Mastercard. The merchant must store it and reference it in every subsequent MIT, along with the MIT type indicator. That reference proves to the issuer that a mandate exists, which is what justifies skipping SCA on the charge.

{
  "amount": { "value": 1399, "currency": "EUR" },
  "paymentMethod": { "storedPaymentMethodId": "tok_8f3a2b" },  // vaulted token
  "shopperInteraction": "ContAuth",         // cardholder not present
  "recurringProcessingModel": "Subscription",  // MIT type: recurring
  "additionalData": {
    "networkTxReference": "015821943260929" // Transaction ID of the initial CIT
  }
}
// Golden rules:
// 1. The enrollment CIT was authenticated with 3DS (proof of mandate).
// 2. Every MIT references the networkTxReference of the initial CIT.
// 3. No CVV on an MIT (it cannot be stored): this is expected,
//    and the issuer should not penalize it if the flagging is correct.

Account updaters: RTAU, VAU, and ABU

An account updater is a network service that sends the merchant, through its PSP, the new details of a reissued card. When a card is reissued after expiry, loss, theft, or a product change, the stored PANs become obsolete. The networks run update services: VAU (Visa Account Updater) in batch and RTAU (Real-Time Account Updater) in real time at Visa, and ABU (Automatic Billing Updater) at Mastercard. The PSP queries the service overnight for the entire stored base, or on the fly when an authorization would otherwise fail. The vault is then updated.

• New PAN: the card has been reissued; replace the stored credential;
• New expiry date: PAN unchanged; extend;
• Account closed: stop attempts and notify the customer (to avoid billed retries);
• Contact cardholder: the issuer asks the merchant to have the cardholder update the card.

The network token lifecycle

A network token is a stateful object, managed jointly by the TSP, the issuer, and the token requestor: the PSP acting on the merchant's behalf, identified by its TRID (Token Requestor ID). The token moves between states over the life of the underlying card, and the merchant has to process these lifecycle events to keep its vault up to date.

These events arrive through the PSP's lifecycle webhooks/notifications. An integration that ignores them lets suspended or terminated tokens pile up in its vault, and the state change only surfaces when a charge fails. The merchant then ends up in exactly the failure scenario that tokenization was supposed to prevent.

PSP configuration and measured gains

Network tokens are turned on through configuration at the PSP. That covers enrolling the merchant as a token requestor (the PSP usually shares its own TRID across merchants) and choosing the scope by card brand, BIN range, and channel. It also sets the fallback policy to the PAN and the rules for displaying the payment method. The table below summarizes the usual options.