Open the card details for anything you've added to Apple Pay or Google Wallet and look at the last four digits. They often don't match the plastic in your pocket. That's not a bug. The phone never received your real card number at all. It got a stand-in, and every tap sends that stand-in along with a fresh, single-use code.
The same machinery now runs behind a lot of online checkouts where no phone is involved. It's called network tokenization, and it's one of the quieter reasons a stolen merchant database is worth less than it used to be. It's also a good example of fintech solving a security problem by changing what data exists, rather than by guarding the same data harder.
The three pieces: PAN, token, cryptogram
Your card's real 16-digit number is the PAN (primary account number). For decades the PAN was both the identifier and, effectively, the password: anyone holding it, plus an expiry date, could attempt a charge.
Network tokenization splits that apart. The card network (Visa, Mastercard, and so on) runs a token vault that maps a PAN to one or more tokens. A token looks like a card number and travels through the same authorization rails, but it is bound to a specific context: one phone, or one merchant, or one channel.
The third piece is the cryptogram, a one-time value generated for each transaction. It's computed from data like the token, the merchant, and the transaction details, and the issuer checks it during authorization. A valid token with a missing or stale cryptogram gets declined.
Here's the flow for a tokenized online purchase, simplified:
1. Merchant (via its payment processor) sends: token + cryptogram + amount
2. Card network checks the token is being used in its bound context
3. Network looks up the token in its vault and finds the real PAN
4. Network forwards PAN + token details to the issuing bank
5. Issuer validates the cryptogram, checks the account, approves or declines
6. The response travels back the same pathThe merchant never sees the PAN. Neither does the phone. The only place the mapping lives is inside the network's vault.
Not the same as your processor's "token"
If you've built a checkout with a payment processor, you've probably stored something like a customer or payment-method ID instead of a raw card number. That's also called a token, but it's a different thing.
A processor token is a pointer into your processor's vault. Behind it sits the real PAN, and when you charge it, the processor sends that PAN to the network. It keeps card data out of your own database, which matters for PCI compliance, but the PAN is still what gets authorized.
A network token is issued by the card network itself and is what actually travels through authorization. Many processors now do both: you hold their ID, and behind the scenes they've swapped the stored PAN for a network token. Some expose it as a toggle in the dashboard; others turn it on by default. If you run a subscription business, it's worth asking your processor which one your stored cards use.
Why issuers approve more of them
The security story is the obvious part. A token stolen from Merchant A is useless at Merchant B, and without the per-transaction cryptogram it can't even be replayed at Merchant A. Visa has reported up to a 28% reduction in fraud on tokenized card-not-present transactions.
The less obvious part is lifecycle management, and it's where a lot of the money is. When your card expires or gets reissued after a fraud scare, the PAN changes. Every merchant storing the old PAN starts getting declines, which is how a subscription service quietly churns a customer who never meant to cancel. With a network token, the issuer updates the vault mapping, and the token keeps working. The merchant never has to ask you for your new card.
Put the fraud signal and the lifecycle updates together, and the networks report meaningfully higher approval rates for tokens than for raw PANs: Visa has cited a 4.6% uplift and Mastercard 2.1% for card-not-present payments. Treat those as network-reported averages, not guarantees. Results vary by issuer, region, and merchant category, and vendors repeat these numbers far more often than they verify them.
A quick illustration of why even small percentages matter: a subscription service billing 100,000 cards a month at $15 sees $1.5 million in attempted charges. A two-point swing in approvals is about $30,000 a month, roughly $360,000 a year, before counting the customers who would have churned after a decline.
Where this is heading
Mastercard said in June 2024 that it aims for 100% tokenization of e-commerce transactions in Europe by 2030, pairing tokens with Click to Pay and passkeys so shoppers stop typing card numbers into forms. At the time it said its tokenization service already secured about a quarter of global e-commerce transactions. That's a stated goal, not a regulation, and it relies on merchants, processors, and banks all moving together.
The tradeoff is concentration. Tokenization moves trust from thousands of merchant databases into a handful of network vaults, and it adds another dependency between you and an approved payment. For most merchants that's a good trade. If you want to go deeper, read your processor's network-token documentation and the EMVCo payment tokenisation specification, which is the industry framework the networks build on.