Payment tokenization replaces a card number with a random surrogate value called a token. The original card number is stored once in a secure vault; every other system in the flow handles the token instead. If the token is stolen, it has no value outside the system that issued it.

That’s the core mechanism. The complexity lies in the details: there are three distinct types of tokens with different architectures, different security properties, and different implications for PCI DSS scope. Getting that taxonomy right matters when you’re deciding whether to rely on your PSP’s built-in tokenization, build your own vault, or use network tokens.

What is tokenization?

Tokenization is the process of substituting a Primary Account Number (PAN) with a token, a string that looks like a card number but has no mathematical relationship to it. Unlike encryption, which transforms the PAN into ciphertext that can be reversed with a key, a token is just a lookup index. The only way to get back to the real card number is to ask the vault that holds the mapping.

The PCI Security Standards Council defines tokenization as creating a surrogate value that has “no exploitable meaning or value.” That’s the formal bar for a token to actually count for PCI DSS purposes: it cannot be reverse-engineered, and it cannot be used to process a payment anywhere except through the original vault.

Tokenization has been adopted at scale. Visa had issued 10 billion tokens by June 2024, generating $650 million in fraud savings in the prior 12 months (Visa press release, June 2024). Juniper Research estimated 283 billion network-tokenized transactions globally in 2025, forecast to reach 574 billion by 2029 (Juniper Research, January 2025).

How payment tokenization works

The flow has four steps:

1. Card entry. The cardholder enters their card number in a payment form. For scope reduction to work, this form must be hosted by the tokenization provider (via an iframe or hosted fields), not your server. If the card number touches your server before tokenization, those servers are in PCI scope.

2. Vault assignment. The tokenization service receives the PAN, generates a random token, and stores the PAN → token mapping. The token is returned to your system. Your system never sees the PAN.

3. Token use. Your system stores the token, passes it to your order management system, billing system, and anywhere else the “card number” would have gone. None of those systems see the real PAN.

4. Detokenization. When a charge is needed, your system sends the token to the vault. The vault looks up the PAN and sends it directly to the payment processor. The PAN travels from vault to processor; your system is not in that path.

Step 4 is where tokenization providers differ in practice. Some vault providers send the PAN from their servers to the processor (your system stays out of the flow). Others return the PAN to your server, which then forwards it to the processor. That approach doesn’t give you the same scope reduction.

Tokenization vs encryption vs masking

These three techniques get conflated because they’re all ways to protect card data, but they have different security properties:

	Tokenization	Encryption	Masking
Reversible?	Yes, by the vault only	Yes, by anyone with the key	No
Relationship to original	None (random lookup)	Mathematical (key-dependent)	Destroyed
Key exposure risk	Vault compromise	Key compromise	None
PCI scope impact	Reduces scope downstream	Reduces scope with key management controls	No downstream scope reduction
Use case	Card-on-file, repeat charging	Data in transit (TLS), data at rest	Display purposes only (showing last 4 digits)

Encryption protects data in transit (that’s what TLS does) and data at rest, but the decryption key has to exist somewhere, which means the key itself becomes an attack target. Tokenization removes the mathematical relationship entirely: the token is just a string your vault remembers. A compromised token is useless without access to the vault’s lookup table.

Masking replaces most of the card number with a placeholder (e.g., **** **** **** 4242). It’s for display only; you cannot charge a masked card number. It does nothing for systems that need to process transactions.

Types of tokens: vault tokens, network tokens, and format-preserving tokens

The “tokenization” umbrella covers three distinct mechanisms with different architectures and trade-offs. Choosing between them is an actual design decision, not just an implementation detail.

Vault tokens (gateway tokens / PCI tokens)

A vault token is generated by your tokenization provider or payment processor and stored in their lookup table. When you charge the card later, you pass the token to the same provider, which looks up the PAN and processes the charge.

The scope reduction is real: your downstream systems handle only tokens and fall outside PCI DSS cardholder data environment scope. But vault tokens have a portability problem. A token issued by PSP A cannot be used to process a transaction at PSP B. If you want to switch processors, or route transactions across multiple processors, you have to re-collect card data, which requires bringing your servers back into PCI scope during the migration.

This is the vendor lock-in risk specific to tokenization. The card vault becomes the moat.

Network tokens

Network tokens are issued directly by the card networks (Visa Token Service, Mastercard Digital Enablement Service) and have a different architecture than vault tokens.

The key difference: network tokens carry a per-transaction cryptogram. For Visa, this is a TAVV (Transaction Authentication Verification Value); for Mastercard, it’s a DSRP (Digital Secure Remote Payments) cryptogram. Each cryptogram is bound to the specific transaction’s amount, currency, and timestamp. If you intercept a network token, you cannot replay it; the cryptogram would fail validation at the issuer.

This is the mechanism behind the fraud reduction data. Visa reports a 4.6% authorization rate lift for tokenized card-not-present transactions versus raw PANs (Visa Risk Datamart, FY2022), and a 30% reduction in online fraud for network-token transactions (VisaNet data, Oct–Dec 2022). The lift isn’t from the token being “meaningless.” It’s from the cryptogram making replayed credentials worthless.

Network tokens also travel with the card, not with the vault. When a card is reissued after a breach or expiry, network tokens update automatically through the card networks’ account updater services. Vault tokens don’t do this. A reissued card means a new PAN, which breaks the old vault token.

Each card also has a Payment Account Reference (PAR), a stable identifier that persists across token requestors and card reissuances. If the same card generates tokens through multiple providers, the PAR links them. This matters for fraud analysis and for linking transaction history when a card is reissued.

Format-preserving tokens (FPE)

Format-preserving encryption (FPE) generates a token that looks exactly like a PAN: 16 digits, valid Luhn checksum. The token can flow through legacy systems that validate PAN format without modification.

FPE is vaultless. It uses a deterministic algorithm (typically FF1 or FF3-1 from NIST SP 800-38G) rather than a lookup table. The token is derived from the PAN and a secret key, which means it’s technically reversible by anyone with the key (making it encryption, not tokenization by PCI SSC’s strict definition). Whether FPE satisfies PCI DSS tokenization requirements depends on the specific QSA assessment and how the key management is implemented.

The practical use case: migrating systems that have PAN-format validation baked in and can’t easily be changed to accept random token formats. FPE lets the integration surface stay unchanged while the data flowing through it becomes unreadable without the key.

Token types at a glance

	Vault token	Network token	Format-preserving token (FPE)
Issued by	PSP or tokenization provider	Card network (Visa, Mastercard)	Your key management system
Portable across PSPs?	No	Yes	Yes (if key is shared)
Per-transaction cryptogram?	No	Yes (TAVV / DSRP)	No
Auto-updates on card reissue?	No	Yes	No
PCI DSS compliant?	Yes	Yes	Depends on QSA assessment
Main use case	Card-on-file with a single PSP	CNP fraud reduction, multi-PSP routing	Legacy system migration

What tokenization solves: PCI DSS scope reduction and card-on-file security

PCI DSS scope reduction

PCI DSS v4.0 Requirement 3.5.1 requires that PANs be rendered unreadable anywhere they’re stored. Tokenization is one of four acceptable methods (alongside truncation, hashing, and encryption).

The scope reduction depends on how you integrate. Under Orchestra’s Library integration, the JavaScript library handles card entry, and card data never touches your servers. This moves you from SAQ D (328 requirements) to SAQ A (31 requirements), roughly a 90% reduction in applicable requirements. The API integration path keeps card collection and PCI responsibility with you, in exchange for full UI control.

One thing every guide glosses over: the vault itself remains in PCI DSS scope. What tokenization does is shrink the scope for your downstream systems: the order management system, the billing system, the customer database. Those systems touch tokens, not PANs, so they fall outside the cardholder data environment. But the component that holds the PAN-to-token mapping (the vault) is still subject to PCI DSS. If you self-host a vault, those servers are in scope. If you outsource to a tokenization provider, the scope burden shifts to them, which is the point of using a provider.

Card-on-file security

Tokenization is what makes card-on-file subscriptions and one-click checkout secure. The merchant stores the token, not the PAN. If the merchant’s database is breached, the attacker gets a list of tokens that can only be used through the issuing vault, useless without access to the vault’s lookup table.

This is the dominant use case for vault tokens. Network tokens take it further by adding the cryptogram layer, which means even a stolen token-plus-card-number combination can’t be replayed without the per-transaction cryptogram.

When you need tokenization (and when your PSP already provides it)

Most PSPs tokenize by default. When you save a card with Stripe, Adyen, or Braintree, they issue a token on their own vault. For single-PSP setups, that’s sufficient. Your system stores the PSP’s token, and the PSP handles the vault.

The gap shows up when you route across multiple PSPs. A token issued by PSP A cannot be used to charge through PSP B. If a transaction needs to fail over to a backup processor, or if you want to route different transactions to different processors based on cost or approval rate, you need a layer that holds the real PAN (or a network token) and can present it to whichever processor is handling the transaction.

This is where payment orchestration and portable vault tokenization matter. Orchestra tokenizes cards in a vault that is not bound to any single gateway, so a card tokenized while routing through one gateway can be charged later through a different connected gateway. The token is portable across the provider set, which means you get multi-PSP routing without re-collecting card data.

For single-PSP setups, relying on your PSP’s built-in tokenization is fine. For multi-PSP setups, card vaults that depend on a specific gateway are a structural constraint on your routing flexibility.

How Orchestra handles tokenization across PSPs

Orchestra’s tokenization approach is designed around the multi-PSP routing problem:

• Both integration paths (the API and the Library) support tokenization, but with different scope implications. The Library path keeps card data off your servers entirely. The API path gives you UI control while keeping PCI responsibility with your organization.
• The vault is not bound to a specific gateway. A card tokenized in one transaction can be charged through a different connected gateway in a later transaction, without re-collecting card data.
• Network tokenization is supported where gateways and card networks support it. You get the authorization rate lift and fraud reduction from network tokens when the transaction path supports them.

The integration count across PSPs and payment methods is available live at orchestrasolutions.com/integrations/. New providers are added at no additional cost.

Frequently Asked Questions

What is tokenization in payments?

Tokenization replaces a card number with a randomly generated token that has no exploitable value outside the system that issued it. The original card data is stored once in a secure vault; every other system in the flow handles the token instead. A stolen token cannot be used to process a payment without access to the vault’s lookup table.

How is tokenization different from encryption?

Encryption transforms data reversibly with a key, so anyone with the key can recover the original value. A token has no mathematical relationship to the card number. It cannot be reversed even if the token itself is exposed. The vault holds a lookup table, not a key. Encryption protects data in transit and at rest; tokenization removes sensitive data from your systems entirely.

Does tokenization reduce PCI DSS scope?

Yes, for downstream systems. If your systems only ever touch tokens and never store, process, or transmit the actual PAN, those systems fall outside PCI DSS cardholder data environment scope. The vault that holds the PAN-to-token mapping remains in scope, whether you host it yourself or outsource it to a provider. Outsourcing the vault shifts that scope burden to the provider.

What’s the difference between a vault token and a network token?

A vault token is generated and controlled by a single processor or tokenization provider and is only usable within that system. Migrating to a new processor means re-tokenizing your vault, which requires PAN access and brings your servers back into PCI scope. A network token is issued directly by the card network (Visa or Mastercard) and works across providers, includes a per-transaction cryptogram that prevents replay attacks, and updates automatically when a card is reissued.

Is tokenization required for PCI compliance?

PCI DSS v4.0 does not mandate tokenization by name. It requires that PANs be rendered unreadable in storage (Requirement 3.5.1). Tokenization is one of four acceptable methods; the others are truncation, hashing, and encryption. Tokenization is the most common choice because it also enables card-on-file functionality that the other methods don’t support.

Can a token be reversed back into the original card number?

Only by the vault that issued it, using the lookup table it controls. There’s no algorithm that derives the PAN from the token itself. Format-preserving tokens are an exception: they use a deterministic algorithm with a key, which means they are technically reversible by anyone with the key. That’s why FPE requires careful key management and why some QSA assessments treat it differently from random-token tokenization.

Do I need to build my own tokenization, or does my PSP already do it?

Most PSPs tokenize on their own vault by default. The gap shows up when you route across multiple PSPs: each one issues its own token, so a card tokenized at PSP A isn’t recognized at PSP B. If you need multi-PSP routing without re-collecting card data, you need either network tokens (which travel across providers) or a payment orchestration layer with a provider-agnostic vault.