Network Tokens vs PSP Tokens: When Each Wins

The word "tokenisation" appears in almost every payments conversation about PSP and infrastructure. It almost never comes with a qualifier. Network tokens and PSP tokens are not the same thing. They are issued by different parties, they behave differently across a card's lifecycle, and when you switch PSPs, only one of them causes you a serious problem.

This is the operator's breakdown.

What each token actually is

A network token is issued by the card scheme — Visa via its Token Service (VTS), Mastercard via the Digital Enablement Service (MDES). It replaces the raw card Primary Account Number (PAN) at the scheme level. The scheme maintains a mapping between the network token and the underlying PAN. Merchants and processors use the token; the scheme resolves it to the PAN when routing to the issuer. Mastercard describes a similar idea for accounts that are not cards: what it calls Wallet Pay account tokenization, announced in September 2026, which it says converts a digital wallet account into a payment credential without issuing a physical card.

A PSP token is issued by your payment processor. It is a reference number that your PSP uses internally to retrieve the stored card details from their vault. It means nothing to anyone outside your PSP's system.

The architecture difference matters:

Auth rate impact

There is no single Visa auth-rate or fraud-reduction figure for network tokens. The scheme has published at least three different pairs of numbers, from different periods and covering different transaction types, and quoting any one of them as "the" Visa figure is exactly the mistake to avoid.

These are not competing versions of one measurement. They cover different channels (CNP vs eCommerce), different periods (FY2022 vs FY2025), and different datasets. The most recent and most cleanly attributable pair is +6 percentage points approval and 30% fraud reduction, for tokenised eCommerce transactions — stated by Visa's CEO on the Q1 FY2025 earnings call. Any of these quoted without its channel and period is a number without a denominator. Uplift is segment-, issuer- and market-dependent; treat published scheme figures as directional, not as a target to plan against.

The mechanism behind all of them is the same: issuers trust tokenised transactions more because the token carries cryptographic proof that it was provisioned by the scheme and that the device or merchant requesting it was verified. This trust signal reduces issuer-side decline rates — particularly on card-not-present (CNP) transactions, which are the highest-decline category and also the category most affected by the 3DS2 authentication tax that network tokens help offset.

PSP tokens do not carry this scheme-level trust signal. Auth rate improvement from PSP tokenisation alone is marginal compared to the network token uplift.

Issuer enrolment decides your actual uplift

None of the figures above are guaranteed to show up on your own transactions, because the uplift is realised only where the issuing bank has enrolled in VTS or MDES. This is an issuer-side implementation, not a merchant-side one, and enrolment is not universal.

Enrolment is strongest in the United States and Western Europe, where major issuers have broadly implemented network token support. It is patchier in Southeast Asia and Latin America, where a meaningful share of issuers have not yet opted into the tokenisation program — a merchant tokenising card-on-file transactions in those markets sees the auth-rate benefit only on the portion of volume where the cardholder's issuer participates.

The practical consequence: network tokenisation is highest-ROI in strong-enrolment markets — the US, UK, Australia, Singapore — and lower-ROI, but still positive, elsewhere. The operator action is to ask your PSP for issuer-enrolment coverage by market before sizing expected impact. Do not size it from a published global average — none of the figures in the table above tell you what your own issuer mix will deliver.

Card lifecycle management

This is where network tokens create the most operational value for subscription merchants.

When a cardholder's card expires or is reissued (after fraud, for example), their card number changes. A PSP token maps to that card number. When the number changes, the token becomes invalid. The next subscription charge fails. Recovery requires either an account updater service or a re-authorisation email to the subscriber.

A network token works differently. The scheme maintains the mapping between token and PAN. When the PAN changes on reissue, Visa and Mastercard automatically update the mapping. The network token continues to work. The subscription charge succeeds without the merchant knowing the underlying card changed.

For subscription businesses, this distinction directly affects involuntary churn — the portion of subscriber loss driven by payment failures rather than cancellations.

Portability

PSP token portability: none. When you switch PSPs, your PSP-issued tokens stay with your old processor. The card data vaulted behind those tokens belongs to the PSP's infrastructure. To migrate, you need either:

1. Raw card data export — the PSP provides the raw PANs from their vault, which you import into a new PSP or vault. This requires a PCI DSS Level 1 card data migration process. It is legally available but operationally intensive.

2. Re-authorisation campaign — you ask subscribers to re-enter their payment method on the new platform. Industry experience suggests 10–25% of subscribers will not complete this step, resulting in involuntary churn.

Network token portability is more nuanced. Network tokens are bound to the merchant ID (MID) that the PSP operates on your behalf. When you switch PSPs, you get a new MID. The existing network tokens no longer route correctly through the new MID.

However, the underlying relationship between the scheme token and the PAN persists in the scheme's system. Some migration scenarios — particularly same-scheme moves with assistance from the acquirer — can facilitate re-tokenisation without requiring raw PAN access. This is not automatic, but it is operationally simpler than a raw card data migration.

The practical rule: whether you have network tokens or PSP tokens, a PSP migration involving stored payment credentials is never clean. The token type determines how painful it is — and how painful it is also depends on who's registered as the network's Token Requestor of record, the vault topology behind your credentials, and the PCI-gated export requirements each receiving processor imposes, all covered in payment credential vault architecture.

When network tokens win

Subscription billing — The auto-update on reissue alone justifies network token adoption for any subscription merchant. Reduced involuntary churn from card expiry is measurable and immediate.

Card-on-file merchants — Auth rate improvement is most significant on CNP transactions with stored credentials. Network tokens provide the scheme-level signal that reduces issuer declines.

Multi-PSP setups — Merchants operating across multiple processors or geographies benefit from the scheme-level consistency that network tokens provide. PSP tokens are processor-specific; network tokens have a consistent identity at the scheme layer.

High-volume recurring — At scale, even a mid-single-digit CNP auth rate lift translates to direct revenue. At $10M monthly recurring volume, recovering 4.6% of decline-driven failures — the FY2022 Visa CNP figure — is material — the economics of each auth rate point compound faster than most operators model.

When PSP tokens are sufficient

One-shot checkout — If customers are not storing their cards and each transaction starts fresh, PSP tokens and network tokens are functionally equivalent. The lifecycle management advantage of network tokens does not apply.

Low volume, single PSP — The operational overhead of network token opt-in may not be justified for early-stage merchants below $1M monthly volume with no planned PSP migration.

No subscription or recurring — If your business model does not involve stored payment credentials, the primary advantages of network tokens — auto-update, auth rate on stored credentials — do not materialise.

How to opt in

Network tokenisation is a PSP-level configuration, not a merchant integration project in most cases. Stripe, Adyen, and Checkout.com all support network tokens and can enable them per-merchant or per-MID.

Ask your PSP account manager:

1. Are network tokens (Visa VTS / Mastercard MDES) enabled on my account?
2. Are new card-on-file transactions being tokenised at the scheme level?
3. How are existing stored credentials handled — are they retroactively tokenised or only new credentials?
4. What does token lifecycle management look like in your reporting?

In many implementations, network tokenisation is already enabled by default for new stored credentials. The question is whether your existing vault contains network tokens or legacy PSP tokens — and what your PSP's migration path looks like for the legacy credentials.

The 2026 pricing signal

Visa has announced pricing updates for 2026 linked to tokenisation adoption. The direction: preferential rates for tokenised transactions, with incentives for merchants to accelerate adoption. Mastercard has set a 100% e-commerce tokenisation target for 2030.

The commercial signal is clear — both schemes are treating tokenisation as the default state for digital card payments, not an optional enhancement. Merchants still running significant PAN-based CNP volume are likely to face both pricing pressure and regulatory pressure to move.

If you are not opted into network tokenisation and your PSP supports it, this is a configuration change, not a project. Do it.