Most people picture a digital wallet as a photograph of a credit card. You add the card, the app shows the card art, you tap, the card gets charged. Reasonable model. It's also wrong in the one place that matters: your card number is not in your phone, and it never was.
What's stored instead is a different number entirely, one that belongs to that specific device and is useless almost everywhere else. Understanding what that number is, and what has to travel alongside it, explains a surprising amount about modern payments, including why your bank sometimes makes you jump through hoops to add a card and why your subscriptions survive getting a replacement card in the mail.
The number in your phone is a stand-in
When you add a card to a wallet, the wallet acts as what EMVCo's tokenisation spec calls a Token Requestor. It asks a Token Service Provider (in practice, usually the card network itself, through Visa's or Mastercard's token service) to issue a surrogate value for your real card number, the Primary Account Number or PAN. The TSP coordinates with your issuing bank to confirm you are who you say you are, then generates a token and stores the token-to-PAN mapping in a vault on its side.
The device gets a Device Account Number, or DPAN. It's provisioned encrypted and lives in the Secure Element, a separate tamper-resistant chip. Your phone and your watch get different DPANs for the same card. Apple's documentation is blunt about it: the full card number isn't stored on the device or on Apple's servers.
This is also where the friction you've experienced comes from. Issuers score each provisioning request and return a recommendation: green (approved outright), yellow (needs extra verification, hence the one-time code), orange (high fraud risk, call the bank), or red (declined). If you've ever had to phone your bank to add a card that worked fine in a store an hour earlier, you hit an orange path.
A stolen token can't buy anything
Here's the part that makes tokenization more than a naming exercise. The DPAN alone doesn't authorize anything. Every transaction also carries a cryptogram: a single-use value generated at the moment of payment and cryptographically bound to that token, that merchant, that amount, and that timestamp. Intercept it and you have a receipt, not a credential.
Compare what actually crosses the wire:
// Raw PAN — anyone who captures this can replay it anywhere.
{ pan: '4111111111111111', exp: '09/29', cvv: '737' }
// Network token — device-scoped, useless without a fresh cryptogram.
{ token: '4111119876543210', exp: '12/31', cryptogram: 'AgAAAAA...', eci: '05' }On top of that, the TSP applies domain controls: usage parameters that pin a token to a particular channel or use case. A token minted for in-app payments on one device can be rejected outright if it shows up somewhere it has no business being. The network declines it before your bank ever sees it.
Merchants care for a less obvious reason
Security is the story everyone tells. The reason payment teams actually push for tokens is approval rates. Visa reports roughly a 4.6% lift in authorization rates on tokenized card-not-present transactions versus raw PANs, with Mastercard around 2.1%, alongside a reported ~26% average decline in fraud. Industry benchmarks generally land in a 2 to 6 percentage point band.
Three things drive that. The network pre-validates the token before the request reaches the issuer, which is a stronger signal than a bare card number. The cryptogram proves the transaction is live rather than replayed. And tokens are updated automatically when a card is reissued, so a lost card no longer silently kills a recurring charge. Mastercard now says tokenization covers more than 90% of its global volume, with a token requestor registry aimed at fintechs rolling out in 2026.
The tradeoff worth naming: all of this concentrates a lot of leverage in the networks, since they own the vaults, the domain controls, and increasingly the relationship with the merchant. A merchant's stored credentials become less portable, not more. That's a structural change to payments, not just a security upgrade, and it's fair to be a little wary of it even while acknowledging that the tap in your pocket is meaningfully safer than the magstripe it replaced.
If you want the primary source rather than vendor marketing, EMVCo publishes the Payment Tokenisation Specification technical framework directly, and it's more readable than the acronym count suggests.