A tokenized card has two numbers:
| Term | What it is |
|---|---|
| FPAN Funding PAN | The number printed on the card. Balance, credit line and statements hang off it |
| DPAN Device PAN, the token | The stand-in. Same order of length as the FPAN, passes Luhn, all digits — in a message it has the same shape as a real card number |
A token is a structurally valid card number drawn from BIN ranges reserved for tokens. That design lets acceptance devices, acquirers and message gateways keep their parsing untouched and go on treating it as a card number.
The constraint that comes with it: the bytes of DE 2 alone do not tell you whether you are holding an embossed number or a token. Telling them apart depends on the token BIN ranges, and those are distributed to acquirers by the schemes rather than published in open BIN tables. For how a BIN itself is read, see what a card BIN is.
The issuer of the token is the TSP (Token Service Provider). Each of the two large schemes runs its own: MDES at Mastercard, VTS at Visa. A TSP does three things: issue the token, hold the DPAN-to-FPAN mapping, and perform the substitution during a transaction.
The party requesting a token is the token requestor, identified by a TRID (Token Requestor ID). Three kinds are common:
The same card gets a different token from each requestor: the one on the phone and the one held by a given merchant are two distinct DPANs. The PAR section covers grouping them back to one account.
Tokenized transactions add no custom structure to an ISO 8583 message. Four fields need a different reading:
| Field | In a tokenized transaction |
|---|---|
| DE 2 PAN | Carries the DPAN. Format, length prefix and Luhn are the same as any card number |
| DE 14 Expiry | Frequently empty. The token has its own expiry, separate from the one printed on the card, and the card expiry is held by the scheme. Its absence here is not a defect |
| DE 22 POS entry mode | Wallet contactless usually reads 07 (full contactless EMV); e-commerce token transactions land on card-not-present values such as 81. See DE22 entry mode codes |
| DE 55 EMV data | Wallet tokens carry a token cryptogram that changes per transaction and attests that this token is being used by an authorised device. Still TLV — see inside DE55 |
De-tokenization happens on the scheme side: on the way to the issuer, the TSP swaps the DPAN back for the FPAN. Which number the issuer finally sees depends on how that issuer is connected; some connection models give it both. When investigating which number DE 2 holds, establish first which segment of the path you are looking at.
One card with several tokens breaks three things: risk profiling, loyalty accrual, and reconciliation keyed on the card number. PAR (Payment Account Reference) exists for this: a 29-character alphanumeric string shared by every token on an account and by the card number itself.
PAR cannot initiate a transaction and cannot be reversed into an FPAN. It answers one question — whether these transactions belong to the same account. For profiling, duplicate detection and cross-channel reconciliation it is a steadier key than DE 2.
Tokens carry a domain restriction: at issuance they are bound to where they may be used — which device, which merchant, which channel, which entry mode. A token bound to a phone, presented in an e-commerce flow, is declined on the scheme side.
That restriction is also what separates a leaked card number from a leaked token: a clear PAN works at any acceptance point, while a token stops working outside the scope fixed at issuance.
One more on the risk side: hard-coding "expiry is mandatory" into validation rejects every wallet transaction that leaves DE 14 empty.