What Is Tokenization? Vault Tokens, Network Tokens and PCI Scope (2026)

Tokenization in payments is the replacement of a card’s primary account number (PAN) with a substitute value, the token, that has no use outside a defined context. The real number is stored in a secure vault, and only the token travels through checkout, storage and recurring billing, which limits what a data breach can expose.

In 2026, tokenization has moved from a security option to the default for card-not-present payments. Card schemes push network tokens with better approval rates, PCI DSS rewards systems that never touch the PAN, and platforms that work with several acquirers need tokens they can keep when they switch provider. For PSPs, PayFacs and platforms, the type of token they hold now shapes their costs, their conversion and their freedom to route.

What is tokenization in payments?

Tokenization is the process of replacing sensitive card data with a surrogate value that can be mapped back to the original only by the system that issued it. The PCI Security Standards Council tokenization guidelines describe the token as a substitute for the PAN that reduces the number of systems where card data is present. The industry framework for scheme-level tokens is the EMV Payment Tokenisation Specification published by EMVCo.

Several roles and notions come with it:

• Token vault: the secure database that holds the mapping between each token and its PAN.
• Token service provider (TSP): in the words of a Federal Reserve Bank of Boston paper, a role “authorized by a Token Program to provide payment tokens”. Visa and Mastercard run their own TSPs.
• Token requestor: the entity that asks the TSP for tokens, typically a merchant, a PSP acting for merchants or a wallet.
• Detokenization: the step where the token is turned back into the PAN so that the issuer can authorize the payment.
• Cryptogram: a one-time code generated for each network token transaction, which proves the token is used by its legitimate requestor.

A token is not encryption. An encrypted PAN can be decrypted by anyone holding the key. A token has no mathematical link to the PAN: without access to the vault, it reveals nothing. Tokenization is also older than it looks. Merchant and gateway vaults appeared in the 2000s to shrink PCI DSS audits, and EMVCo published its first payment tokenisation framework in 2014, when mobile wallets needed a way to put cards on phones without copying the card number. Since then, the scheme model has spread from wallets to every stored credential. Our episode on network tokens focuses on the scheme-level model; this one covers tokenization as a whole.

Vault tokens vs network tokens: what is the difference?

Vault tokens protect stored card data inside one provider. Network tokens replace the card number across the whole payment chain, up to the card scheme. The two coexist in most stacks.

• Vault token (also called PSP, acquirer or security token): created by a PSP, gateway or merchant vault. It is only meaningful to the system that created it. The PAN is still sent to the acquirer and the scheme at authorization.
• Network token (also called scheme or EMVCo token): issued by the card scheme’s TSP with the issuer’s approval. It is bound to one token requestor, sometimes to one merchant, and each payment carries a fresh cryptogram. The PAN is not exposed to the merchant, the PSP or the acquirer.
• Device token: a network token provisioned to a phone or watch by a wallet such as Apple Pay or Google Pay. See our episode on Xpay wallets.
• Lifecycle: a vault token goes stale when the card expires or is replaced. A network token is updated by the scheme when the issuer reissues the card.
• Portability: a vault token cannot leave its vault without a migration of the underlying PANs. A network token is tied to the token requestor, so it follows the operator that requested it, not the acquirer.

In short, the vault token answers “where is the card number stored?”, and the network token answers “which card number travels on the network?”. Most platforms use a vault for their own storage and request network tokens for the payments they send.

How does tokenization work?

For a network token, the process involves the merchant, its PSP, the scheme and the issuer. It starts when a shopper saves a card.

1. Card entry: the shopper enters the card in a checkout hosted by the PSP. The PAN goes straight to a PCI-compliant vault, and the merchant receives a vault token.
2. Token request: the PSP, acting as token requestor, sends the PAN to the scheme’s TSP and asks for a network token for this merchant.
3. Issuer approval: the TSP asks the issuer, identified from the BIN, to approve the token. The issuer can run its own checks.
4. Provisioning: the TSP returns the network token, its expiry date and a Payment Account Reference (PAR), a stable identifier that links all tokens of the same card.
5. Payment: at each purchase, the PSP requests a cryptogram and sends the token and cryptogram to the acquirer.
6. Detokenization: the scheme checks the cryptogram, swaps the token for the PAN and forwards the authorization to the issuer.
7. Response and updates: the issuer approves or declines. When the card is later reissued, the scheme updates the token’s link to the new PAN, and the stored token keeps working.

Tokenization in numbers (2026)

Scheme figures show how fast network tokens have become the norm for online card payments.

• 35% less fraud: Visa reports that tokenization led to a 35% reduction in e-commerce fraud rates compared with non-tokenized transactions, based on 2024 data, in its article on security at network scale.
• Nearly 5 percentage points: the increase in authorization rates Visa attributes to tokenized transactions, in the same April 2026 article.
• More than half: the share of e-commerce transactions on Visa’s network that were already tokenized in late 2025, while manual card entry fell to 16% of Visa e-commerce transactions, from 44% in 2019, according to Payment Expert.
• 2030: the date by which Mastercard aims for 100% e-commerce tokenization in Europe, a goal set out in its June 2024 announcement, together with the end of manual card entry.
• PCI DSS v4.0.1: the current version of the card data security standard, available in the PCI SSC document library, under which systems that never store, process or transmit the PAN can fall outside the assessment scope.

What are the risks and limits of tokenization?

Tokenization reduces exposure, but it does not remove every risk. The limits are mostly operational.

• Vault lock-in: vault tokens belong to their provider. Moving to another PSP requires a PAN migration between PCI-compliant parties, which takes planning and cooperation from the old provider.
• Partial coverage: not every issuer, card type or region supports network tokens. A platform still needs a fallback for cards that cannot be tokenized.
• Scope is reduced, not removed: the systems that capture the card, host the vault or call the detokenization service stay in PCI DSS scope.
• Token sprawl: one card can have several network tokens, one per requestor or merchant. Without the PAR, a platform may not see that two tokens belong to the same shopper, which weakens fraud checks and analytics.
• Fees and integration: schemes may charge for token provisioning and cryptograms, and each TSP has its own API.
• Not a fraud cure: a stolen device or a compromised account can still produce valid tokenized payments. Authentication and fraud rules still apply.

Tokenization: what changes for PSPs, PayFacs and platforms

For an operator, tokenization is an architecture decision. It decides who owns the card relationship and how freely payments can move. Five areas matter most.

Compliance and PCI scope

A platform that lets the PSP vault capture the card and only stores tokens can keep most of its systems out of PCI DSS scope. The choice between a hosted form and a direct integration decides the questionnaire, as explained in PCI DSS SAQ A vs SAQ D.

Routing and portability

A token that works with one acquirer only limits multi-acquiring. Operators that hold network tokens as token requestor, or a vault they control, can send the same stored card to several acquirers through routing rules. When a migration is needed, the steps are covered in why migrating tokens doesn’t have to be complicated.

Authorization performance

Network tokens are updated when cards are reissued and carry a cryptogram, which issuers trust more than a bare PAN. Fewer “expired card” declines and fewer false fraud declines translate into higher approval rates on subscriptions and saved cards. The operating gains are discussed in efficiency meets tokenization.

Reconciliation and data

A token is not a card number, so reporting must not depend on the PAN. The PAR and the BIN remain available and let operators link transactions to a card and to its issuer without storing sensitive data. In NORBr, network tokenization is part of the platform, and operators can use network tokens across the payment providers connected to their stack.

Disputes and fraud

Tokens change the evidence trail. A network token transaction carries a cryptogram and a token requestor identifier, which helps show that a payment came from the legitimate merchant. Fraud teams, however, lose the PAN as a matching key. They need the PAR, the BIN and the device or account data to link several payments to the same card, to apply velocity rules and to answer a chargeback with the right history. Operators should check that their fraud tools and dispute workflows accept tokens as input before they switch stored cards to network tokens.

Market rules

Some regulators have made tokenization compulsory for stored cards. In India, merchants may no longer keep card numbers on file, which made network tokens the norm for domestic e-commerce, as the guide to payment methods in India explains.

For the rules that apply once a token is stored, the Payments Library lists Card-on-File Done Right: how to stay compliant with the stored credential mandate. The #TheShot episode Full data access: a competitive edge explains why owning card data, in tokenized form, matters to operators.

Is tokenization worth it in 2026?

Yes, for every player that stores cards or runs recurring payments. The right model depends on the role:

• PSPs: request network tokens as token requestor for their merchants and keep a vault for cards that cannot be tokenized.
• PayFacs: use tokens to cut PCI scope and to keep sub-merchant card data under their control, not their acquirer’s.
• ISOs: check who owns the tokens in each acquirer contract before signing, because it decides whether merchants can move.
• ISVs and platforms: choose an integration where the card never touches their servers, and ask for network tokens on stored credentials to protect subscription revenue.

Tokenization replaces the card number with a value that is useless outside its context, and operators who control their tokens keep both the security benefit and the freedom to route payments where they perform best.