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 requester, 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 stolen token should not work outside its approved environment.

How do merchants access network tokens?

A merchant cannot generate a network token itself. Network tokens are provisioned either directly through the networks, or more commonly, by a token service provider (TSP). The Token Requester may be the merchant itself, or a PSP, processor, gateway, or independent provider acting on the merchant’s behalf.

For merchants, the practical question is therefore not simply whether a provider “supports network tokens.” Merchants should understand who acts as the Token Requester, which network token services the provider connects to, who controls the resulting Token Requester relationship, and whether those tokens remain usable if the merchant changes processors.

The number of hops between the merchant and the card network also matters. Each intermediary in the token-request path adds another network call, increasing latency and introducing another potential point of failure. A token service provider that connects directly to Visa Token Service and Mastercard Digital Enablement Service, acting as the Token Requester itself, has fewer dependencies than one that routes through an upstream intermediary. At checkout, this more direct architecture can mean lower latency and greater reliability.

For example, VGS’s network token onboarding registers merchant organizations with Visa Token Service and Mastercard Digital Enablement Service to obtain the Token Requester IDs used to provision merchant-specific network tokens.

Where are network tokens available?

Network token issuer coverage is broad in most major regions, but it varies by card network, region, and issuer. For global networks like Visa and Mastercard, coverage tends to be high: 99% of issuers in the U.S., 97% across Canada and Europe, 97% in Latin America, 99% in C.E.M.E.A., and 96% in the Asia Pacific support network token provisioning. This is roughly what we see today, though it’s likely to keep changing as adoption grows.

These numbers reflect the reach of networks with global issuance and acceptance footprints. For other card networks, coverage depends on their specific issuer relationships and regional presence, which means provisioning eligibility can look very different depending on the network a given card runs on. Merchants processing volume across multiple networks should track provisioning rates by network and region rather than assuming uniform availability.

These aggregate figures also move over time. A network or issuer that shows a coverage gap today may close it within a quarter, and gaps that appear closed at a regional level can still hide thin coverage for specific issuers within that region. Coverage isn’t a fixed number that merchants can check once. It’s a moving target that should be monitored by network, geography, and issuer on an ongoing basis, not treated as a one-time data point.

What should a merchant’s token fallback strategy be?

Not every card in a merchant’s portfolio will receive a network token. Token coverage can vary by network, issuer, card program, region, and use case, and some credentials may be ineligible for tokenization or unable to be provisioned. Even after a token is successfully provisioned, its status can change over time.

That means merchants need a fallback plan for when a network token is unavailable or becomes inactive.

One approach is to maintain secure access to the PAN as a secondary credential. If a network token can’t be provisioned for a given card, the merchant can still process transactions using the PAN where appropriate. If a previously active token becomes unavailable, the PAN may also provide a fallback when the underlying credential remains valid.

The catch is that a PAN is only useful if it’s current. Cards expire, and cards can be replaced or reissued. When that happens, the PAN a merchant has on file may no longer work, resulting in a preventable decline.

This is where Account Updater fits in. Account Updater helps keep PAN-based credentials current by retrieving updated card information from the card networks. That can include changes to account numbers or expiration dates when cards are replaced or reissued.

A practical credential strategy looks something like this: provision network tokens wherever possible, use the network token as the preferred credential, maintain secure access to the PAN as a fallback, and use Account Updater to help keep those PAN-based credentials current. The goal is broad credential coverage across the portfolio, rather than relying on a single credential type for every card.

Network tokens vs. PANs

A PAN is the original card number associated with a credit or debit card account. It is typically 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 must 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.

It’s important to note that network tokenization is also still maturing. Issuer support varies by region and can change over time, and provisioning behavior is not always consistent across networks or card programs. Merchants should use network tokens where they can, but they should also maintain a current PAN as a fallback and keep it up to date through an account updater service. A token first strategy works best when there’s a plan for the cards and regions where tokens aren’t available yet.

How does network tokenization work?

The exact flow varies by network, token requester, 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 (CIT), meaning a transaction where the cardholder is actively present and directly initiates the payment, such as an online checkout, 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 requester, token service provider (TSP), processor, network, and issuer.

   The flow differs for certain subsequent merchant-initiated transactions (MIT), meaning transactions the merchant initiates without the cardholder directly present, such as a recurring subscription charge or a scheduled installment payment. 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. Visa reports a 4.3% increase in authorization across its broader network token data, though this result should not be treated as a guaranteed lift for every merchant.

That average also masks issuer-level variation. Some issuers authorize a token at a lower rate than they would authorize the same transaction on the underlying PAN, even when that issuer generally supports network token provisioning. Supporting tokenization and optimizing for it are not the same thing. Merchants that track authorization performance by issuer, not just by network, can identify where a PAN may still outperform a token and route accordingly.

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. Issuer support for network token provisioning varies by region, card program, and network, and that coverage is still evolving. Even in regions with high provisioning rates, some cards in a merchant’s portfolio won’t receive a token. Merchants should maintain secure access to PANs as a fallback credential for those cards and use Account Updater services to keep them current. A fallback PAN that’s expired or tied to a reissued card doesn’t help when the token is unavailable. The strongest credential strategies treat network tokens as the preferred option and the PAN as a maintained backup, not the other way around.

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.

Actual savings depend on the card network, region, merchant category, transaction type, processor, and whether all qualification requirements are met. 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

A payment service provider (PSP) is a third-party company that processes payment transactions on behalf of a merchant. Most merchants work with at least one PSP, and many with several, for reasons such as geographic coverage, redundancy, cost management (including interchange savings), or authorization optimization.

Network tokens can support this kind of multi-PSP setup, but with an important caveat: a network issued token is not automatically portable across all processors.

That’s because a token can be provisioned under a specific PSP’s token requester identity, or configured for one particular merchant-processor relationship. Whether it can be moved to a different processor depends on:

• Who controls the token requester 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

One way around this is to use an independent token requester. Rather than tying a token to a single PSP, an independent token requester provisions it directly for the merchant, making it more portable across processors. Because of this, merchants should confirm who owns their tokens and how portable they are before adopting a network token solution.

Network tokens vs. gateway or PSP tokens

The word “token” is used to refer to several different payment technologies. Two common categories are provider-specific tokens, such as gateway or PSP-issued tokens, and network tokens.

What is a gateway or PSP token?

A gateway token or PSP 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 card networks, such as Visa, Mastercard, American Express, and Discover, 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 requester 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 serves as a substitute credential for use 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
• PCI 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. American Express’s Agentic Commerce Experiences (ACE) developer kit takes a similar approach, using single-use, intent-bound tokens to enable registered AI agents to complete payments within its closed-loop network. All three approaches are intended to provide issuers, merchants, and consumers with greater visibility and control when an AI agent participates in a transaction.

A standard merchant network token is typically provisioned for a card-on-file (COF) or digital-payment use case. To address agentic commerce specifically, the networks have introduced a distinct category called agentic tokens. These are not a separate credential architecture but rather a form of network token with additional controls and data layered on top. These controls identify the agent, connect the transaction to the consumer’s authorization, and distinguish agent-initiated activity from standard COF transactions.

Network tokenization provides much of the credential infrastructure used by agentic commerce, and agentic tokens are built directly on that same underlying token architecture. Agent-initiated payments also involve authentication, user consent, transaction controls, agent identification, and merchant visibility, which is why the network programs listed above layer those capabilities on top of the standard network token, resulting in the Agentic Token as the purpose-built variant for this use case.

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 requester 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. That variability is not a reason to avoid network tokens. It’s a reason to understand exactly where the gaps are and plan around them.

Even issuers that support provisioning can show different authorization performance when processing a token versus the underlying PAN. Supporting network tokens and optimizing for them are not the same thing, and merchants who only track whether a token was issued, without also tracking its performance, can miss cases where the PAN is still the better credential to route through.

Coverage and performance also evolve over time, as issuer support expands and authorization behavior shifts. 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.

If a network token can’t be provisioned for a given card, the merchant still needs a way to process that transaction. That’s what the PAN fallback is for. But a fallback PAN is only useful if it’s current, and cards get replaced or reissued regularly. Account Updater keeps the PAN current so the fallback credential doesn’t go stale while token coverage catches up.

Transaction classification

Cardholder-initiated transactions (CIT), recurring transactions, unscheduled credential-on-file payments, account funding transactions, and other merchant-initiated transactions (MIT) 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. 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 is the only independent vault and non-PSP that 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 and owning credentials for recurring billing or subscription services, multi-PSP payment orchestration strategy, 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 requester, 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 transactions (CIT). Subsequent merchant-initiated transactions (MIT), such as some recurring payments, follow stored-credential rules and may not include a new token cryptogram. That said, cryptogram requirements vary by network. Some networks expect a cryptogram on the first MIT transaction using the token, even if subsequent MITs do not require one. Merchants should confirm the specific rules for each network they support.

• Do network tokens improve authorization rates?

  Yes, 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?

  Yes, 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?

  Yes, 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 their 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, verify user authentication, and provide merchants and issuers with greater visibility into transactions.

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 requester structure, processor support, lifecycle management, fallback strategy, and performance measurement. That fallback strategy matters because network tokenization is still evolving.

VGS brings these capabilities together through direct card network integrations and a unified Card Management Platform. Merchants can manage tokens, keep card data up to date on file, receive enriched card data, authenticate transactions, and use other credential services while improving payment security and maintaining greater independence from any single payment processor.