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.
Limited-Use Key (LUK)
The Limited-Use Key is a symmetric key derived per DPAN and stored in the device's Secure Element (or cloud HSM for HCE). It is used to generate per-transaction cryptograms. The LUK has a usage limit (e.g., 10 transactions or 30 days) after which a fresh LUK is derived and pushed to the device. This limits the exposure from any key compromise.
TAVV — Token Auth Verification Value (Visa)
TAVV replaces the CAVV for tokenized Visa transactions. It is computed by the device using the LUK combined with the FPAN, transaction amount, currency, date, and a random nonce. The issuer's TSP validates the TAVV by recomputing it using the same inputs — a valid TAVV proves that the genuine provisioned device generated this transaction.
TAVV is transmitted in the same field as CAVV (DE48 SE22 in Visa VisaNet, or equivalent). The issuer validation is transparent to the standard authorization flow.
DSRP — Digital Secure Remote Payment (Mastercard)
DSRP is Mastercard's cryptogram for tokenized remote (card-not-present) transactions. It generates a full EMV-like ARQC inside the device's secure element using the DPAN's derived keys. The ARQC is transmitted in DE55 (just like a chip card transaction), enabling the issuer to validate it with standard EMV cryptogram verification logic.
DSRP makes an e-commerce transaction cryptographically equivalent to an in-person chip transaction — the issuer validates the same ARQC either way.
Cryptogram Comparison
| Attribute | TAVV | DSRP | CAVV (3DS) |
|---|---|---|---|
| Scheme | Visa | Mastercard | All schemes |
| Derivation inputs | LUK + FPAN + txn data + nonce | DPAN keys + ARQC data (EMV standard) | ACS key + transaction data |
| Transmitted in | DE48 SE22 (same field as CAVV) | DE55 (EMV chip data block) | Auth request (DE48 SE22 for Visa) |
| What it proves | Device possession + transaction integrity | Device possession + EMV-equivalent security | Cardholder was authenticated by issuer ACS |
| Used in | Mobile wallet, card-on-file | 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.