Payment Tokenization
How real card numbers (FPAN) are replaced by tokens (DPAN) for digital wallets, card-on-file, and IoT payments. Covers the full lifecycle, cryptogram generation, and the Visa VTS vs. Mastercard MDES service comparison.
Merchant and PSP tokens vs network tokens
"Token" means two different things for a merchant that keeps cards on file. A PSP vault token is a reference into the payment provider's own database: the provider still holds the real card number and sends it to the network on every payment. A network token is issued by Visa Token Service or Mastercard MDES and replaces the card number on the wire: it only works for one merchant or token requestor, each customer-initiated payment carries a one-time cryptogram, and it keeps working when the bank reissues the card. Most PSPs now do both: they vault the PAN and hold a network token beside it.
Raw PAN vs PSP vault token vs network token
| Attribute | Raw PAN on file | PSP vault token | Network token |
|---|---|---|---|
| Issued by | — | The PSP / gateway | The card network's TSP (VTS, MDES) |
| What the network sees | PAN | PAN (the PSP de-tokenizes first) | Token + cryptogram; the network maps it to the PAN |
| Merchant PCI scope | Full PCI DSS | Minimal (e.g. SAQ A) | Minimal; the requestor still protects the token |
| Usable if stolen | Anywhere card-not-present | Only through that PSP account | Only by that requestor, merchant and channel (domain restriction) |
| Card reissued | Payment fails unless Account Updater runs | Same, unless the PSP runs Account Updater | Token keeps working; the requestor is notified |
| Per-payment proof | CVC at first use only | CVC at first use only | Cryptogram (TAVV / DSRP UCAF) for customer-initiated payments |
| Portable between PSPs | Yes (it is the PAN) | No — needs a vault migration | Tied to the token requestor; a new requestor re-tokenizes |
| Approval rate | Baseline | Same as PAN | Higher: networks report a few points of uplift |
| Cross-merchant identifier | PAN | None | Payment Account Reference (PAR) |
Animated flows — vault token, enrolment, checkout cryptogram, recurring + reissue
The classic card-on-file setup: the PSP stores the real card number (PAN) in its PCI DSS vault and gives the merchant an opaque reference. The merchant is out of PCI scope, but every payment still travels to the network with the real PAN.
Card captured in hosted fields
PAN, expiry and CVC go straight from the browser to the PSP.
Hosted fields, an iframe or a mobile SDK keep card data off the merchant’s servers, so the merchant qualifies for the lightest PCI DSS questionnaire (SAQ A).
Who can request network tokens
Only a registered token requestor can ask for tokens. Each has a Token Requestor ID (TRID) per network, and every token is bound to it. There are three common models:
- PSP or gateway as requestor (the usual one): the PSP registers once and tokenizes for all its merchants, passing each merchant's identity so the token is restricted to that merchant.
- Merchant as requestor: large merchants register directly, so their tokens are not tied to one PSP. They must then call VTS and MDES themselves, or through a token-requestor service.
- Wallets and click-to-pay: Apple Pay, Google Pay and Click to Pay are requestors too; the merchant receives a token and cryptogram per payment but does not hold a reusable token (see Wallet Provisioning).
Getting a token
Visa Token Service: POST vts/panEnrollments with the card encrypted as JWE in encPaymentInstrument and a panSource such as ONFILE, then POST vts/panEnrollments/{id}/provisionedTokens. Requests are signed with an X-PAY-TOKEN HMAC header. If the issuer wants step-up, the requestor offers the stepUpOptions and completes it with an OTP.
Mastercard MDES: POST /digitization/static/1/0/tokenize with tokenTypeCLOUD, the tokenRequestorId and fundingAccountInfo protected with Mastercard field-level encryption. The decision is APPROVED, DECLINED or REQUIRE_ADDITIONAL_AUTHENTICATION.
The response carries the token's own expiry (not the card's), a token reference ID for later API calls, the PAR, and product data such as card art and the last four digits of the PAN for display.
Paying with a network token
For every customer-initiated payment (CIT) the requestor fetches a fresh cryptogram just before authorizing:
- Visa: the TSP returns a TAVV, carried in VisaNet Field 126.8. The authorization has the token and token expiry instead of the PAN, card expiry and CVC.
- Mastercard:
POST /remotetransaction/static/1/0/transactwithdsrpTypeUCAFand anunpredictableNumberreturns an encrypted payload with the token,applicationExpiryDate,panSequenceNumberand the DSRP cryptogram. Under AN 3363 the cryptogram goes in DE104 subelement 001 (Digital Payment Data); DE48 SE43 was the older carrier.
Merchant-initiated payments (MIT: recurring, instalments, unscheduled top-ups) use the stored token and the network transaction ID of the original CIT. Network rules generally do not require a new cryptogram for them — check your acquirer's specification. In the EEA and UK the first CIT still needs strong customer authentication; 3-D Secure works with network tokens, and the authentication value (CAVV / AAV) travels alongside the token.
Lifecycle: why subscriptions like tokens
When the issuer replaces a card (expiry, loss, product upgrade), it updates the TSP. The token stays the same and the requestor is told: Mastercard calls notifyTokenUpdated; Visa sends lifecycle notifications. Tokens can be ACTIVE, SUSPENDED (e.g. card reported lost, may be resumed) or DEACTIVATED (account closed — stop retrying). Account Updater (Visa VAU, Mastercard ABU) gives a similar result for raw PANs, but in batches and only on request.
Common pitfalls: sending the card expiry instead of the token expiry; reusing a cryptogram (each is single use); dropping the stored PAN, which is still needed where tokens are not supported; falling back to the PAN after a token decline, which bypasses the issuer's decision; and ignoring lifecycle notifications, so suspended or deactivated tokens keep being retried.
Network tokens are also the basis of agent payments: Visa Intelligent Commerce and Mastercard Agent Pay issue tokens to AI agents with the same domain restrictions and per-payment cryptograms.