In plain English: what a PAN is, what a token is, why networks push tokens, and what this means for your checkout and card-on-file flows. Useful today; still relevant tomorrow.
The 30-second version
Freshness note: accurate as of 26 Sep 2025.
Cards used to travel as raw numbers (PAN). In 2025, the default is shifting to network tokens (issued under the EMVCo framework) and DPANs (device-specific tokens used in Apple Pay/Google Pay). Tokens lower fraud and make revenue more resilient: fewer false declines, automatic updates when the physical card changes, and less friction in 3-D Secure (3DS2). You still own the customer experience and your vault logic—but you should ask your PSP/gateway a few pointed questions (checklist below).
PAN vs. network token vs. DPAN — in plain words
PAN (Primary Account Number). The long card number printed on the card. It’s stable until the card is reissued. If you touch/store PANs (even via a PSP), you expand PCI obligations and face more churn when cards expire or are replaced.
Network token. A token created and managed by the networks (EMVCo). It represents a PAN but is not the PAN. Networks bind it to context (merchant, domain, device, channel) and refresh it automatically when the underlying card changes. Operationally, it behaves like a safer, auto-updating alias you can charge.
DPAN (Device PAN). Used in wallets. Think of it as a device-specific network token for that phone or watch. Each device gets its own DPAN and a per-transaction cryptogram; the PAN never leaves the device.
Mental model:
PAN = raw card number (legacy default)
Network token = safer, auto-updating alias for your merchant/app/site
DPAN = token tied to a specific device/wallet
Where life gets easier for merchants
- Fewer false declines (better approvals). Tokens carry richer, fresher signals (domain/device binding). Issuers trust them more, so authorization rates improve—fewer “your card was declined” for good users.
- Auto-updates beat “broken cards.” When a card expires or is reissued, network tokens refresh behind the scenes. Recurring billing avoids waves of failed renewals.
- Less 3DS2 friction where risk is lower. Tokenized traffic often scores better with issuer risk models, yielding more frictionless 3DS2 outcomes while meeting SCA requirements.
- Wallets “just work.” DPANs, device cryptograms, and wallet checks shoulder much of the security load—lifting approvals and reducing spoofing.
What still sits with you (the merchant)
- Vault strategy. Decide what you “store”: your surrogate keys, your PSP’s tokens, or network tokens provisioned via your PSP. Clarify portability: if you change PSPs or add routing, can you keep charging the same tokens?
- Card-on-file & MITs. Subscriptions, trials-to-paid, top-ups, and one-click reorders still need clear consent, descriptors, and reason codes. Tokens help approvals, but retry logic, dunning, and smart routing drive renewals.
- SCA and exemptions (EU/UK). Tokenization reduces friction, but SCA still applies. Coordinate MIT framework, TRA, and low-value exemptions with your PSP to minimize challenges while staying compliant.
- Disputes don’t vanish. Better data reduces friendly fraud, but policy clarity wins: clean receipts, proof of delivery, and simple refunds.
How tokenization actually flows (simplified)
- Customer enters a card or uses a wallet.
- Your PSP/gateway requests a network token (or uses a DPAN from a wallet).
- The token is bound to your merchant/domain/app and returned to your vault.
- Each charge includes a dynamic cryptogram and fresh metadata.
- If the physical card changes later, the network updates the token mapping.
- Recurring charges keep working—fewer “card expired” failures.
Practical gains you can expect
- Approval lift: tokenized traffic often authorizes a few points higher than PANs with similar profiles.
- Renewal stability: auto-refresh cuts involuntary churn from expired/replaced cards.
- Lower friction: more frictionless 3DS2 on low-risk traffic.
- Fraud pressure: tokens + device signals help issuers say “yes” to good users and “no” to bad ones.
(Deltas vary by market, issuer mix, and checkout design—verify with your own A/Bs.)
Implementation choices you’ll face
- Network tokens vs. PSP proprietary tokens. Network tokens are portable across supporting providers and auto-refresh with card lifecycle events. PSP tokens can be faster to adopt and cross-scheme, but portability may be limited. Best practice (2025): enable network tokens wherever available and keep a migration plan.
- Routing & redundancy. If you use multi-acquirer routing, confirm tokens work across all routes and that domain controls won’t block failover.
- Global mix. Wallet penetration and token support differ by country. Prioritize high-impact locales first (sensitive approvals, large subscription bases).
Mini-checklist: what to ask your provider
Scheme tokenization support
• Do you provision network tokens per scheme for card-on-file and recurring?
• Are DPAN wallet flows (Apple/Google Pay) first-class on web and app?
Lifecycle & portability
• Is auto-refresh enabled so tokens survive reissues/expiry?
• If we change acquirers or add routing, can we keep charging existing tokens?
• Can you export or map tokens if we migrate?
3DS2 & SCA strategy
• How do tokens influence frictionless rates?
• What exemptions are applied for MIT/recurring, and how are they evidenced?
Metrics & reporting
• Do you break out approval rate for tokenized vs. PAN traffic?
• Can we track involuntary churn after tokenization?
• What are your false-decline benchmarks for our profile?
Risk & ops
• How do tokens interact with our fraud tools and allow-lists?
• What’s the fallback if token provisioning fails mid-checkout?
• How does our PCI scope change if we stop touching PANs?
The bottom line
Tokenization is no longer a “nice to have.” In 2025 it’s the card-rails equivalent of using HTTPS: invisible to the user, but critical for trust, approvals, and renewals. If you run subscriptions, memberships, or any card-on-file flow, enabling network tokens (plus wallets) is one of the cleanest ways to cut avoidable churn and checkout friction—without rebuilding your stack.
Facts are based on company statements, product briefings, and industry reporting.