Cards & Merchant Payments / Learning brief
Card tokenisation: from PAN to DPAN
Your notes
In simple terms / 01
What this means in plain language
Why a phone wallet never carries the real card number: how EMV payment tokenisation swaps the PAN for a device-bound network token (often called a DPAN), who the token requestor and token service provider are, what the token vault maps, and why a lost phone no longer means a reissued card.
Card tokenisation replaces the real card number — the PAN (primary account number) — with a substitute number called a payment token, so the real number stops travelling through phones, terminals, and merchant databases. Under the EMV Payment Tokenisation framework, a token requestor (a phone wallet, or a merchant storing cards on file) asks the card network's token service provider for a token; the issuer approves; and the mapping between token and PAN is stored in a token vault that only the token service can read. A token provisioned to a specific phone or watch is commonly called a DPAN (device primary account number). It looks like a card number, but it is bound to its device, fenced by domain restrictions, and presented with a one-time cryptogram, so a stolen token is close to useless elsewhere. At payment time the network swaps the token back to the real PAN before the issuer decides. The practical benefits: merchants never hold real card numbers, and a lost phone means suspending one token — not reissuing the card.
Key takeaways / 03
Three things to remember
- 01
Tokenisation substitutes the PAN with a network token; the real number lives only in the token service provider's vault, and the swap back happens inside the network during authorisation.
- 02
A DPAN is a device-bound token in card-number format, protected by domain restrictions and a per-transaction cryptogram rather than by encryption of the PAN.
- 03
Token lifecycle management separates the credential from the card: a lost phone kills one token, and a reissued card can keep its existing tokens working.
Practical use cases / 04
Where you would use this
A wallet provider provisions device tokens so phones and watches can pay at terminals without the card number ever being stored on the device.
A subscription merchant converts its stored cards to network tokens, so customer payments survive card reissues and its database holds no real PANs.
An issuer's operations team suspends a single device token after a customer reports a stolen phone, leaving the plastic card and other wallets untouched.
Worked example / 05
Put the idea into a real situation
Illustrative example (SYNTHETIC / TRAINING ONLY): Maya Chen, a fictional customer, adds her Bank Alfa card ending 4821 to her phone wallet; Bank Alfa and Cardnet are fictional (Cardnet stands in for Visa- and Mastercard-style networks). The wallet, acting as token requestor, asks Cardnet's token service for a token; Bank Alfa approves after Maya confirms a one-time code; and the vault records the mapping between her PAN and a new DPAN ending 0093, restricted to that phone. When Maya taps the phone for a GBP 3.60 coffee, the terminal sees only the DPAN and a cryptogram. Cardnet detokenises, Bank Alfa authorises against her real account, and the merchant's records keep the token alone. When Maya later loses the phone, Bank Alfa suspends the DPAN ending 0093 in the vault. Her plastic card ending 4821 keeps working, and nothing needs reissuing.
Evidence & review / 07
Evidence & review
Network tokenisation of card payments under the EMV Payment Tokenisation framework, in wallets and merchant card-on-file setups generally. Each card network operates its own token service with its own enrolment and lifecycle rules.
What this brief simplifies: Follows one wallet provisioning and one payment round trip. Identity-and-verification step-up options, token assurance detail, and differences between network token services are compressed; acquirer and gateway tokens are mentioned only to distinguish them.
Sources for this brief1
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.