Payment Tokenization Beyond PCI Compliance

Tokenization has two very different implementations in payments, and conflating them is expensive. PSP-level tokenization — replacing a card number with a PSP-specific token in the merchant’s database — solves a PCI DSS compliance problem. Network tokenization, implemented through Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES), solves an authorization and fraud problem. The former reduces your audit scope. The latter increases your revenue.

Tokenized transaction volume grew 44% in 2024 (Visa, 2025). That translated into a measured 6% improvement in authorization approval rates and up to 30% reduction in fraud rates for merchants who implemented network tokens (Visa, 2025). Mastercard reported that MDES handled more than 30% of its global transaction volume in 2024 (Mastercard SEC filing, February 2025). Visa has committed to tokenizing all card-not-present transactions by 2030. The migration is happening, but most merchants are still operating on PSP tokens and missing the authorization rate benefit entirely.

PSP Tokenization vs Network Tokenization: The Actual Difference

PSP Tokenization

When a customer enters card details at checkout, the PSP (Stripe, Adyen, Braintree, etc.) encrypts the card number and replaces it with a PSP-specific token — a random string that maps to the real PAN in the PSP’s vault. The merchant stores and transmits the PSP token; the actual PAN never touches the merchant’s systems after the initial submission.

This solves the PCI scope problem. If you store PSP tokens instead of PANs, your systems don’t contain card data, and your PCI DSS assessment scope shrinks accordingly. It does not solve authorization quality. When the transaction reaches the card network, the PSP has de-tokenized and presented the original PAN and CVV. The issuer sees a raw PAN transaction with the same risk signals as any other card-not-present transaction.

Network Tokenization

Network tokenization operates at the card scheme level. Visa and Mastercard each maintain a central token vault. When a card is tokenized through VTS or MDES, the network generates a unique token (a 16-digit number that looks like a PAN but maps to the original card in the network’s vault) and cryptographically binds it to a specific merchant, domain, or device. Each transaction using a network token generates a unique cryptogram — a one-time code that proves the token was used in an authorized context.

When this tokenized transaction reaches the issuing bank, the issuer can validate:

1. That the token is legitimate (issued by the network, not synthesized by a fraudster)
2. That the cryptogram is valid (the token was used in the context it was bound to)
3. That the token has not been suspended or revoked

This is categorically higher-quality signal than a raw PAN. Issuers respond by approving more transactions that might otherwise be declined as suspicious. The 6% authorization improvement is not uniform — it’s higher in markets with elevated CNP fraud (Brazil, Indonesia, the UK) and for merchant categories with historically high decline rates (gaming, travel, digital goods).

The Lifecycle Advantage: Automatic Card Updates

Network tokens have one operational benefit that compounds over time: they survive card renewals and reissues. When a customer’s physical card expires or is replaced due to fraud, the card network notifies VTS/MDES, which updates the token’s underlying mapping automatically. The merchant’s stored network token continues to work without requiring the customer to re-enter card details.

PSP tokens do not have this property by default. When a card is reissued, the PSP token becomes stale and subsequent transactions decline. The workaround — Account Updater services from Visa and Mastercard — provides card updates via batch file, but it operates T+1 and requires explicit integration. Network tokens make Account Updater effectively redundant for merchants who implement them.

For subscription businesses, the math is direct: the average credit card has a 3-year expiration cycle, and issuers replace approximately 8–12% of cards annually due to fraud-related reissue. A subscription business with 100,000 active payment methods is looking at 8,000–12,000 card reissues per year. Each reissue that declines before Account Updater catches it is a passive churn event. Network tokenization eliminates this category of churn.

The Multi-PSP Portability Problem

Here is where network tokenization creates a structural challenge that PSP tokenization avoids: portability.

A PSP token is owned by the PSP. Stripe tokens cannot be used with Adyen. If you want to migrate card data from one PSP to another, you need to initiate a card data migration (CDM) — a formal process where the losing PSP exports encrypted PANs and the gaining PSP imports them under strict security protocols. This is painful, expensive, and typically requires a written agreement between PSPs. Stripe and Adyen have a history of providing CDM for departing merchants, but smaller PSPs may resist or delay.

Network tokens are theoretically more portable — the token is issued by the card network, not the PSP, so it should be usable with any acquirer. In practice, network token portability requires that the new PSP/acquirer support the MDES or VTS token format and has the appropriate agreements with the card networks to accept detokenization requests. Not all acquirers have this in place, and the operational process for migrating network tokens between acquiring relationships is not yet standardized.

The current state: for merchants operating a primary PSP with full VTS/MDES integration, the tokenization benefit is real but locked to that PSP’s implementation. Multi-PSP routing strategies (using Adyen as primary and Stripe as backup, for example) complicate network tokenization because each PSP may hold different tokens for the same card. This is solvable with a token orchestration layer (Primer, Spreedly), but adds another vendor and integration layer.

Implementation Paths: Issuer Enrollment Matters

Network tokenization’s authorization improvement is only realized when the issuing bank has enrolled in the MDES or VTS program and enabled the higher approval logic for tokenized transactions. This is an issuer-side implementation, not merchant-side — and enrollment is not universal.

In the US and Western Europe, major issuers (Chase, Bank of America, Barclays, Deutsche Bank) have implemented network token support. In Southeast Asia and LatAm, issuer enrollment is patchier. A merchant implementing VTS/MDES in Indonesia or Brazil will see authorization improvement only on transactions where the issuing bank has opted into the tokenization program — which may be 50–70% of their card volume rather than 100%.

The implication: network tokenization is highest-ROI in markets with strong issuer enrollment (US, UK, Australia, Singapore) and lower-ROI (but still positive) in markets with partial enrollment. Operators should ask their PSP for issuer enrollment data by market before sizing the expected impact.

What to Implement and When

If you’re on a single PSP: Most major PSPs now expose network tokenization automatically for stored cards or via explicit API parameter. Stripe automatically attempts network tokenization for saved cards in supported markets. Adyen’s Tokenization API supports VTS/MDES with a configuration flag. The implementation lift is typically 1–5 engineering days to ensure your checkout and recurring charge flows are using the tokenized card object rather than raw PANs.

If you’re on multiple PSPs: A token orchestration layer (Primer, Spreedly, Basis Theory) can normalize token handling across PSPs and provide a migration path for multi-PSP strategies. This is the right architecture for merchants routing more than $50M/year in card volume across multiple acquirers.

For subscription businesses specifically: Prioritize network tokenization for your card-on-file vaulting. The subscription renewal decline rate improvement (from eliminating card expiry declines) typically justifies the implementation cost within 3–6 billing cycles for merchants with 50,000+ active subscriptions.

For wallets and in-app payments: Apple Pay and Google Pay already use network tokens by default. If your mobile app routes Apple Pay or Google Pay transactions through your PSP, you’re already getting some network tokenization benefit for those payment methods. The gap is usually card-on-file (saved card) transactions, which require explicit VTS/MDES enrollment in most PSP implementations.

Visa’s 2030 Mandate and What It Means Now

Mastercard announced in 2024 that it would shift entirely to tokenization and biometric authentication by 2030, eliminating raw PAN transmission in card-not-present environments (Mastercard, November 2024). Visa has made similar statements about its tokenization roadmap. Tokenized transactions are projected to double from 283 billion in 2025 to 574 billion by 2029.

The practical meaning for operators: PAN-based CNP transactions will face increasing scrutiny and potentially higher decline rates as issuers are trained to expect tokenized transactions. Merchants who defer network tokenization implementation are not deferring a minor optimization — they are accumulating technical debt that will cost authorization rate points as the network transitions.

The authorization rate improvement from network tokenization is real, measurable, and available today. Treating it as a PCI compliance exercise rather than a revenue optimization misses most of its value.