PSP & Infrastructure 10 min read
Network Tokens vs PSP Tokens: When Each Wins
Compare network tokens and PSP vault tokens by issuer, lifecycle and migration path. Scope, update behavior and portability depend on the implementation.
Network tokens and PSP vault references have different roles. Lifecycle updates and migration depend on the scheme, issuer, merchant setup and provider agreement. Neither token type alone guarantees portability or authorisation improvement.
Network tokens and PSP vault tokens are different credential mechanisms. They are provided through different systems and can behave differently across a card's lifecycle and a provider migration. The practical result depends on the specific token service and contract.
This is the operator's breakdown.
What each token actually is
A network token is a payment credential issued through a card-network token service, such as Visa VTS or Mastercard MDES. It is used in supported payment flows in place of the PAN; a token service provider resolves the credential within the relevant processing flow. Issuer, merchant and provider setup determine how a particular token can be used. Mastercard describes a separate account-token approach for digital-wallet accounts in its Wallet Pay announcement.
A PSP vault token is a provider-specific reference to stored payment details. It generally works within that provider's systems; whether credentials can be migrated or exported depends on the provider's supported process, contract and applicable security requirements.
The architecture difference matters:
| Network Token | PSP Token | |
|---|---|---|
| Issued by | Card-network token service | Payment processor's vault service |
| Resolves to PAN via | Scheme network | PSP vault |
| Lifecycle when card details change | Token service may maintain validity; check supported flow | Provider may offer account-updater or migration services |
| Use after changing PSP | Depends on token requestor, merchant and receiving-provider setup | Provider-specific migration or export may be available by agreement |
| Auth-rate evidence | Scheme-reported results vary by channel, period and issuer coverage | Do not assume a lift from the vault reference alone |
Auth rate impact
Published network-token performance results are specific to their measurement period, channel and comparison group. They should not be treated as a forecast for an individual merchant.
| Reported figure | What it measures | Source and period |
|---|---|---|
| +4.6% authorisation lift | Card-not-present transactions, global, versus PAN | Visa Risk Datamart, FY2022 (via Visa's Tokenisation Knowledge Hub) |
The reported FY2022 figure is a Visa global CNP comparison against PAN. Channel, issuer participation, merchant mix and implementation can affect results. Treat the figure as context, not as a target to plan against.
Network-token flows can include token-specific data and cryptograms. Their effect on issuer decisions depends on the applicable scheme, issuer and transaction flow; do not treat tokenisation as a substitute for authentication or risk controls.
The PSP's stored-credential reference and the network token serve different roles. Do not infer a comparative approval-rate effect without measuring the relevant transactions.
Issuer participation affects results
Published results are not guaranteed to show up in your transactions. Issuer participation and the provider's implementation affect where network tokens are used.
Ask your PSP for issuer and market coverage before sizing expected impact. Compare like-for-like transactions in your own reporting.
Card lifecycle management
Network-token lifecycle services may matter to merchants storing credentials for recurring payments.
When underlying card details change, a provider vault reference may need an account updater or other credential maintenance process. Behavior depends on the provider and its services.
A network-token service may maintain the token relationship when underlying card details change. Confirm the applicable lifecycle behavior with the network and PSP; a valid token does not guarantee that a subscription charge will be authorised.
For subscription businesses, this distinction directly affects involuntary churn — the portion of subscriber loss driven by payment failures rather than cancellations.
Portability
PSP vault references are provider-specific. When you switch PSPs, ask whether the outgoing provider supports a secure credential migration or export under your agreement. If it does not, options may include recollecting payment details or another provider-supported migration path. Requirements depend on the data, providers and applicable security controls.
Network-token migration is also implementation-specific. Some PSPs document options to manage or forward network tokens to a PCI-compliant provider; eligibility and setup depend on the token service, token requestor, merchant arrangement and receiving PSP. Adyen's network-token documentation is one provider-specific example, not a universal migration rule. Confirm the path with both providers before switching.
When to evaluate network tokens
Subscription billing — Ask whether network-token lifecycle services support your issuers and stored-credential flows, and measure their effect on your own retries and payment outcomes.
Card-on-file merchants — Compare network-token support, issuer coverage and reporting with your current stored-credential flow.
Multi-PSP setups — Ask how credentials are provisioned, shared or forwarded across the specific merchant accounts and PSPs in scope. Do not assume a scheme token is automatically usable across providers.
High-volume recurring — Evaluate lifecycle support and transaction outcomes against your own issuer mix, costs and provider terms before estimating a business case.
When PSP tokens are sufficient
One-shot checkout — If the flow does not store payment credentials, stored-credential lifecycle and migration features may be less relevant.
Single-provider or low-volume setups — Compare the available feature set and migration requirements with the operational effort before opting in.
No stored credentials — If your business model does not store payment credentials, credential lifecycle and migration questions may be less central to the decision.
How to opt in
Network tokenisation may be managed by a PSP or require merchant-side configuration, depending on the provider and integration.
Ask your PSP:
- Are network tokens (Visa VTS / Mastercard MDES) enabled on my account?
- Are new card-on-file transactions being tokenised at the scheme level?
- How are existing stored credentials handled — are they retroactively tokenised or only new credentials?
- What does token lifecycle management look like in your reporting?
Ask whether network tokenisation is enabled for new credentials, whether existing credentials can be provisioned, and what support is available for migration.
Sources & methodology (5)
Visa reported a 4.6% global authorisation-rate lift for tokenised card-not-present transactions versus PAN, based on VisaNet FY2022 data.
Checked:
Adyen distinguishes its storedPaymentMethodId token from a network token, describes network tokens as PAN alternatives, and documents provider-managed, merchant-managed and third-party forwarding options for supported integrations.
Checked:
EMV payment-token processing uses a Token Service Provider to detokenize a payment token within the specified processing flow; tokenisation is distinct from a PSP's stored-credential reference.
Checked:
2025 industry overview of network token adoption, PSP token architecture, and scheme token roadmaps.
Checked:
Network tokens are listed as a primary lever for auth rate improvement in 2026, with PSP-level opt-in as the implementation path.
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer