In early 2025, Visa announced it had issued more than 12.6 billion network tokens since launching its Token Service (Visa, 2025). Roughly half of Visa's global digital transactions now move as tokens, up 44% year over year. The same year, Visa reported that this token surge translated into a 6% lift in approval rates and up to a 30% reduction in fraud across its network (PYMNTS, 2024).

Tokenization stopped being a security checkbox somewhere around 2022. Today it is a revenue lever, a fraud control, a PCI scope reducer, and a card-lifecycle manager rolled into one. About 35% of all card transactions in 2025 are expected to be tokenized, and the global payment tokenization market is projected to grow from USD 1.5 billion in 2024 to USD 8.4 billion by 2034 at an 18.6% CAGR (Market.us, 2025).

Yet most engineering and product teams still treat tokenization as one thing. It isn't. There are at least three distinct flavors (network tokens, processor tokens, vault tokens), each with different cost, security, and routing implications. This article unpacks how tokenization actually works in 2026, what the numbers say about its impact, and how Juspay Hyperswitch implements all three flavors across 300+ processors and payment methods through a single API.

What Is Payment Tokenization, Precisely?

Payment tokenization replaces a sensitive card number (PAN) with a non-sensitive surrogate value called a token. The token is mathematically unrelated to the underlying PAN. If a token is stolen from a merchant's environment, it cannot be used to reconstruct the original card number, and in most cases it cannot be used to authorize a transaction outside the merchant or domain it was issued for.

Tokenization is not encryption. Encryption transforms data with a reversible algorithm, anyone holding the key can decrypt it. Tokenization replaces data with a random value and stores the mapping in a secure vault. Without access to that vault, the token is useless. This is why tokenization is the preferred method for taking systems out of PCI DSS scope. There is nothing sensitive on the merchant's side to steal in the first place.

Tokenization vs Encryption at a Glance

The Three Types of Payment Tokens (and Why the Difference Matters)

Most blogs collapse "tokenization" into a single concept. In production payments, there are three distinct token types, and choosing the wrong one costs money.

1. Network Tokens

Network tokens are issued by the card networks themselves (Visa Token Service, Mastercard Digital Enablement Service, American Express Token Service). The network replaces the PAN with a network-issued token bound to the merchant, the device, or the channel, and provides a cryptogram for each transaction.

Network tokens are the highest-value token type because the issuing bank can verify them with significantly more confidence than a raw PAN. The result:

• Authorization rate lift: Visa reports a 4.6% global lift in CNP authorization rates for tokenized transactions versus PAN (Visa). Mastercard reports an average 2.1% increase (Mastercard data, 2024).
• Fraud reduction: Visa reports CNP fraud drops by approximately 26% on average and up to 40% for tokenized transactions (Visa).
• Interchange savings: Visa Network Token transactions can qualify for interchange rates up to 10 bps lower than non-tokenized rates (Visa).
• Lifecycle management: When a card is reissued, expired, or replaced, the network token continues to work. There is no card-on-file failure cascade, which is a leading cause of involuntary churn for subscription businesses.

2. Processor (or PSP) Tokens

Processor tokens are issued by the payment processor that handles the transaction. They are usable only with that specific processor. They reduce PCI scope and protect stored cards, but they create vendor lock-in. If you switch processors, your tokens do not migrate, and you lose the saved card data unless you have a separate vault.

3. Vault (or Merchant) Tokens

Vault tokens are issued by an independent card vault. The card number is stored in a PCI DSS Level 1 compliant vault, and the token is portable across processors. This is the architecture that gives merchants leverage: if you want to route to a new acquirer next quarter, you can do it without re-collecting card data from customers.

When to Use Which Token Type

The Business Case in Numbers

Tokenization adoption is no longer driven by security teams alone. The financial impact has crossed into CFO and revenue territory.

• Adoption: About 60% of merchants now use tokenization, and more than 70% of financial institutions report lower fraud after deploying it (CoinLaw, 2025).
• Volume: Visa alone processed over 12.6 billion network tokens by early 2025, with 50% of its digital transactions now tokenized (Visa, 2025).
• Auth rate impact: A 2-4% lift in approval rates may sound modest. For a merchant doing USD 100M in annual GMV with a 90% baseline approval rate, recovering even 2 percentage points is roughly USD 2 million in additional captured revenue per year, with no marketing or product spend.
• Fraud impact: Card-not-present fraud fell by an average of 28% with network tokenization (PCI Proxy industry research). Compare that to the cost of fraud, where every USD 1 of fraud now costs US e-commerce merchants USD 4.61 (LexisNexis, 2025).
• Subscription churn: Network tokens act as an embedded account updater. For subscription businesses where 20-40% of involuntary churn comes from card lifecycle events, this directly recovers retention.

Does Tokenization Make You PCI DSS Compliant?

Tokenization does not automatically make a merchant PCI DSS compliant, but it dramatically reduces the scope of compliance. PCI DSS applies to systems that store, process, or transmit cardholder data. By replacing the PAN with a token at the point of capture and never storing the underlying card number on merchant infrastructure, the merchant moves the bulk of compliance scope to the tokenization service provider.

In practice, this can shift a merchant from SAQ D (the most extensive Self-Assessment Questionnaire, with over 300 controls) to SAQ A or SAQ A-EP, where merchant infrastructure is largely out of scope. The compliance audit cost difference is significant, often six figures annually for mid-market merchants.

How Juspay Hyperswitch Implements Tokenization

Juspay Hyperswitch supports all three token types through a unified architecture, and it is one of the few orchestrators that ships with end-to-end network tokenization built in (provisioning, cryptogram management, lifecycle, and fallback).

Juspay's Position in the Tokenization Ecosystem

Juspay is certified as both a Token Requestor (TR) and a Token Service Provider (TSP) with the major card networks. Concretely:

• As a Token Requestor, Juspay initiates token provisioning with Visa, Mastercard, and American Express on the merchant's behalf.
• As a Token Service Provider, Juspay manages the full token lifecycle: provisioning, detokenization, refresh, suspension, and deletion.
• Juspay has issued more than 150 million network tokens globally to date.
• Merchants can use Juspay's TR ID by default, or bring their own TR credentials and configure them inside Juspay Hyperswitch for full control over token ownership.

Most orchestrators integrate to a TSP. Juspay Hyperswitch is the TSP, which removes a layer of latency and cost from the network tokenization path.

Three Network Tokenization Modes

Juspay Hyperswitch supports three distinct integration modes for network tokenization, depending on how deep the merchant wants to go:

Mode 1: Network Tokenization during Payments (Orchestration mode)

The most common path. The merchant runs payments through Juspay Hyperswitch's orchestration layer and Juspay Hyperswitch handles network tokenization automatically:

1. Customer enters card details in the Hyperswitch checkout UI.
2. Hyperswitch requests a network token + cryptogram from the card network.
3. If tokenization succeeds, Hyperswitch sends the network token + cryptogram to the PSP.
4. If the network token fails (network token-specific errors or eligibility issues), Hyperswitch silently retries with clear PAN + CVV/NTI to maximize authorization rate. This fallback is automatic and invisible to the merchant.
5. If the customer chose to save the card, the network token is stored in Juspay Hyperswitch's PCI DSS Level 1 vault and optionally returned to the merchant.

No PSP integration changes required. Merchants get tokenized payments by toggling the feature on their merchant account.

Mode 2: Network Tokenization during Vaulting (Standalone Vault mode)

For merchants who want a vault-first architecture and route payments through their own systems or other PSPs:

1. Card details captured via Hyperswitch's PCI-compliant UI SDK or server-to-server API.
2. Juspay Hyperswitch provisions a network token, retrieves PSP tokens (where applicable), and stores PAN + network tokens + PSP tokens together.
3. Returns the NT + cryptogram + PSP tokens + NTID to the merchant.
4. Later: merchant calls /retrieve_payment_method, gets the NT + a fresh cryptogram, and uses it to process payments through any PSP they want.

This mode is what gives merchants commercial leverage. The vault holds the card; the merchant chooses the processor.

Mode 3: Standalone Network Tokenization API

For merchants who already have their own PCI vault and orchestration layer but want to add network tokenization for the auth-rate and cost benefits:

POST /generate_token        Provision a network token for a PAN
POST /update_token          Update token attributes
POST /delete_token          Delete a token
POST /retrieve_token        Get token + fresh cryptogram for a payment

Webhooks from the card network update token state automatically. No vault, no checkout, just the tokenization service.

PG-Agnostic Recurring Payments: How Network Tokens Unlock Routing Freedom

A common production problem: a merchant sets up a recurring payment via Stripe, gets back a Stripe-issued token, and is now stuck routing all renewals to Stripe. If Stripe has a regional outage or worse pricing, the merchant cannot route around it without re-collecting the card.

Juspay Hyperswitch solves this with PG-Agnostic Card Forwarding. The system stores the Network Transaction ID (NTID) alongside the token, which acts as a chaining identifier back to the original CIT. On subsequent MITs, Juspay Hyperswitch can route to any eligible connector that accepts the NTID, regardless of which PSP issued the original token.

Currently supported processors for PG-agnostic recurring payments: Stripe, Adyen, Cybersource.

Enable it per business profile via:

curl --location 'http://sandbox.hyperswitch.io/account/:merchant_id/business_profile/:profile_id/toggle_connector_agnostic_mit' \
  --header 'Content-Type: application/json' \
  --header 'api-key: api_key' \
  --data '{ "enabled": true }'

Once enabled, any payment method saved with setup_future_usage: off_session becomes eligible for routing across the supported PSPs on subsequent MITs. The internal precedence: try with NTID first, fall back to the original PG token if NTID is not present.

Routing CITs and MITs to Different Processors

A common pattern is to route CITs through one PSP (best authentication UX) and MITs through another (best recurring auth rates). Juspay Hyperswitch's Smart Router supports this via metadata-based rules:

// CIT request
"metadata": { "is_cit": "true" }

// MIT request
"metadata": { "is_mit": "true" }

Configure the routing rule once in the Hyperswitch dashboard's routing module (Rule-Based Configuration), and CITs go to one PSP while MITs go to another. The same NT + NTID stays usable across both.

Token Storage: PCI DSS Level 1 Vault

Juspay Hyperswitch's vault is a separate service, hardened to PCI DSS v4.0 Level 1 Service Provider standards:

• In transit: SSL/TLS between SDK and backend; signed (private key) and encrypted (vault public key) for application-to-vault traffic.
• At rest: AES encryption inside the vault, on top of database-level encryption.
• Per-merchant DEKs: Each merchant has a unique Data Encryption Key, optionally managed via AWS KMS or a Key Manager Service.
• Logs: Sensitive fields wrapped in a Rust Secret<T> type, masked in all logs (*** alloc::string::String ***).

The vault is the same one that backs Hyperswitch's payment orchestration, the standalone Vault Service, and the Vault SDK / Payment Method Management SDK.

Implementation Best Practices

For teams deploying tokenization, a few patterns separate effective implementations from compliance-checkbox ones:

1. Tokenize at the earliest possible point. Capture cards with a hosted field, iframe, or Vault SDK that tokenizes before the PAN reaches your application server.
2. Provision network tokens at first save, not at first charge. Provisioning at save means the network token is ready when the customer comes back, and you avoid the cold-start auth rate penalty on the first recurring charge.
3. Always store the cryptogram with the network token. Network tokens require a fresh cryptogram per transaction. Caching cryptograms causes downstream auth failures.
4. Use a vault you control, or a vault you can switch. Processor-bound tokens are convenient until you want to renegotiate processing fees. Independent or merchant-controlled vaults preserve commercial leverage.
5. Monitor token-vs-PAN auth rate as a KPI. If the lift you observe is below industry benchmarks (4.6% Visa, 2.1% Mastercard), the issue is usually missing or stale cryptograms, or BIN ranges where issuer support is incomplete.
6. Configure NT-to-PAN fallback. Network token coverage is high but not 100%. Silent fallback to clear PAN preserves the auth rate for ineligible cards. Juspay Hyperswitch does this automatically in orchestration mode.

Frequently Asked Questions

Is a tokenized card the same as a virtual card?

No. A tokenized card is a surrogate value for an existing PAN, controlled by the network or vault. A virtual card is a distinct PAN issued for one-time or short-term use, often for B2B payments or expense management.

Do network tokens work for all card brands?

Juspay Hyperswitch currently supports Visa, Mastercard, and American Express network tokens, with additional networks added based on merchant demand and network readiness. Coverage within each network varies by issuer and BIN range.

Does tokenization slow down checkout?

No. Tokenization adds a few milliseconds at card capture and is fully invisible at authorization. Juspay Hyperswitch optimizes for latency by falling back to clear PAN + CVV/NTI when network tokens would add delay.

Can I migrate from processor tokens to network tokens?

Yes. Juspay Hyperswitch can re-provision network tokens for existing vault entries. For PG-agnostic recurring payments, the NTID stored alongside the original token enables routing to alternative PSPs without re-collecting card data.

What happens to my tokens if I leave my payment provider?

If you use processor tokens, they typically do not migrate. If you use vault tokens issued by Juspay Hyperswitch's Vault, they remain yours and continue to work with any connected processor. This is the architecture argument for orchestration from day one.

Can I bring my own Token Requestor credentials?

Yes. Juspay Hyperswitch supports configuring your own TR ID with Visa, Mastercard, and American Express, so all network tokenization requests are made under your credentials. This is preferred for merchants with existing TR registrations or compliance-driven token ownership requirements.

Closing Perspective

Tokenization in 2026 is not the same product it was in 2018. It has quietly become the single highest-leverage change a payments team can make: 2-4% more authorizations, 26-40% less CNP fraud, lower interchange, fewer card-on-file failures, and a smaller PCI footprint. The merchants pulling ahead are not the ones who tokenize. They are the ones who use the right token type for each flow, and who choose architectures that preserve commercial leverage across processors.

Juspay Hyperswitch was built so those choices are configurable rather than locked in. Network tokenization across Visa, Mastercard, and American Express; PG-agnostic recurring payments via NTID; CIT/MIT routing to different PSPs; bring-your-own TR credentials; standalone vault and standalone NT API for merchants who want only one piece. All of it sits on a PCI DSS Level 1 vault and connects to 300+ processors and payment methods through a single API.

Explore Juspay Hyperswitch on GitHub or read the network tokenization documentation to get started.