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.
Running tokens as an issuer
Every network token belongs to an issuer's card, and the issuer decides whether it may exist. There are three ways to take part. Most issuers connect to the network's TSP (Visa VTS, Mastercard MDES) and answer its approval requests and notifications. Many let their issuer processor do that integration. A few, such as Amex and Discover (which are both issuer and network), some domestic schemes, and Indian card issuers tokenizing their own cards under the RBI card-on-file rules, run the token service themselves.
EMVCo roles and building blocks
The EMV Payment Tokenisation Specification — Technical Framework (v2.4 is current) defines the parts every token service has, whoever runs it:
| Term | Meaning |
|---|---|
| Token Service Provider (TSP) | Issues tokens from token BIN ranges, keeps the token vault, de-tokenizes and manages lifecycle. Registered TSPs get an EMVCo TSP code. |
| Token Requestor | Asks for tokens: wallets, merchants, PSPs, click-to-pay, agent platforms. Each has a Token Requestor ID per TSP. |
| Token Programme / Token User | Newer roles: the programme sets the rules a group of tokens follows; a token user pays with tokens received from a requestor. |
| Token Vault | The token-to-PAN mapping, plus the token's domain, status and requestor. The most sensitive store in the system. |
| Domain restriction controls | Where a token may be used: requestor, merchant, channel (contactless, e-commerce), and whether a cryptogram is required. |
| Token Assurance Method | How the cardholder was verified when the token was issued (e.g. no ID&V, OTP, logged in to the bank app). Travels to the issuer in authorization. |
| Payment Account Reference (PAR) | A 29-character value that identifies the card account across its PAN and all its tokens. |
Animated flows — issuer on a network TSP, lost card, issuer as TSP
The common setup: Visa VTS or Mastercard MDES runs the token service, and the issuer answers its questions. It approves each new token, sends one-time codes when it wants step-up, and is told when the token is live.
Token request
A wallet or merchant asks for a token for a card.
The request carries the encrypted card, the token requestor ID and risk data: device and wallet-account scores, device name, account age, how the card was entered.
Issuer integration with VTS and MDES
An issuer on a network TSP implements the same five steps for both networks. Each step is available as an API (below) and, for issuers on older hosts, as ISO 8583 messages.
| Step | Mastercard MDES | Visa VTS |
|---|---|---|
| Approve a new token | authorizeService | Token Activation Request |
| Deliver a step-up code | deliverActivationCode | OTP through the issuer API, or a Visa-generated OTP in an 0100 message |
| Token is active | notifyServiceActivated | Token Create Notification |
| Token status changed | notifyTokenUpdated | Token Event Notification |
| Issuer acts on a token | Customer Service API: search, suspend, unsuspend, delete | VTS issuer lifecycle API: suspend, resume, delete, update card |
MDES retries its outbound calls (deliverActivationCode, notifyServiceActivated, notifyTokenUpdated) three times and then again with longer intervals, so the issuer's endpoints must be idempotent. When the issuer does not answer an approval request in time, the TSP can stand in and decide using rules the issuer configured beforehand.
Designing the approval decision
The approval request carries far more than the card. A typical issuer rule set uses:
- Card checks: status, expiry, and CVC and address results the TSP already verified.
- TSP and wallet risk: device score, wallet-account score and reason codes, account age, number of cards added recently, whether the device is in the cardholder's country.
- Channel: push provisioning from the bank app is usually green; a card typed into a new device is often yellow; card-on-file tokens for merchants are usually green.
- Own data: a recent password reset, a new phone number, or fraud cases on the account push toward yellow or red.
On yellow, offer at least one method that does not depend on a phone number an attacker may have just changed. App-to-app verification in the bank app is the strongest and the easiest for the cardholder (see Wallet Provisioning).
Lifecycle decisions
| Event | Usual issuer action on tokens |
|---|---|
| Card lost or stolen | Block the card; suspend or keep device tokens (the phone was not lost); update the PAN when the new card is issued, then resume. |
| Card expired and renewed | Update expiry / PAN in the TSP; tokens continue unchanged. |
| Phone lost | Suspend or delete that device's token only; the card and other tokens keep working. |
| Fraud on a token | Delete that token; review the other tokens on the account. |
| Account closed | Delete all tokens; requestors receive DEACTIVATED and must stop retrying. |
| Product change | Update card art and product data; the token stays the same. |
Show the tokens in the bank app ("Apple Pay on iPhone", "Netflix", "Amazon") with suspend and delete buttons: cardholders then fix a lost phone or an unwanted subscription themselves instead of blocking the whole card.
Running your own TSP
An issuer-run TSP has to build what the networks provide as a service:
- Token BIN ranges registered with the network so tokens route back to the issuer, and EMVCo TSP registration.
- Vault in PCI DSS scope, with HSM-protected keys for mapping and for cryptogram validation.
- Cryptogram keys: per-token keys for Secure Element wallets, and limited-use keys with replenishment for cloud (HCE) tokens.
- Requestor onboarding: token requestor IDs, domain restrictions and APIs for each wallet and merchant, which is the hardest part to scale.
- De-tokenization in authorization, 24/7, with its own stand-in when the core is down.
The benefits are full control of the data, no per-token fees, and the ability to tokenize on domestic rails. The cost is that Apple, Google and large merchants integrate first with the global network TSPs, so most issuers use the network TSP for international tokens even when they run their own for domestic ones.