Network Tokenisation for Payments Guide: How Card Network Tokens Work and When to Use Them

A stored card number is valuable to anyone who steals it, and it quietly stops working every time the card expires or is replaced. Network tokenisation replaces the card number (PAN) with an EMV payment token issued through the card network's token service, restricted to one merchant, device or channel, and kept up to date by the network when the card changes. This explainer covers what network tokens are, how provisioning, cryptograms and lifecycle updates work, what they do and do not change for PCI DSS scope and fraud, and the misconceptions that cause failed projects. It is for payments, fraud and security teams at merchants, platforms and payment service providers. General data tokenisation, vaults and masking are covered in the Tokenisation and Data Masking Guide, which this page does not repeat.

Key takeaways

• A network token is a domain-restricted card credential. EMVCo describes the EMV payment token as an alternative value to the PAN that is constrained in how it can be used, for example to a specific merchant, device or payment scenario.
• Each transaction carries a cryptogram. The token alone is not enough to pay: the network produces a cryptogram per authorisation tied to the token, the merchant and the transaction, which makes stolen tokens far less useful.
• The network updates the token when the card changes. When a card expires or is replaced, the scheme updates the details behind the token, so card on file payments keep working without the customer re-entering anything.
• Tokens that can initiate payments are still high value. PCI SSC warns that tokens usable as payment instruments may be as valuable to an attacker as the PAN and need fraud controls; network tokens reduce exposure but do not remove the need to protect the charge path.
• Check scheme programme changes. Mastercard has announced it will globally decommission MDES for Merchants effective 31 December 2026, with integrators moving to Secure Card on File.

What it is

Network tokenisation is the issuing of EMV payment tokens by a token service provider (TSP) operated by, or on behalf of, a card network or issuer. The token is a 16 to 19 digit value in the same format as a card number, so it flows through existing authorisation messages, but it maps back to the real PAN only inside the token service. EMVCo, the body that publishes the EMV specifications, maintains the EMV Payment Tokenisation Specification, Technical Framework; its site lists version 2.4, published on 9 July 2026, as the latest (checked 8 November 2026). EMVCo also assigns TSP codes so that each TSP issuing EMV payment tokens can be identified worldwide.

The two largest network token services are the Visa Token Service (VTS), which Visa describes as replacing sensitive card data with a unique digital identifier so payments can be processed without exposing account details, across online, in-store and in-app payments, and the Mastercard Digital Enablement Service (MDES). Mastercard's merchant card on file product is now Secure Card on File (SCOF), which its documentation describes as letting merchants, commerce platforms and payment service providers replace a cardholder's PAN with a token for e-commerce and in-app payments, a token that is specific to one card and one merchant. Mobile wallet tokens (a token stored on a phone) are network tokens too, restricted to that device.

How it works

Roles

• Token requestor: the entity that asks for tokens, such as a merchant, a payment service provider tokenising on behalf of merchants, or a wallet provider. It registers with the network and receives a token requestor identifier (TRID); token responses from processors carry this as a token requestor ID.
• Token service provider: the network or issuer service that issues tokens, keeps the token vault mapping tokens to PANs, generates or validates cryptograms and manages lifecycle.
• Issuer: the cardholder's bank, which approves token provisioning, sees token transactions and can suspend or delete tokens.
• Acquirer and processor: pass the token and cryptogram in the authorisation; the network detokenises before the issuer authorises.

Flow

1. Enrol: the customer saves a card. The token requestor sends the PAN to the TSP, directly or through its payment provider. Checkout.com documents that provisioning can be asynchronous (the first payment uses the PAN while the token is created) or synchronous (the payment waits for the token).
2. Issuer approval: the issuer approves or declines provisioning, often using risk data supplied with the request.
3. Store: the token requestor stores the network token, usually in its provider's vault, and can delete the PAN if it no longer needs it.
4. Pay: for each payment the requestor obtains a cryptogram (Mastercard's SCOF Checkout API returns token details and a cryptogram; Checkout.com describes a per-authorisation cryptogram tied to the token, merchant and transaction) and sends both in the authorisation.
5. Detokenise and authorise: the network validates the cryptogram and domain restriction, maps the token back to the PAN and passes it to the issuer for its decision.
6. Lifecycle: when the card is reissued, expires, is suspended or closed, the network updates or suspends the token and notifies the requestor. Mastercard SCOF sends card notification events about card details, PAN expiration and account suspension; Checkout.com exposes the same updates as webhooks.

Domain restrictions and cryptograms

A token is bound to a domain: a token requestor, a channel (e-commerce, contactless) or a device. A token copied from one merchant's database fails at another merchant. The cryptogram is a one-time value calculated with keys held by the token service or device, so a captured token plus an old cryptogram cannot be replayed. For recurring merchant-initiated payments, scheme rules set when a cryptogram is required; check your acquirer's guidance rather than assuming every transaction needs one.

Why it matters

Network tokens also complement, rather than replace, other controls. EMV 3-D Secure authenticates the cardholder at enrolment or high-risk payments; tokens protect the stored credential afterwards. See the EMV 3-D Secure Guide and the Payment Fraud Guide.

Effect on PCI DSS scope

The PCI SSC Tokenization Guidelines Information Supplement (version 2.0) sets the principle: systems holding only tokens can fall out of scope only where the PAN cannot be recovered from the token even if the token and its host systems are compromised, and where they are segmented from the tokenisation system, the vault and anyone who can detokenise. It also warns that tokens usable as payment instruments ("high-value tokens") may be as valuable to an attacker as the PAN, may need additional fraud controls, and may be in scope even if they cannot retrieve the PAN; merchants should ask their acquirer or payment brands. In practice:

• Using a provider's vault: if the PAN is captured on a provider-hosted field and you only ever hold network tokens, your scope shrinks to the payment page and integration, but it does not disappear. See the PCI DSS Scoping and Network Segmentation Guide and the PCI DSS for E-commerce Payment Page Scripts Guide.
• Acting as your own token requestor: you receive the PAN to provision, so the provisioning path and any PAN fallback stay fully in scope.
• Keeping PAN as fallback: many integrations retry with the PAN if a token payment fails. Checkout.com documents an automatic retry with the full PAN for certain decline codes. If you keep PANs for fallback, you keep their scope.

Implementing network tokens

1. Inventory stored cards: where PANs, provider tokens and network tokens live today, and which flows use them (one-click, subscriptions, refunds, customer service).
2. Choose the integration route: through your payment provider (fastest, provider is token requestor) or as a direct token requestor (more control, more scope and certification work). Large merchants with several acquirers often want tokens that are portable across processors; Checkout.com, for example, offers a cryptogram endpoint for using a token at another acquirer.
3. Pilot on new cards: provision tokens for new card saves in one market, compare approval rate, decline codes and cost against PAN.
4. Migrate the back book: bulk-provision tokens for existing stored cards, handle cards the issuer declines to tokenise, and keep the PAN path only where needed.
5. Handle lifecycle events: subscribe to notifications, update the displayed card (last four digits and expiry from the token metadata), and stop charging suspended or deleted tokens.
6. Retire PANs: delete stored PANs once tokens are proven, and re-scope with your assessor.
7. Plan rollback: keep a feature flag to revert to provider tokens or PAN processing for a market or issuer if approval rates fall, and monitor daily during migration.
8. Track scheme changes: Mastercard M4M integrators must move to SCOF and migrate tokens before 31 December 2026.

Common misconceptions

• "Tokens remove us from PCI DSS." They reduce scope. The page that captures the card, any PAN fallback and the provisioning path remain in scope, and payment-capable tokens can still be in scope.
• "A token is worthless if stolen." It is worth less: domain restrictions and cryptograms block use elsewhere, but an attacker inside your platform can still charge stored tokens. Protect the charge path, refund path and admin access, and watch for abuse. See the Card Testing and Carding Attacks Defence Guide.
• "Network tokens and gateway tokens are the same." A gateway token is a reference to a PAN in the provider's vault and works only with that provider; a network token is a card credential issued by the network and recognised by the issuer.
• "Account updater does the same job." Account updater services push new card details to the merchant in batches or on request; token lifecycle updates happen behind the token, so the merchant never handles the new PAN.
• "Every card can be tokenised." Issuer participation varies by market and card type, and provisioning can be declined, so plan for a mixed estate.
• "Click to Pay is the same as tokenisation." EMV Secure Remote Commerce, branded Click to Pay, is a checkout specification (EMVCo lists v1.6 as current). EMVCo presents payment tokenisation as a technology that can be combined with it, not as the same thing.

Related concepts

• Machine credentials around tokens: the API keys, mutual TLS certificates and webhook secrets that request tokens and cryptograms are themselves high-value non-human identities. Mastercard's SCOF notifications require mutual TLS with certificates from its Key Management Portal. Treat these credentials as you would PAN access. See the Payment API keys beyond Stripe and the Payment Gateway Integration Security Guide.
• Agentic and delegated payments: scheme programmes for AI agents that buy on a user's behalf build on network tokens with tighter controls. See the Agent Payments Protocols Guide.
• PCI DSS 4.0: requirements for stored account data and scope. See the PCI DSS 4.0 Guide.

Practitioner checklist

• Measure token coverage: Track the share of stored cards held only as network tokens and list every remaining PAN storage location.
• Send the cryptogram: Obtain a cryptogram for each payment and send it with the token, checking your acquirer's guidance on when merchant-initiated payments need one.
• Handle lifecycle events: Consume the network's card update and suspension notifications or webhooks so card on file payments keep working after expiry or reissue.
• Protect the charge path: Treat tokens that can initiate payments as high value and keep fraud controls on them, as PCI SSC warns they may be as valuable as the PAN.
• Review PAN fallback: If you retry failed token payments with the PAN, recognise that keeping PANs for fallback keeps that storage in PCI DSS scope.
• Confirm scope with your acquirer: Ask your acquirer or the payment brands how high-value tokens affect your PCI DSS scope rather than assuming they remove it.
• Track scheme changes: Plan for Mastercard decommissioning MDES for Merchants on 31 December 2026 and the move to Secure Card on File.
• Compare approval and decline rates: Measure authorisation approval rates for tokens versus PANs, and declines for expired or replaced cards before and after tokenisation.

Standards and references

• EMVCo: EMV Payment Tokenisation
• PCI SSC: Tokenization Guidelines Information Supplement
• EMVCo: EMV Secure Remote Commerce
• Visa Developer: Visa Token Service
• Mastercard Developers: Secure Card on File
• Mastercard Developers: MDES Digital Enablement
• Checkout.com Docs: Network Tokens

Related NHI Mgmt Group resources: Tokenisation and Data Masking Guide · PCI DSS 4.0 Guide · EMV 3-D Secure Guide · Payment Fraud Guide · Lending and BNPL Fraud Guide