Network Tokens vs PSP Tokens: When Each Wins

The word “tokenisation” appears in almost every payments conversation. 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.

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:

	Network Token	PSP Token
Issued by	Card scheme (Visa VTS / Mastercard MDES)	Payment processor
Resolves to PAN via	Scheme network	PSP vault
Auto-updates on reissue	Yes	No
Portable to new PSP	Limited (MID-bound)	No
Auth rate impact	+4.6% vs PAN (Visa global data)	Marginal
Fraud reduction	34% vs PAN (Visa data)	Lower

Auth rate impact

Visa reports a 4.6% lift in authorisation rates for network token transactions globally, compared to equivalent raw PAN transactions. Mastercard publishes comparable figures. Fraud is reduced by 34% on tokenised transactions versus PAN.

The mechanism: 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.

The 4.6% lift is a global average across all transaction types. For subscription merchants on card-on-file flows — where issuers are already cautious — the uplift can be higher. For one-shot checkout merchants, the delta may be smaller.

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.

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 acquiring bank — 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.

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, a 4.6% auth rate lift translates to direct revenue. At $10M monthly recurring volume, recovering 4.6% of decline-driven failures is material.

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.