Network Tokenisation Explained: How It Works, Benefits and When Merchants Need It

Quick summary: what is network tokenisation?

Network tokenisation replaces a customer's card number with a secure payment token issued through the card-network tokenisation ecosystem.

Instead of repeatedly using the customer's underlying Primary Account Number (PAN), an eligible payment can be processed using a token that represents that card.

The token can be restricted to a particular merchant, device or payment scenario, meaning that if it is compromised it cannot simply be used in the same way as a stolen card number.

For merchants, network tokenisation can be particularly useful for:

• cards stored on file
• subscription and recurring payments
• one-click checkout
• mobile and digital-wallet payments
• reducing exposure to card numbers
• keeping stored payment credentials up to date
• reducing avoidable payment declines
• supporting more resilient digital-payment infrastructure.

However, network tokenisation should not be confused with the proprietary tokens created by individual payment gateways or processors.

Understanding the difference becomes particularly important if a business has a large number of stored customers, uses several payment providers or is considering changing gateway.

Find Your New Processor

What is payment tokenisation?

Payment tokenisation replaces sensitive payment data with an alternative value known as a token.

The underlying card number is known as the Primary Account Number, or PAN.

Rather than exposing or repeatedly transmitting that PAN, a token can be used to represent the payment credential.

There are several different types of token used within payments, which is why simply asking whether a provider “supports tokenisation” does not always tell a merchant enough.

For example, a business might encounter:

• gateway or processor tokens
• acquiring tokens
• EMV payment or network tokens
• digital-wallet tokens
• other provider-specific payment tokens.

They are not necessarily interchangeable.

What is network tokenisation?

Network tokenisation uses the card-payment network's tokenisation infrastructure to replace the PAN with a payment token.

EMVCo, the technical body responsible for the global EMV Payment Tokenisation framework, describes an EMV Payment Token as a unique alternative value that replaces the PAN and can be constrained according to where and how it is used.

A token could, for example, be restricted to:

• a particular merchant
• a particular consumer device
• a particular payment scenario.

This means the token has less value if it is stolen than an unrestricted card number.

Unlike a proprietary gateway token that may primarily act as a reference to card data stored within one provider's vault, an EMV payment token can travel through the payment transaction from the point of purchase, through the acquirer and payment network, to the issuer for authorisation.

Read EMVCo's explanation of EMV Payment Tokenisation.

How does network tokenisation work?

A simplified card-on-file network-token transaction can work like this:

1. A customer provides their card details when making a payment or saving a card.
2. An eligible token request is made through the payment ecosystem.
3. The card credential is replaced with a network payment token.
4. The token is associated with a defined usage domain, such as a particular merchant.
5. The merchant or its payment provider can use the token for eligible future payments rather than repeatedly using the underlying PAN.
6. During a tokenised transaction, the token travels through the payment ecosystem for authorisation.
7. The card network and issuer can validate the token and its permitted usage.

The precise implementation depends on the card network, token service provider, payment provider and merchant setup.

Network tokenisation vs gateway tokenisation

This is one of the most important distinctions for merchants to understand.

Gateway or processor tokenisation

A payment gateway or processor may store a customer's card information within its secure payment vault and give the merchant a token that refers back to that information.

The merchant might therefore store:

Customer 123 → Gateway Token ABC123

rather than storing the customer's complete card number.

The token may only work inside that particular provider's system.

Network tokenisation

A network token replaces the PAN within the wider card-payment flow rather than operating solely as a reference inside an individual gateway's vault.

EMV Payment Tokens are designed to work through the payment ecosystem and are subject to controls defining how and where they can be used.

Visa, for example, describes its network tokens as replacing the PAN throughout the transaction flow from merchant to payment service provider and card network.

This distinction can matter for security, credential lifecycle management, recurring payments and the merchant's longer-term payment architecture.

Why do network tokens help when a customer's card expires?

One of the important benefits of network tokenisation is credential lifecycle management.

Stored-card businesses regularly experience customers whose underlying cards:

• expire
• are lost
• are stolen
• are replaced
• receive updated account information.

With traditional stored card details, a change to the underlying credential can result in a failed payment until the merchant obtains updated information.

Network-token lifecycle management can allow the token relationship to remain current when the underlying card credential changes, where supported by the issuer, network and payment setup.

This can be particularly useful for businesses relying on card-on-file and recurring payments.

Network tokenisation and recurring payments

Subscription businesses are one of the most obvious use cases for network tokenisation.

Consider a business charging thousands of customers every month.

Without effective credential lifecycle management, cards expiring or being replaced can result in:

• failed recurring payments
• involuntary customer churn
• additional payment retries
• customers being asked to update card details
• additional customer-service work.

Network tokens can help keep eligible stored credentials current, reducing some avoidable failures caused by outdated underlying card information.

They do not, however, guarantee that a recurring payment will be authorised.

An issuer may still decline a transaction for many other reasons, including insufficient funds, account restrictions, fraud controls or other issuer decisions.

For a wider explanation of recurring-payment infrastructure, read our Subscription Payment Processing guide.

Can network tokenisation improve authorisation rates?

Card networks and payment providers have published data showing improved authorisation performance for some network-tokenised transactions.

However, these figures should be interpreted carefully.

Network tokenisation does not guarantee a particular improvement in approval rates for an individual merchant.

Visa currently states that its Visa Token Service has produced an up to 5% increase in authorisation rates when comparing token transactions with PAN transactions in its cited VisaNet data.

View Visa Token Service information.

Mastercard also published 2025 data with Checkout.com showing that merchants within that particular dataset using network tokens saw a 10.3 percentage-point difference in approval rates compared with cards.

View Mastercard's network-tokenisation research.

These are network and provider datasets rather than universal industry benchmarks.

The actual effect for an individual business will depend on factors including its customers, issuers, transaction type, geography, payment provider and existing payment performance.

Can network tokenisation reduce fraud?

Network tokenisation is designed to reduce the value of compromised payment information.

An EMV Payment Token can be constrained so it only works within its intended usage domain.

This means that stealing a merchant-specific token does not provide the same unrestricted payment credential as stealing the underlying PAN.

Visa currently reports up to a 50% reduction in fraud for token transactions compared with PAN transactions within the VisaNet dataset cited by Visa.

Again, this is Visa's own network data and should not be interpreted as a guaranteed fraud reduction for every merchant.

Tokenisation should form part of a broader payment-security strategy rather than being treated as a replacement for fraud monitoring, authentication or other payment controls.

Network tokenisation and PCI DSS

Tokenisation can reduce exposure to cardholder data, but businesses should be careful with claims that tokenisation automatically makes them “PCI compliant”.

It does not.

The PCI Security Standards Council states that an EMV Payment Token used in accordance with the EMV Payment Tokenisation Specification and held outside the Token Service Provider's token data environment is not considered Account Data for PCI DSS purposes.

However, PCI DSS still applies anywhere account data is stored, processed or transmitted.

If systems handling tokens are also connected to systems that store or process underlying card data, those systems may remain within PCI DSS scope.

View PCI Security Standards Council guidance on EMV Payment Tokens and PCI DSS.

The practical impact therefore depends on the merchant's complete payment environment.

Network tokenisation vs account updater

Network tokenisation and account-updater services are related concepts but they are not the same thing.

An account updater is designed to provide participating merchants with updated payment credentials when an issuer changes a customer's card information.

For example, Visa Account Updater allows participating issuers and acquirers to exchange updated account information for credential-on-file merchants.

Network tokenisation instead replaces the underlying PAN with a token and can include its own lifecycle-management capabilities.

Depending on the provider and payment architecture, merchants may encounter network tokenisation, account-updater services or a combination of both.

Are Apple Pay and Google Pay examples of tokenisation?

Digital wallets are an important use case for network payment tokenisation.

For compatible wallet transactions, the underlying card credential can be represented by a payment token associated with the relevant device or payment environment.

However, merchants should not assume that every token they encounter through a digital wallet is identical to a merchant-specific card-on-file network token.

Token domains and provisioning can differ according to the use case.

This distinction becomes particularly important when businesses are considering:

• moving stored payment credentials
• changing payment provider
• building recurring-payment systems
• using several gateways or processors.

Can network tokens move when you change payment provider?

Businesses should not assume that network tokenisation makes payment-provider switching automatic.

This is an important distinction.

Network tokens are designed to operate across the payments ecosystem rather than being inherently tied to one processor in the same way as many proprietary gateway tokens.

However, the merchant still needs to establish:

• who is acting as the token requestor
• how the tokens were provisioned
• who controls the token relationship
• whether the proposed new provider supports the existing network-token setup
• whether tokens can remain in use or need to be reprovisioned
• what happens to any associated gateway tokens
• what recurring-payment information needs to be migrated.

For businesses with stored cards or subscriptions, token migration should therefore be investigated before cancelling the existing provider.

Read our Changing Payment Gateway: Moving Stored Cards, Tokens and Recurring Payments guide for a detailed explanation of the migration process.

Find Your New Processor

Network tokenisation and acquirer independence

Network tokenisation becomes particularly interesting for businesses developing more flexible payment infrastructure.

A merchant may want to:

• use more than one acquirer
• use several payment service providers
• route payments between providers
• reduce dependency on a single gateway
• change acquiring arrangements over time.

Network tokens can form part of this architecture because they are not simply proprietary references within an individual processor's vault.

However, successful multi-provider use still depends on how tokenisation has been implemented and which providers support the relevant token arrangement.

For businesses considering this type of architecture, see our Acquirer-Agnostic Payment Gateways guide.

Network tokenisation and payment orchestration

Payment orchestration platforms can connect a business to multiple PSPs, gateways or acquirers.

For businesses using this type of architecture, the location and ownership of stored payment credentials becomes important.

If all customer credentials are locked inside one PSP's proprietary vault, routing transactions to alternative providers may be more complicated.

A payment architecture that supports suitable tokenisation and provider-independent credential management can therefore be relevant to businesses considering orchestration.

This does not mean every business needs its own independent token vault or network-token strategy.

The architecture should reflect the actual scale and complexity of the merchant.

Read our Payment Orchestration guide for more information.

Does every business need network tokenisation?

Not necessarily.

For many smaller businesses, tokenisation will be handled by the payment provider without the merchant needing to design or manage the underlying token infrastructure itself.

It becomes particularly worth understanding when a business has:

• a large card-on-file customer base
• subscriptions or recurring payments
• high volumes of repeat customers
• multiple payment providers
• multiple acquirers
• international payment requirements
• high levels of avoidable card declines
• a requirement to reduce dependency on one processor
• plans to change or restructure its payment stack.

The merchant does not necessarily need to become a tokenisation expert.

It does need to ask its providers the right questions.

Questions to ask your payment provider about tokenisation

• Do you support network tokenisation or only your own gateway tokens?
• Which card networks do you support for network tokenisation?
• Who acts as the token requestor?
• Do you support network tokens for card-on-file and recurring payments?
• How is credential lifecycle management handled?
• What happens when the customer's underlying card expires or is replaced?
• Do you use an account-updater service as well?
• Can network tokens be used across more than one acquirer?
• What happens to our tokens if we change processor?
• Can stored payment credentials be exported?
• Would tokens need to be reprovisioned if we moved provider?
• Are there additional charges for network tokenisation?
• How do you measure authorisation performance for tokenised transactions?

For businesses with a significant stored-card portfolio, these questions can be just as important as the headline transaction rate.

Network tokenisation and agentic commerce

Tokenisation is also becoming increasingly relevant as payment technology moves towards AI-assisted and agent-led commerce.

An autonomous purchasing agent cannot safely be given unrestricted card credentials every time it needs to make a payment.

Tokenised payment credentials can instead provide a mechanism for limiting how payment credentials are used within defined environments and use cases.

This is an emerging area and payment networks are developing new token-based approaches specifically for agent-led commerce.

We explore the wider concept in Why Agentic Commerce Requires Multi-Tokenisation.

What changed in the EMV tokenisation standard in 2026?

EMVCo continues to develop the technical framework underlying payment tokenisation.

In July 2026, EMVCo published version 2.4 of the EMV Payment Tokenisation Specification – Technical Framework.

The framework defines the roles, functions and technical requirements that allow EMV Payment Tokens to operate within the existing payments ecosystem.

For merchants, the important point is that network tokenisation is not simply a feature invented by individual gateways. It forms part of an interoperable industry framework maintained by EMVCo and implemented by card networks and payments businesses.

View the current EMV Payment Tokenisation framework.

How Merchant Advice Service helps with tokenisation and payment infrastructure

Tokenisation often becomes relevant when a business is reviewing a wider payment problem rather than looking for tokenisation in isolation.

Merchant Advice Service can help businesses understand requirements involving:

• payment gateways
• stored cards
• recurring payments
• network tokenisation
• gateway and processor tokens
• payment-provider migration
• multiple acquirers
• payment orchestration
• international payments
• complex payment integrations.

The appropriate setup depends on how the business currently takes payments and what it is trying to achieve.

A merchant considering a new gateway can also read our Best Payment Gateways for UK Businesses guide.

About Merchant Advice Service

Merchant Advice Service is a UK business-to-business payments information, comparison and provider-matching service.

Founded in 2016, MAS helps businesses understand their payment requirements and identify payment providers or specialist partners that may be relevant to the way they operate.

We provide information and support across areas including:

• merchant accounts
• payment gateways
• integrated payments
• higher-risk merchant accounts
• international acquiring
• multiple currencies
• specialist payment integrations
• more complex provider requirements.

Merchant Advice Service is not an acquiring bank or payment processor and does not make final underwriting decisions.

The MAS information, matching and introduction service is free to businesses. MAS may receive commission or a referral fee from some commercial partners where an introduction results in a completed product or account.

For full information about how our service operates, provider matching, independence and commercial relationships, read How Merchant Advice Service Works.

Find Your New Processor

Sources and methodology

This guide was reviewed and updated in August 2026 using primary payments-industry sources.

EMVCo — EMV Payment Tokenisation

EMVCo's current information and technical framework explaining EMV Payment Tokens, token domains and the role of payment tokenisation throughout the transaction.

EMVCo: EMV Payment Tokenisation

Visa — Visa Token Service

Visa information covering network tokenisation, authorisation performance, fraud, token usage and Visa Token Service.

Visa: Visa Token Service

Visa — Merchant Tokenisation

Visa material covering network tokens, processor independence, credential lifecycle management and merchant use cases.

Visa: Merchant Tokenisation

Mastercard — Network Tokenisation

Mastercard information and research covering network-tokenised ecommerce transactions and payment-performance data.

Mastercard: Network Tokenisation

PCI Security Standards Council

PCI SSC guidance explaining the treatment of EMV Payment Tokens and the circumstances in which PCI DSS continues to apply.

PCI SSC: EMV Payment Tokens and PCI DSS

Editorial and commercial disclosure

Merchant Advice Service is an independent payments information, comparison and provider-matching service.

Our editorial content may reference payment providers, card networks, technology companies and financial institutions regardless of whether Merchant Advice Service has a commercial relationship with them.

Where organisations are named for research or technical examples, inclusion does not constitute a recommendation and should not be taken to mean that Merchant Advice Service can introduce businesses to that organisation.

Visa, Mastercard, EMVCo and the PCI Security Standards Council are referenced in this article as primary sources for payment-tokenisation standards, network information, research and security guidance.

MAS may receive commission or a referral fee from some commercial partners where a business chooses to proceed following an introduction. Commercial relationships do not determine which organisations may be referenced within our independent educational content.

Organisations have not paid for inclusion in this article unless explicitly stated.

Tokenisation support, implementation, pricing, portability and network availability vary between payment providers and can change over time. Businesses should confirm the current technical position with their provider.

Statistics quoted from Visa and Mastercard relate to the specific datasets and methodologies published by those organisations and should not be interpreted as guaranteed results for an individual merchant.