Payment Tokenization: How It Works and Why Businesses Need It

Payment tokenization replaces a card's primary account number (PAN) with a substitute value called a token. The token can be stored and reused by a merchant, but it carries no exploitable relationship to the real card number, so a stolen token is of little use on its own.

That's the whole idea, and it's why the technique sits underneath card-on-file billing, Apple Pay, Google Pay and most contactless payments you'll make this month.

This guide walks through the mechanics with a concrete example, separates the gateway tokens most merchants meet first from the network tokens issued by Visa and Mastercard, and covers what the Reserve Bank of India actually requires today. It also untangles three unrelated things that share the word "token".

Payment tokenization is the substitution of a sensitive card value with a surrogate value that has no exploitable mathematical relationship to the original, used to complete a transaction without exposing the real card number.

That definition comes from the PCI Security Standards Council's own tokenization guidance. EMVCo, the standards body behind the network specifications, frames it in blunter terms: tokenisation replaces "the most valuable data to a fraudster, the primary account number (PAN)" with "a unique alternative value".

Two properties do the actual work.

• Substitution, not transformation - the token isn't derived from the PAN by a formula. It's a value assigned to the PAN and recorded in a lookup table.
• Domain restriction - a token is normally bound to a specific merchant, device or channel, so a token lifted from one context can't be replayed in another.

A quick warning before you go further. "Tokenization" also describes blockchain and real-world-asset tokenisation, and separately describes tokenized bank deposits. Three different concepts, one word. The trends section sorts them out.

The process runs the same way whether you're saving a card for a subscription or tapping a phone at a till. Five stages, drawn from EMVCo's tokenisation framework and PCI SSC's guidance.

• Capture - the cardholder enters their PAN at checkout, or agrees to save the card on file.
• Token generation - a Token Service Provider (TSP) generates a token bound to that specific merchant, device or channel.
• Vault storage - the TSP or gateway records the PAN-to-token mapping in a segmented, PCI DSS compliant token vault.
• Merchant storage - the merchant's systems keep the token, usually alongside a masked last four digits. The PAN itself is never stored there.
• Detokenisation at authorisation - at transaction time the token is mapped back to the real PAN inside the vault, and it's the PAN that the issuer authorises.

A Worked Example

Here's what that looks like with actual values. The card number and token below are illustrative, chosen to show the mechanism rather than copied from any live processor.

A customer pays with card 4111 1111 1111 1234 and ticks "save this card".

The gateway sends the PAN to its TSP. The TSP returns 4241 8823 5567 1234. Same sixteen digits, same format, and the last four digits are deliberately preserved so the customer still sees "card ending 1234" on a receipt.

Everything between the first digit and those last four has been randomly generated. There's no key, no algorithm and no amount of computation that turns 4241 8823 5567 1234 back into the original card. The only route back is a lookup inside the vault.

Your database now holds the token. When the subscription renews next month, your system charges the token, the gateway swaps it for the PAN inside the vault, and the issuer approves or declines against the real card. The merchant environment never sees the PAN again.

Note that many tokens are format-preserving and deliberately pass a Luhn checksum, so they slot into systems built to accept card numbers without rewriting validation logic. Vendor token-format documentation, such as Worldpay's, describes both variants: one that retains the original last four digits and one that randomises everything except the checksum digit.

The security case for payment tokenization is straightforward. In a correctly scoped deployment, PAN data never touches merchant systems, so a breach of the merchant's database yields tokens rather than usable card numbers.

The compliance case needs more care than most vendor pages give it. PCI SSC's own wording is that tokenization "may simplify a merchant's validation efforts by reducing the number of system components for which PCI DSS requirements apply", but "does not eliminate the need to maintain and validate PCI DSS compliance".

Read that twice if you're scoping an audit. Fewer systems in scope is a real saving. Zero obligations is not what's on offer, and any vendor implying otherwise is overselling. The detail of how scope gets drawn belongs in a proper walkthrough of PCI DSS compliance for SaaS.

The current standard is PCI DSS v4.0.1. As of 31 March 2025, the 51 requirements that were previously future-dated are all mandatory in assessments, so a scoping exercise done against v4.0 assumptions is out of date.

Two further benefits are worth naming plainly:

• Card-on-file convenience - repeat customers and subscribers don't re-enter card details, because the merchant holds a reusable reference.
• Narrower blast radius - a token compromised in one merchant context can't generally be used in another, thanks to domain restriction.

Authorisation-rate improvement from network tokens is widely claimed across the industry. We aren't printing a figure, because the percentages in circulation (2 to 3%, 4%, 4.6%) trace back to different secondary sources with no consistent primary citation.

Tokenisation also doesn't make a payment system unbreakable. The vault becomes the concentrated target, account-takeover and social-engineering fraud are untouched by it, and a compromised merchant session can still be abused in real time.

Four roles appear in almost every deployment, and knowing which party plays which one tells you where your risk actually sits.

• PAN - the primary account number being protected.
• Token requestor - the entity asking for a token: a merchant, a wallet provider, or a gateway.
• Token Service Provider (TSP) - the entity authorised to issue tokens, hold the mapping and manage the token's lifecycle. EMVCo assigns TSP Codes so that every provider is, in EMVCo's words, "uniquely identifiable on a global basis".
• Token vault - the segmented system holding the PAN-to-token mapping. It must itself be PCI DSS compliant, and nothing outside the cardholder data environment should be able to reach it.

The roles are defined in the EMV Payment Tokenisation Specification Technical Framework.

Payment tokenization deployments then split into three broad types: tokens issued by a gateway, tokens issued by a card network, and tokens provisioned to a device such as a phone or watch.

Gateway Tokenization

Gateway tokenization is the version most merchants encounter first, because it arrives bundled with the payment gateway or payment service provider (PSP) you've already signed with. The gateway runs its own vault, issues its own tokens, and hands you a reference string to store.

It's easy to adopt. There's no separate integration, no network onboarding, and the merchant's card-handling scope shrinks immediately.

The catch is portability. A gateway's token is meaningless outside that gateway's vault, so switching providers usually means either a vault-to-vault migration negotiated with your outgoing provider, or asking every customer to re-enter their card. For a business with a large card-on-file base, that's a genuine commercial constraint, and it's worth raising during procurement rather than at renewal.

Gateway tokens also don't know anything the gateway wasn't told. When a customer's card is reissued after loss or expiry, the stored token points at a PAN that no longer authorises, and recovery depends on whatever account-updater service your provider offers.

Device-Based Tokenization

When a card is added to Apple Pay, Google Pay or a smartwatch, a token is provisioned to that specific device rather than to a merchant. The device presents the token at the terminal, and the physical card's PAN never enters the transaction. This is a network-issued token in practice, scoped to the device.

Two comparisons cause most of the confusion here. The first sets payment tokenization against encryption. The second separates the gateway tokens above from tokens issued by the card networks themselves.

Tokenization Versus Encryption

Both protect card data, and most real architectures use both. This table sets out where they differ, following PCI SSC's tokenization guidance.

The practical consequence sits in the first row. Ciphertext contains the original data, mathematically embedded and recoverable by whoever holds the key, which makes key management the critical control. A token contains nothing, so the vault is the control.

They're complementary rather than alternatives. Encrypt in transit, tokenise at rest, and treat the two as separate exercises.

Gateway Tokens Versus Network Tokens

Network tokens are issued by the card networks directly, under named programmes: Visa Token Service (VTS), Mastercard Digital Enablement Service (MDES), and American Express Tokenization Service. Amex describes its service as "a suite of solutions that includes a token vault, payment token issuing and provisioning, token lifecycle management, and risk services", available to issuers, acquirers and merchants on its network.

That third row is the one that matters most for recurring billing. A card expires or gets reissued, and a network token keeps working without the merchant or the customer doing anything, which removes a common cause of involuntary subscription churn.

Payment tokenization shows up in five places most often, and the mechanism differs slightly in each.

• Card-on-file and recurring billing - the merchant stores a token instead of the PAN for subscription and repeat charges. This is the core case behind RBI's mandate, and PCI SSC's primary scope-reduction example.
• Subscription billing - mechanically the same as card-on-file, with the added dependency on the token surviving card reissue.
• Wallet and device provisioning - Apple Pay, Google Pay and Samsung Pay transactions typically run on an EMV payment token provisioned to the device.
• In-store contactless - a token held on a phone or watch is presented at the point of sale in place of the physical card's PAN.
• Click to Pay - an EMVCo-initiated one-click checkout standard that removes manual card entry using a tokenised card on file.

If your interest is the broader control set around these flows rather than tokens specifically, our payment security guide covers that ground.

India regulates payment tokenization more prescriptively than most markets, and the rules have moved since the original mandate.

The framework began with RBI's September 2021 press release extending the January 2019 device-tokenisation framework to Card-on-File Tokenisation (CoFT). Two commitments in that release still define the model: card issuers were permitted to act as Token Service Providers, and tokenisation "shall be done with explicit customer consent requiring Additional Factor of Authentication (AFA)".

The purge deadline moved twice. An RBI circular dated 31 March 2021 pushed it to 30 June 2022, and a further extension took final effect to 1 October 2022.

The December 2023 Issuer-Enabled Update

The change many pages still miss came in RBI/2023-24/91, CO.DPSS.POLC.No.S-919/02-14-003/2023-24, dated 20 December 2023. It's a December 2023 circular, not a 2024 one, though most coverage of it landed in 2024.

It allows card-on-file tokens to be generated directly through the card issuing bank, using mobile banking and internet banking channels, with explicit customer consent and AFA validation. A single AFA can cover multiple merchants selected in one session.

So a cardholder can tokenise a card for several merchants from their banking app, instead of doing it merchant by merchant at each checkout.

What Merchants May Still Store

After the purge deadline, merchants and payment aggregators may not retain the actual PAN or CVV. What they may keep is the token, the name on the card, the last four digits, and the card network or issuer name for reference.

CoFT governs how RBI-regulated entities handle card data. Research did not find an RBI sentence directly addressing cross-border scope, so treat any claim about foreign acquirers cautiously.

One 2026 development is worth separating out clearly. RBI has been reported to mandate two-factor authentication for all digital payments from 1 April 2026. That's a broad authentication requirement, not a CoFT change, and it shouldn't be described as one.

Two directions are real and citable. A third is mostly noise, and it's worth saying so.

Wallets And Click To Pay

Wallet provisioning remains the largest consumer-facing use of network tokens, and it keeps growing as more issuers enable it. Click to Pay, EMVCo's one-click checkout standard integrated across the major schemes, extends the same tokenised card-on-file model to browser checkout without a wallet app.

Blockchain Tokenization Is A Different Thing

Blockchain and real-world-asset tokenisation means creating an on-chain digital representation of an asset such as equity, a bond or property, which can then be transferred or used as collateral. It's about representing ownership. Card tokenisation is about protecting a payment credential. The two share a word and very little else.

We checked whether the two are genuinely converging, because plenty of content asserts they are. What turned up was vendor and consultancy commentary (Chainlink, PYMNTS) describing possible future integration, not a live standard or a network-confirmed mechanism. Treat the convergence story as positioning for now.

Tokenized deposits are a third meaning again: a bank deposit represented as a token on a ledger. That's monetary infrastructure, not card security, and we cover it separately in our tokenized deposits explainer.

Payment tokenization is a mature, well-specified control, and for card-on-file and wallet flows it's effectively the default. Three things decide whether a given implementation is any good.

• Who holds the vault - gateway or network, because that determines your portability and your reissue behaviour.
• How honestly the scope reduction is described - PCI DSS obligations shrink, they don't disappear.
• Whether the India-specific rules are current - the operative CoFT mechanic is the December 2023 issuer-enabled path, not the 2022 baseline alone.

For transparency: Xflow handles inbound cross-border payments rather than card checkout, and doesn't tokenise PANs. Its own security posture is ISO 27001 and SOC 2 certification, set out in the announcement that Xflow achieves SOC 2 and ISO compliance certification.