Beyond the PAN: What Merchants Need to Know About Network Tokens

What is a network token?

A network token is a set of randomized code that acts as a substitute for a credit card’s primary account number (PAN). Network tokens allow merchants to securely process payments without storing sensitive card details, significantly reducing the risk of fraud and data breaches. These tokens are issued and managed by the major card networks themselves, such as Visa, Mastercard, American Express, and Discover.

The network token itself is linked to the customer’s underlying card account, but the merchant can use it instead of submitting the original PAN for supported transactions.

A network token often resembles a normal card number and can travel through existing card-payment infrastructure. Behind the scenes, the network recognizes it as a token, applies the relevant usage controls, and maps it to the underlying account before sending the authorization request to the issuer.

The important part is not simply that the PAN has been replaced. The token can also be limited to a particular merchant, device, token requestor, or payment scenario. EMVCo refers to these restrictions as token domain controls. They reduce the usefulness of a token if it is stolen because the token should not work outside its approved environment.

Network tokens vs. PANs

A PAN is the original card number associated with a credit or debit card account. It is typically 15 or 16 digits and can generally be used wherever that card brand is accepted.

A network token is a substitute credential connected to that PAN. It does not replace the underlying card account itself. Instead, it reduces the frequency with which the original PAN needs to be stored, transmitted, or presented within the merchant’s payment flow.

This distinction matters most in card-on-file commerce. A merchant may store a PAN for subscriptions, one-click checkout, usage-based billing, or future purchases. If the card is later replaced, the stored PAN may become outdated.

A network token can reduce that problem because the card network and issuer can manage the connection between the token and the underlying account. In many cases, the merchant can continue using the existing token without asking the customer to enter a new card number.

That continuity is valuable, but it is not guaranteed in every situation. A token can be suspended or deactivated, an issuer can decline a provisioning request, and some cards or transaction types may not be eligible for tokenization.

How does network tokenization work?

The exact flow varies by network, token requestor, processor, and transaction type. At a high level, network tokenization usually follows five steps.

1. The card is submitted for tokenization

   When a customer saves a card, the merchant or its tokenization provider sends the card information and relevant merchant data to the appropriate card-network token service.

   The party that requests and manages the token is known as the token requester. A merchant can act as the token requester directly, or a third-party provider can perform that role on the merchant’s behalf.

2. The issuer evaluates the request

   The token service works with the card issuer to evaluate the request. Depending on the card, risk signals, and provisioning scenario, the issuer may approve the token, request additional verification, or decline the request.

   This process can also produce token-assurance information that helps indicate how the cardholder or account was verified during provisioning.

3. The network token is provisioned

   Once approved, the card network provides a network token and related data to the token requester. The merchant may store the payment token itself or store a reference that allows its provider to retrieve and use the token when needed.

   Even though the token is not the original PAN, it should still be protected appropriately. Network tokens may resemble account numbers and remain valuable within their authorized payment domains.

4. The token is used for a payment

   For a supported cardholder-initiated transaction, the merchant or its provider retrieves the network token and requests the transaction data required by the network. This commonly includes a fresh token cryptogram.

   A cryptogram is a transaction-specific security value that helps the network and the issuer verify that the token is used in an authorized transaction. The merchant then submits the token, cryptogram, and other payment information through its processor.

   The network recognizes the token, maps it to the underlying account, and sends the authorization request to the issuer. EMVCo documents this flow as a coordinated exchange among the merchant, token requestor, token service provider, processor, network, and issuer.

   The flow differs for certain subsequent merchant-initiated transactions. Recurring charges and other stored-credential payments must comply with the applicable network rules and may not require a new cryptogram for each authorization.

5. Lifecycle events are managed

   If the underlying card expires or is replaced, the issuer and card network can update the token’s associated account information or expiration details.

   The token may also be suspended, resumed, or deleted in response to events such as fraud, account closure, or a cardholder request. This lifecycle management helps merchants avoid relying only on a static credential that may become outdated without warning.

Why do merchants use network tokens?

Network tokenization can affect several parts of payment performance, from authorization rates to credential security.

Higher authorization rates

An issuer has to decide whether to approve every card transaction. Network tokens can provide useful signals during that decision, including the token’s status, assurance information, merchant restrictions, and transaction authentication data.

They can also reduce declines caused by outdated card information. If the token remains active after an underlying card change, the merchant can submit a current credential instead of a stale PAN.

Results vary by merchant and implementation. VGS cites authorization improvements of approximately 1%-3% for its network token solution, while Visa reports a 4.3% increase in authorization across its broader network token data. Neither result should be treated as a guaranteed lift for every merchant.

Even a modest improvement can be meaningful for businesses processing a high volume of card-not-present transactions. The actual revenue impact depends on transaction value, customer behavior, retry logic, issuer mix, and whether an approved payment ultimately settles.

Better payment continuity

Expired and replaced cards can create involuntary churn, especially for subscriptions and other recurring-payment businesses.

Because network tokens support lifecycle management, merchants may be able to continue billing a customer after the underlying card details change. This reduces the need for payment update emails, customer service outreach, and manual card replacement.

Network tokens should still be paired with a broader credential-management strategy. Not every card can be tokenized, and not every lifecycle event will preserve the token. Account updater services and secure PAN fallback can help cover cards that are not eligible for network tokenization.

Reduced the value of stolen payment data

A PAN is designed to work across many merchants. A network token is generally restricted to a narrower payment domain.

That restriction makes a compromised network token less useful outside the merchant, device, or transaction environment for which it was provisioned. For applicable transactions, a cryptogram provides additional security and should not be reused for a different purchase.

Visa reported in a 2022 analysis that tokenized transactions had 28% lower fraud rates and 3% higher approval rates across more than 8,600 issuers and 800,000 merchants. Results will vary, but the data illustrates why networks and issuers increasingly view tokenization as an important part of card-not-present security.

Potential processing-cost savings

Some card-network programs offer more favorable interchange treatment for eligible network-token transactions.

VGS estimates that processing savings can reach approximately 10 basis points in some scenarios. Actual savings depend on the card network, region, merchant category, transaction type, processor, and whether all qualification requirements are met. Network tokenization should not be presented as a universal 10-basis-point discount.

Merchants should review their own transaction data with their acquirer or payments provider before building a business case around interchange savings.

More control over a multi-processor strategy

Merchants often use multiple processors for geographic coverage, redundancy, cost management, or authorization optimization.

Network tokens can support this type of architecture, but there is an important qualification: a network-issued token is not automatically portable across every processor.

A token may be provisioned under a PSP’s token requestor identity or configured for a particular merchant-processor relationship. Moving it can depend on:

• Who controls the token requestor ID
• How the merchant is identified to the card network
• Whether the new processor accepts network-token transactions
• Whether the required cryptogram and token metadata can be generated
• Whether the token’s domain controls permit the new route

An independent token requestor can make network tokens more portable by provisioning them for the merchant rather than tying them to a single PSP. Merchants should confirm token ownership and portability before adopting any network-token solution.

Network tokens vs. gateway or PSP tokens

The word “token” is used to refer to several different payment technologies. Two of the most common are vault tokens and network tokens.

What is a gateway or PSP token?

A gateway token, PSP token, or vault token is a reference created by a payment provider. The provider stores the PAN in its vault and issues the merchant a token that references the stored card.

The merchant can use that reference for future payments without keeping the raw card information in its own application. This can reduce exposure to sensitive data and, when implemented correctly, help reduce PCI DSS scope.

The limitation is that the token usually works only within the provider that created it. If the merchant changes PSPs, the token may not be usable with the new provider.

What is different about a network token?

A network token is recognized by the card network as a payment credential. It can support issuer-managed lifecycle updates, domain restrictions, token assurance information, and transaction-specific security data.

That does not mean every network token can move freely between processors. If a PSP provisions the token under its own token requestor setup, the merchant may still face operational lock-in.

The most useful question is therefore not simply, “Is this a network token?”

Merchants should also ask:

1. Who is the token requester?

2. Who controls the token relationship?

3. Can the token be used through another supported processor?

4. Who generates the cryptogram and other required transaction data?

5. What happens to the tokens if the merchant changes providers?

Are network tokens replacing PANs?

Network tokens are reducing reliance on PANs in merchant-facing payment flows, but they are not eliminating the underlying card accounts.

The PAN still exists within the issuing and card-network ecosystem. The network token acts as a substitute credential that can be used in approved payment environments.

For merchants, the goal is not necessarily to remove every PAN from every part of the payment ecosystem. It is to reduce how often the merchant needs to collect, store, transmit, and present raw card data.

A mature credential strategy may use:

• Network tokens for eligible card-on-file transactions
• Account updater for cards that cannot be tokenized
• Secure PAN access for approved fallback scenarios
• Vault tokens to protect sensitive data within internal systems
• Monitoring to determine which credential produces the best authorization result

Network tokens and PANs may therefore coexist for some time, even as tokenized transactions account for a growing share of digital payments.

How are network tokens used in agentic commerce?

Agentic commerce introduces another participant into the payment flow: an AI agent that can research products, compare options, and potentially initiate a purchase on a consumer’s behalf.

Giving that agent unrestricted access to a raw card number would create unnecessary security and control challenges. Tokenized credentials provide a more practical foundation because they can be restricted to an agent, a merchant, a transaction context, or a set of user-approved instructions.

Visa Intelligent Commerce includes an agent-specific pass-through token designed for use at Visa-accepting merchants. Mastercard Agent Pay introduces agentic tokens that build on Mastercard’s existing tokenization capabilities. Both approaches are intended to give issuers, merchants, and consumers more visibility and control when an AI agent participates in a transaction.

These agentic credentials are related to network tokens, but the terms should not be treated as exact synonyms. A standard merchant network token is typically provisioned for a card-on-file (COF) or digital-payment use case. An agentic token can include additional controls and data that identify the agent and connect the transaction to the consumer’s authorization.

The broader point is clear: network tokenization provides much of the credential infrastructure that agentic commerce needs, but agent-initiated payments require more than a replacement card number. They also need authentication, user consent, transaction controls, agent identification, and merchant visibility.

What should merchants consider before adopting network tokens?

Network tokenization is not always a simple switch. Merchants should evaluate the complete credential and processing flow before beginning a rollout.

Processor and acquirer support

Confirm which processors accept network tokens, which networks and transaction types they support, and how required token data should be submitted.

A processor may support network tokens for e-commerce but not for every recurring, money movement, geographic, or debit routing use case.

Token ownership and portability

Determine who will act as the token requestor and whether the merchant retains access to its tokens if it adds or changes processors.

This decision can have a long-term effect on routing flexibility and vendor lock-in.

Network and issuer coverage

Visa, Mastercard, American Express, and Discover all support network tokenization, but provisioning eligibility and issuer participation can vary.

Merchants should track provisioning rates by network, issuer, card type, country, and use case rather than assuming that every stored card will receive a token.

PAN and account-updater coverage

A network-token strategy still needs a plan for cards that cannot be provisioned or tokens that become inactive.

Account updater and secure PAN fallback help merchants maintain payment coverage when a network token is unavailable.

Transaction classification

Cardholder-initiated transactions, recurring transactions, unscheduled credential-on-file payments, account funding transactions, and other merchant-initiated payments can have different requirements.

The transaction must be correctly identified and submitted. A token alone will not correct an improperly classified payment.

PCI DSS responsibilities

Network tokens can reduce a merchant’s reliance on raw card data, but they do not automatically eliminate PCI DSS obligations.

The impact on PCI scope depends on how the merchant collects the original card data, where tokens are stored, whether PAN access remains available, and how the overall payment environment is designed.

Performance measurement

Merchants should establish a baseline before migration and track:

• Token provisioning rates
• Authorization rates for tokens and PANs
• Decline reasons
• Fraud and chargeback rates
• Interchange and processing costs
• Token lifecycle events
• PAN fallback usage
• Performance by issuer, network, processor, and region

This makes it possible to measure the actual value of network tokenization rather than relying solely on industry averages.

How VGS supports network tokenization

VGS provides direct network token integrations with Visa, Mastercard, American Express, and Discover through a single platform. VGS is a non-PSP tokenization provider that allows merchants to manage payment credentials independently from the processor that ultimately handles the transaction.

A merchant can use a single VGS card object across Network Tokens, Account Updater, and Card Attributes. This gives the merchant a central way to manage the credential while still supporting multiple payment services and downstream processors.

With VGS:

• Eligible cards can be provisioned as network tokens across all four major U.S. card networks.
• Token lifecycle events can be managed without requiring the merchant to build separate integrations with each network.
• VGS network tokens can be routed to supported processors rather than being tied to one PSP’s proprietary vault.
• Account Updater and secure PAN access can help provide coverage when a network token is unavailable.
• Merchants can retain greater control over their payment data and processor strategy.

For merchants already using VGS to vault payment data, network tokens can be added within the same card-management infrastructure rather than introduced as a separate credential system.

The result is not simply a safer replacement for a card number. It is a more flexible foundation for managing credentials across recurring billing, e-commerce, payment orchestration, and emerging agentic-commerce flows.

Frequently asked questions about network tokens

• What is a network token in payments?

  A network token is a payment credential provisioned through a card network that replaces a cardholder’s PAN within an approved payment environment. It allows supported transactions to be processed without repeatedly presenting the original card number.

• Is a network token the same as a PSP token?

  No. A PSP token is usually a reference to a PAN stored in that PSP’s vault. A network token is recognized by the card network as a payment credential and can support network-managed lifecycle events and transaction security features.

• Are all network tokens portable between processors?

  No. Portability depends on the token requestor, merchant configuration, token domain controls, processor support, and access to required cryptograms and metadata. Network tokens provisioned by an independent provider such as VGS can provide more processor flexibility than tokens controlled by a single PSP.

• Do network tokens automatically update when a card expires?

  Network tokens support lifecycle management, which means the network and issuer can update the token when the underlying card changes. The outcome depends on the issuer and lifecycle event, and some tokens may instead be suspended or deactivated.

• Does every network-token transaction use a cryptogram?

  No. A fresh cryptogram is generally used for applicable cardholder-initiated token transactions. Subsequent merchant-initiated transactions, such as some recurring payments, follow stored-credential rules and may not include a new token cryptogram.

• Do network tokens improve authorization rates?

  They can. Current credentials and additional token information can help reduce preventable declines and give issuers more context. The size of the improvement varies by merchant, issuer mix, region, processor, and implementation.

• Do network tokens lower interchange fees?

  They may qualify for more favorable interchange treatment in some programs and regions. The savings are not universal and depend on the network’s current qualification rules and the merchant’s payment configuration.

• Do network tokens reduce PCI DSS scope?

  They can reduce exposure to raw card data, but they do not automatically remove a merchant from the PCI DSS scope. The effect depends on the design of the full card-data environment.

• Are digital-wallet tokens network tokens?

  Many digital wallets use network tokenization, but wallet tokens are usually provisioned for a device or wallet-specific domain. Merchant card-on-file network tokens use the same foundational technology but may have different controls and transaction flows.

• Why are network tokens important for agentic commerce?

  Network tokens provide a foundation for creating payment credentials that do not expose raw PANs and can be restricted to an approved context. New agentic-token programs build on this model by adding controls that identify the agent, reflect user authorization, and provide merchants and issuers with greater visibility into the transaction.

Build a more flexible credential strategy with VGS

Network tokens can help merchants reduce their reliance on static card numbers, strengthen credential security, and improve payment continuity. They also help reduce fraud and support smoother online purchases without exposing raw account numbers. Their value, however, depends on more than simply turning tokenization on.

Merchants need the right network coverage, token-requestor structure, processor support, lifecycle management, fallback strategy, and performance measurement.

VGS brings these capabilities together through direct card-network integrations and a unified Card Management Platform. Merchants can manage network tokens, Account Updater, card attributes, authentication, and other credential services while improving payment security and maintaining greater independence from any single payment processor.