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.
Transaction Cryptograms
Tokenization is only secure because each transaction is protected by a cryptogram that proves the payment came from the genuine provisioned device. Without a valid cryptogram, a stolen DPAN cannot be used to make payments.
Where the token keys live: Secure Element vs cloud (LUK)
Secure-element wallets (Apple Pay, Samsung Pay on SE devices) keep the token's EMV keys inside the device's Secure Element for the life of the token. Cloud-based / HCE wallets (Google Wallet on Android) cannot rely on an SE, so the token service derives Limited-Use Keys (LUKs) from a master key it shares with the issuer's processing and pushes them to the phone over the air. Each LUK is short-lived — valid for a number of transactions or a time window — and is replenished when it runs low; issuers can be told about replenishment in 0620 advice messages. A stolen LUK is only useful for a few payments.
TAVV — Token Authentication Verification Value (Visa)
The TAVV is the cryptogram for card-not-present Visa token transactions (card-on-file, in-app, click-to-pay). It is generated by an approved entity, typically the Visa Token Service itself, at the token requestor's request, and passed to the merchant through the token requestor. It never involves the FPAN: VTS validates it and swaps the token for the FPAN before the issuer sees the authorization.
In VisaNet the TAVV travels in Field 126.8; Field 126.9 carries the 3-D Secure CAVV. A TAVV is single-use: since January 2022 Visa declines transactions carrying a previously used or stale TAVV. In-store wallet taps don't use a TAVV; they produce an EMV cryptogram (see below).
DSRP — Digital Secure Remote Payment (Mastercard)
DSRP is Mastercard's cryptogram for tokenized remote transactions (in-app, e-commerce, card-on-file). It is carried either as full EMV chip data in DE55 or in UCAF format in DE48 subelement 43; the UCAF form can hold both an authentication value and the DSRP cryptogram. A cryptogram is required on the initial authorization; follow-on recurring or split-shipment authorizations don't need one.
Cryptogram Comparison
| Attribute | TAVV | DSRP | CAVV (3DS) |
|---|---|---|---|
| Scheme | Visa | Mastercard | All schemes |
| Derivation inputs | Token-service keys + token + transaction data (never the FPAN) | Token keys + EMV transaction data | ACS key + transaction data |
| Transmitted in | VisaNet Field 126.8 | DE104 SE001 for remote commerce (AN 3363; DE48 SE43 before); DE55 for contactless | Visa Field 126.9; Mastercard DE48 SE43 (AAV) |
| What it proves | Device possession + transaction integrity | Device possession + EMV-equivalent security | Cardholder was authenticated by issuer ACS |
| Used in | In-app, card-on-file, click-to-pay (not in-store taps) | Mobile wallet, in-app, card-on-file | 3DS-authenticated e-commerce |
ARQC in Token Context
For in-person NFC payments using a mobile wallet, the standard EMV ARQC mechanism is used. The device's Secure Element stores token-specific keys that replace the card-derived keys. From the terminal and issuer perspective, the transaction looks identical to a physical EMV chip transaction — the ARQC is generated and validated using the same EMV standard derivation, just with different underlying keys tied to the DPAN rather than the FPAN.
🧩 Check yourself