Payment Tokenization: The Complete Guide to Network Tokens, Gateway Tokens, and PCI Compliance

Every time a card number is stored, transmitted, or processed, it creates risk. Payment tokenization replaces sensitive card data with non-sensitive substitutes—tokens—that are useless to attackers but fully functional within the payment ecosystem. It is the single most important technology shift in card payments since EMV chip adoption.

The numbers tell the story. The global payments industry processed 283 billion tokenized transactions in 2025, and that figure is projected to reach 574 billion by 2029. Visa reports a 4.6% global authorization rate lift for tokenized card-not-present transactions compared to raw card numbers, alongside a 26% average decline in fraud rates. These are not marginal improvements—they are structural advantages that compound across every transaction a business processes.

Yet most guides on payment tokenization cover only the basics: what a token is, and why it matters for PCI compliance. They rarely explain the critical differences between gateway tokens and network tokens, the mechanics of how network tokens interact with issuers and card schemes, or how to build a quantified business case for migration. This guide fills those gaps. It is written for payment professionals, product managers, and technical leaders who need to understand tokenization deeply—not just conceptually.

What Is Payment Tokenization?

Payment tokenization is the process of replacing a primary account number (PAN)—the 16-digit number on the front of a payment card—with a surrogate value called a token. The token maintains the format of a card number (it looks like a PAN) but carries no intrinsic value. If intercepted, it cannot be used to initiate a payment, reverse-engineer the original card number, or commit fraud.

The original PAN is stored securely in a token vault—a hardened, PCI-compliant database managed by either the payment processor, the card network, or a dedicated tokenization service provider. When a transaction needs to be processed, the token is submitted in place of the PAN, and the token vault maps it back to the real card number at the appropriate point in the authorization flow.

Where Tokens Are Used

Tokens appear throughout the payment lifecycle:

• Card-on-file storage – Subscription services, e-commerce platforms, and digital wallets store tokens instead of card numbers, eliminating the risk of a data breach exposing raw PANs.
• Transaction processing – Tokens flow through payment gateways and processors, reducing the number of systems that handle sensitive card data.
• Merchant-initiated transactions (MITs) – Recurring billing, installment payments, and unscheduled payments use tokens to charge cards without requiring the customer to re-enter their details.
• Mobile and digital wallets – Apple Pay, Google Pay, and Samsung Pay use network-level tokenization to secure every contactless and in-app transaction.
• Account Funding Transactions (AFTs) – Businesses processing Account Funding Transactions use tokens to securely pull funds from stored cards for money transfers, wallet loads, and prepaid card funding.

The fundamental principle is simple: if a system does not need to see the real card number, it should not. Tokenization enforces this principle at scale.

Three Types of Tokenization: Gateway Tokens, Network Tokens, and Encryption

Not all tokenization is equal. There are three distinct approaches, each with different security properties, authorization benefits, and implementation complexity. Understanding the differences is critical for choosing the right strategy.

1. Gateway / PSP Tokens

Gateway tokens (also called PSP tokens or acquirer tokens) are generated and managed by your payment gateway or payment service provider. When a customer submits their card for the first time, the gateway stores the PAN in its own token vault and returns a proprietary token to the merchant. All subsequent transactions reference this token, and the gateway resolves it internally before sending the real PAN to the card network.

Key characteristics:

• The token is proprietary to the gateway—it only works with that specific provider
• The original PAN is stored in the gateway's vault, not at the network level
• The issuing bank sees the raw PAN during authorization—the token is resolved before the request leaves the gateway
• No cryptogram is generated—the issuer cannot distinguish a tokenized transaction from a non-tokenized one
• If you switch gateways, you must migrate PANs or re-collect card details from customers

2. Network Tokens

Network tokens are issued by the card networks themselves—Visa, Mastercard, American Express—through their Token Service Providers (TSPs). Instead of a proprietary gateway token, the card network generates a Device PAN (DPAN) or Token PAN (TPAN) that is linked to the original card (the Funding PAN or FPAN) within the network's infrastructure. Each transaction also includes a cryptogram—a one-time, transaction-specific security code that the issuer validates during authorization.

Key characteristics:

• The token is issued and managed by the card network, not the gateway
• The issuer knows the transaction is tokenized and can apply higher trust scoring
• A unique cryptogram accompanies each transaction, providing transaction-level authentication
• If the physical card is reissued (new number, new expiry), the network token updates automatically—no customer action required
• Network tokens are portable across gateways and processors
• Qualifying transactions may receive interchange fee reductions

3. Point-to-Point Encryption (P2PE) / End-to-End Encryption

Encryption is not tokenization in the strict sense, but it is often discussed alongside it. Point-to-point encryption (P2PE) encrypts card data at the point of capture (the terminal or browser) and keeps it encrypted until it reaches the decryption endpoint (the processor). The PAN is never exposed in plaintext within the merchant's environment.

Key characteristics:

• Data is encrypted, not replaced—the ciphertext can be decrypted back to the original PAN
• Primarily used for card-present transactions at physical terminals
• Does not generate a reusable token for recurring or card-on-file payments
• Provides strong PCI scope reduction for the encryption boundary, but not for stored data
• Often used in combination with tokenization: P2PE protects the initial capture, and tokenization protects long-term storage

Three-Way Comparison

The takeaway: gateway tokens are a good baseline for PCI scope reduction, but network tokens deliver measurably higher authorization rates, lower fraud, interchange savings, and automatic card lifecycle management. For businesses with significant card-on-file or recurring payment volume, network tokens are the superior choice.

How Network Tokens Work: Step-by-Step

Network tokenization involves a specific set of participants and a well-defined flow. Understanding this flow is essential for anyone evaluating, implementing, or troubleshooting network token integrations.

The Key Participants

• Cardholder – The person who owns the payment card
• Token Requestor (TR) – The entity that requests a token on behalf of the merchant. This can be the merchant directly, the payment gateway, or the payment orchestrator
• Token Service Provider (TSP) – The card network's tokenization platform (Visa Token Service, Mastercard Digital Enablement Service, etc.)
• Issuing Bank – The bank that issued the cardholder's card. The issuer approves or declines the token request

The Token Provisioning Flow

The critical difference from gateway tokenization: with network tokens, the issuing bank knows the transaction is tokenized and has validated the cryptogram before making its approval decision. This issuer-side awareness is what drives higher approval rates and lower fraud—benefits that gateway tokens simply cannot provide.

The Business Case for Network Tokenization

Network tokenization delivers measurable financial returns across four dimensions. The following figures are drawn from published card network data and aggregated merchant results.

1. Authorization Rate Improvement

Authorization rates—the percentage of transaction attempts that are approved by the issuing bank—are the single most impactful metric for online merchants. Every declined transaction is a lost sale. Visa reports a 4.6% global authorization rate lift for tokenized card-not-present (CNP) transactions compared to raw PAN submissions. Leading payment platforms report an average 3% authorization rate increase across their merchant base after enabling network tokens.

For a business processing $100 million in annual CNP volume with a 90% baseline approval rate, a 3–5% improvement translates to $3–5 million in recovered revenue from transactions that would otherwise have been declined.

2. Fraud Rate Reduction

Visa data shows a 26% average decline in fraud rates for transactions processed with network tokens compared to raw PANs. The cryptogram mechanism makes it impossible for an attacker to reuse a stolen token—each cryptogram is valid for exactly one transaction and is bound to the specific token requestor.

Lower fraud translates directly to reduced chargeback costs, lower dispute management overhead, and improved standing with card network fraud monitoring programs. For businesses operating in high-risk verticals or high-fraud geographies, the fraud reduction alone can justify the migration.

3. Interchange Fee Savings

Visa offers a 0.10% (10 basis points) interchange reduction on qualifying tokenized CNP transactions. While 10 bps may sound modest, it compounds across transaction volume. For a merchant processing $500 million in annual card-not-present volume, 10 bps represents $500,000 in annual interchange savings.

Mastercard has also introduced favorable interchange treatment for tokenized transactions in select markets. As network tokenization adoption grows, interchange incentives are expected to expand.

4. Reduced Involuntary Churn

For subscription businesses, one of the largest sources of revenue loss is involuntary churn—customers whose recurring payments fail because their card expired, was reissued, or was replaced. Traditional approaches rely on account updater services that batch-check for new card numbers, often with multi-day delays and incomplete coverage.

Network tokens solve this structurally. When a card is reissued, the card network automatically updates the DPAN-to-FPAN mapping in the token vault. The merchant's stored token remains unchanged, and the next recurring charge processes successfully against the new card—without the cardholder lifting a finger. This eliminates a significant portion of payment-related churn and the costly retry-and-recovery flows that subscription businesses build around it.

Combined ROI Summary

PCI Compliance and Scope Reduction

The Payment Card Industry Data Security Standard (PCI DSS) defines the security requirements that any organization handling cardholder data must meet. PCI compliance is not optional—it is mandated by the card networks and enforced through fines, increased audit requirements, and potential loss of card processing privileges.

How Tokenization Reduces PCI Scope

PCI scope is determined by the Cardholder Data Environment (CDE)—every system, network, and process that stores, processes, or transmits cardholder data. The larger the CDE, the more systems must meet PCI requirements, and the more expensive and complex compliance becomes.

Tokenization shrinks the CDE dramatically. When a merchant stores tokens instead of PANs, the systems that handle tokens are outside PCI scope (provided the tokens meet PCI's definition of non-reversible). The only systems that remain in scope are those that handle the initial card capture (before tokenization) and the token vault itself.

In practice, this means:

PCI DSS 4.0 and Tokenization

PCI DSS 4.0, which became mandatory in March 2025, introduced several changes that make tokenization even more relevant. The updated standard places greater emphasis on risk-based approaches, continuous security monitoring, and encryption of stored PAN data. Requirement 3 (Protect Stored Account Data) specifically addresses how organizations must protect stored PANs—and tokenization is the most straightforward way to meet these requirements.

Under PCI DSS 4.0, organizations that store PANs must implement stronger access controls, more granular logging, and more frequent testing. Organizations that tokenize their card data can avoid most of these obligations entirely, because the tokens they store are not considered account data under the standard. For businesses evaluating their PCI DSS 4.0 compliance roadmap, network tokenization represents the fastest path to scope reduction.

Token Lifecycle Management

A network token is not a static artifact. It has a full lifecycle—from creation to retirement—managed by the card network's Token Service Provider. Understanding this lifecycle is essential for operational reliability.

Provisioning

Provisioning is the initial creation of a token, as described in the step-by-step flow above. The token requestor submits the FPAN, the issuer approves the request, and the TSP issues a DPAN. The provisioning event is logged, and the token is assigned a status of Active. Provisioning may include additional verification steps depending on the issuer's risk policies and the token requestor's trust level.

Active Use

During active use, the token is submitted with each transaction alongside a fresh cryptogram. The TSP maintains the DPAN-to-FPAN mapping and generates cryptograms on demand. The merchant's systems interact only with the token—the FPAN never leaves the card network's vault. Transaction data (authorization responses, settlement records) is linked to the token for reconciliation.

Automatic Updates

When a cardholder's underlying card changes—due to expiration, loss, theft, or issuer-initiated reissue—the card network updates the FPAN associated with the token. The DPAN itself does not change. This means the merchant's stored token continues to work without any action from the merchant or the cardholder. This is the mechanism that eliminates involuntary churn for subscription and recurring payment businesses.

Automatic updates cover these common scenarios:

• Card expiration – New card issued with new expiry date and potentially new PAN
• Lost or stolen card replacement – New card number issued by the bank
• Card upgrade – Issuer replaces a standard card with a premium product
• Issuer-initiated reissue – Bank replaces cards proactively due to a data breach or portfolio migration

Suspend and Resume

A token can be temporarily suspended without being deleted. Suspension may be triggered by the cardholder (who reports the card lost and then finds it), the issuer (who suspects fraud and needs to investigate), or the token requestor (who pauses a subscription). A suspended token cannot be used for transactions but retains its DPAN-to-FPAN mapping. When the suspension is lifted, the token returns to Active status and transactions resume without re-provisioning.

De-Provisioning

De-provisioning permanently removes a token. The DPAN-to-FPAN mapping is deleted from the token vault, and the token can no longer be used for transactions. De-provisioning is triggered when the cardholder requests removal of their stored payment method, when the merchant cancels the customer's account, when the issuer permanently closes the underlying card account, or when the token requestor terminates their relationship with the merchant.

Card-on-File and Merchant-Initiated Transactions

Card-on-file (COF) tokenization and merchant-initiated transactions (MITs) are two of the highest-value applications of network tokens. Together, they address the core challenges of recurring payments, subscription billing, and stored-credential commerce.

The Expired Card Problem

Before network tokens, every stored card had a built-in expiration date. When the card expired, the stored credential became useless—the next charge would decline, and the business had to contact the customer to collect updated card details. With average card lifecycles of 3–4 years, a large subscription business could see 25–30% of its stored cards turn over annually. Each turnover event risked losing the customer entirely.

Account Updater services partially addressed this by periodically checking with card networks for updated card numbers. But Account Updater operates in batch mode (typically nightly or weekly), has incomplete coverage across issuers and geographies, and still results in a window where charges can fail before the updated PAN is retrieved.

Network tokens eliminate this problem. The token remains constant even when the underlying card changes. Updates propagate in real time through the card network, with no batch delays and no gaps in coverage. For subscription businesses, this means significantly fewer failed payments and a measurable reduction in involuntary churn.

MIT Classification and Network Tokens

Card networks classify transactions into categories based on who initiated them and whether the cardholder is present. The two primary categories for stored-credential transactions are:

Network tokens strengthen the MIT flow by providing the cryptogram as a transaction-level proof of legitimacy. When an issuer receives a MIT with a network token and valid cryptogram, it has much higher confidence that the charge is legitimate and was authorized by the cardholder through the original CIT. This confidence translates directly to higher approval rates for recurring charges—one of the most impactful benefits for subscription-based businesses.

For businesses processing Account Funding Transactions on stored credentials—such as recurring wallet loads or scheduled money transfers—the combination of network tokens and proper MIT classification ensures that these transactions are processed reliably, with the highest possible approval rates and the lowest possible fraud exposure.

Visa Token Service (VTS) vs Mastercard Digital Enablement Service (MDES)

The two largest card networks each operate their own Token Service Provider. Visa's is called the Visa Token Service (VTS), and Mastercard's is the Mastercard Digital Enablement Service (MDES). While both implement the EMVCo tokenization specification, they differ in several practical dimensions.

Head-to-Head Comparison

Key Differences in Practice

Cryptogram format: The most significant technical difference is in how each network generates and validates cryptograms. Visa uses the TAVV (Token Authentication Verification Value), while Mastercard uses the DSRP (Digital Secure Remote Payment) cryptogram. Both serve the same purpose—proving the transaction is legitimate and originated from an authorized token requestor—but they use different cryptographic methods. Payment processors and orchestrators must support both formats to process tokenized transactions across both networks.

Interchange incentives: Visa has published explicit, global interchange reductions for tokenized CNP transactions (10 bps). Mastercard's incentive structure varies by region and is less uniformly published. Merchants processing high volumes across both networks should verify the specific interchange treatment applicable in their operating markets.

Issuer coverage: Both networks have broad issuer support, but coverage is not 100%. Some smaller issuers and regional banks may not yet support network tokenization. When a token request is sent for a card whose issuer does not support tokenization, the TSP will return a decline, and the system must fall back to gateway tokenization or raw PAN processing. A well-designed integration handles this gracefully.

Practical recommendation: Most businesses do not interact with VTS or MDES directly. Instead, they work through a payment orchestrator or gateway that abstracts the network-specific differences. The orchestrator handles token provisioning, cryptogram generation, and lifecycle management across both networks through a unified API. This is the recommended approach for merchants that do not want to maintain separate integrations with each card network.

Implementation Guide: How to Adopt Network Tokenization

There are three paths to network tokenization, depending on your organization's size, technical capability, and existing payment infrastructure.

Path 1: Become a Direct Token Requestor

Large merchants and payment platforms can register directly with Visa and Mastercard as Token Requestors (TRs). This provides maximum control over the tokenization process but requires significant technical investment.

Requirements include:

• Registration with each card network (Visa ID & V, Mastercard MDES Token Connect)
• Building and certifying direct API integrations with VTS and MDES
• Implementing cryptogram generation and management
• Managing token lifecycle events (updates, suspensions, de-provisioning)
• Maintaining compliance with each network's Token Requestor standards
• Supporting multiple cryptogram formats (TAVV for Visa, DSRP for Mastercard)

This path is typically chosen by large e-commerce platforms, digital wallets, and payment service providers that process billions of dollars annually and need full control over their tokenization infrastructure.

Path 2: PSP-Managed Tokenization

The most common path for mid-market and enterprise merchants is to enable network tokenization through their existing payment gateway or orchestration platform. In this model, the gateway acts as the Token Requestor on behalf of the merchant.

This approach offers several advantages:

• No direct integration with card networks required
• The gateway handles token provisioning, cryptogram generation, and lifecycle management
• A single API serves both Visa and Mastercard tokenization
• Migration from gateway tokens to network tokens can often be done without re-collecting card details
• The merchant benefits from the gateway's existing Token Requestor certification and trust level

Most modern payment gateways and orchestrators now offer network tokenization as an opt-in feature. The merchant enables it in their configuration, and the platform begins requesting network tokens for new card-on-file enrollments—and in many cases, can backfill existing stored credentials with network tokens.

Path 3: Phased Migration

For businesses that already have a large base of gateway tokens and stored credentials, the recommended approach is a phased migration rather than a big-bang switch.

Glossary of Payment Tokenization Terms