Network Tokenization: A Complete Guide for Merchants

Network tokenization works by having the card network swap a customer’s card details for a token once the issuing bank approves the request, after which the merchant stores that token and uses it in place of the card number on every future payment.

Here’s a step-by-step breakdown of the process:

1. A customer initiates a transaction, entering their card details.
2. The merchant receives those details and passes them through a token gateway to the card network, which is responsible for generating a network token.
3. The card network shares the merchant’s request with the cardholder’s issuing bank, which either approves or denies it.
4. If the issuer approves the request, the card network then generates a token and sends it back through the gateway to the merchant.

Once this process is complete, the merchant can store this network token for future use. Any time that customer makes a purchase through that merchant, the merchant will use the token (as well as a cryptogram generated by the card scheme) in place of their payment credentials.

Who owns a network token, the merchant or the card network?

The card network owns the network token, not the merchant who uses it. When a card network issues a token for a stored card, it holds the token in its own vault and can update or revoke it, while the merchant only maintains the right to charge that token for as long as the customer relationship lasts. A merchant that wants to own raw customer card data would have to store PANs itself, which comes with heavier security and compliance obligations. 

Do network tokens expire?

No, network tokens do not expire the way physical cards do. A network token remains valid through a card reissue or replacement because the card network refreshes the token in the background whenever the underlying account details change. That persistence keeps stored-card and recurring payments from failing when a customer’s card is renewed, and it spares the merchant from chasing customers for updated card information.

Network tokens and the PANs they represent work as a linked pair, with the token being what a merchant stores and transmits for a payment, and the PAN being the underlying value mapped to that token, which stays locked in a secure vault on the card network’s side. To the issuer, the PAN is still the account number on record; the token just stands in for it as the payment is processed.

The mapping between a network token and a PAN is what enables a tokenized payment to reach an issuer in the first place. When a token-based transaction comes through, paired with its one-time cryptogram, the card network matches the token back to the underlying PAN and passes the request to the issuing bank for a decision. The merchant works only with the token from end to end, and the sensitive card number stays shielded. 

Both network tokens and PANs can be used as alternatives during authorization. A token service provider can submit whichever credential is more likely to win approval on a given transaction, falling back to the stored PAN if a network token attempt is declined for any reason unrelated to the customer’s funds.

Merchant tokenization is a form of payments tokenization that a merchant or its payments service provider (PSP) performs in-house, with no card network involved. The token it produces is called a merchant token, though you may see it referred to as a Payment Card Industry (PCI) token or gateway tokenization. Whatever the label, it substitutes for a customer’s card details and stays within that one merchant’s payments environment.

Keeping the token inside that environment reduces the amount of raw card data a merchant stores, which eases the PCI DSS compliance burden that comes with handling PANs directly. The card network and the issuing bank play no part in creating or maintaining the token.

How do merchant tokens differ from network tokens?

Though they both use a unique numeric sequence to replace a value, merchant tokens differ from network tokens in that they’re issued by a merchant or its PSP and exist solely within that merchant’s payments ecosystem.

The problem with this approach is that multiple parties — not just the merchant — need to be able to securely handle card data, including the PAN, expiration date, and card verification value. This introduces multiple points of failure and increases the risk of consumers’ payments card data being compromised. 

Network tokens mitigate the risk of exposure by making cardholders’ issuing banks part of the token approval process. Because a network token is designed to stay valid when a card is reissued, it also supports uninterrupted card-on-file and recurring billing. For best results, merchants should use a combination of merchant tokens and network tokens to secure payments.

Though it does not happen often, a card network may randomly change the network token for a customer’s PAN, making it unsuitable for any merchant that wants to use that token to track customer buying patterns and monitor their fraud risk. Additionally, if a merchant were to change its network provider, its network token would change as well, causing that merchant to lose cardholders’ payments history.

How does network tokenization work compared to merchant tokenization?

Both network tokenization and merchant tokenization begin the same way, with the customer entering card details that pass through a gateway, but while network tokenization sends the request to the card network and issuing bank for approval before generating a token, with merchant tokenization, a PSP returns the token without that approval. 

Here’s what that process looks like:

1. A customer initiates a transaction by entering their card details.
2. The merchant receives those details and passes them through a payments gateway to a third-party tokenization service provider, which is responsible for generating a merchant token.
3. The tokenization service provider generates a merchant token and sends it back through the gateway to the merchant.

Again, once this process is complete, the merchant can store the merchant token for future use. You’ll notice that merchant tokenization does not require any approvals, and that neither the card network nor the issuing bank are involved in the process. As a result, merchant tokens are only secure when they are within a merchant’s ecosystem.

Yes, digital wallets such as Apple Pay and Google Pay are powered by network tokens, which is why most merchants already accept tokenized payments, even if they’ve never set up network tokenization themselves. When a customer adds a card to a wallet, the card network issues a token that stands in for the PAN on that device, and every wallet payment that follows uses the token in place of the card number.

This goes beyond eCommerce. A tap-to-pay purchase at a physical terminal is a tokenized transaction, as is any payment made from a card loaded into a mobile wallet, whether the customer is buying online or standing at the register. The surrogate credential and one-time cryptogram that protect a card-on-file purchase do the same work behind a contactless tap. 

Network tokenization already underpins a large share of everyday wallet and contactless transactions. Extending it to card-on-file and recurring payments brings the rest of a merchant’s transactions up to the same standard of security and acceptance.

Network tokens tackle some of the biggest problems merchants face with card payments, including transactions that are wrongly declined, outdated card credentials, fraud exposure, poor protection of stored card data, and friction during the checkout process caused by authentication. 

Let’s take a closer look at each one:

False declines

Due to the fraud risks commonly associated with card-not-present (CNP) payments, authorization and acceptance rates for online transactions are substantially lower than those for in-person, card-present ones. And with low authorization and acceptance rates comes a higher rate of false declines: when a legitimate transaction is wrongly rejected due to a suspicion of fraudulent activity.

False declines can be incredibly damaging to a merchant’s business. According to PYMNTS Intelligence, 35 percent of cardholders are likely to abandon a merchant after a single card decline. To avoid losing business and loyal customers, merchants need a way to understand and address declined transactions. There are a few ways they can go about this, including working with a payments service provider capable of orchestrating multi-acquirer strategies and offering a wider variety of payment methods.

Network tokenization is also key to limiting false declines and boosting acceptance rates. Since issuing banks are involved in the network token approval process, there’s greater trust at the outset. Visa reports that its tokenized CNP transactions receive a 4.6 percent lift in authorization rate globally, compared to transactions that use the PAN. Network tokens are also updated dynamically, reducing false declines and involuntary churn, especially among subscription businesses.

Out-of-date accounts

One of the biggest challenges in eCommerce is that stored card details become unusable when cards are lost, stolen, or expire. Although consumers appreciate the convenience of one-click checkout when finalizing purchases, having outdated, unusable card credentials on file can lead to false declines — which can, in turn, increase cart abandonment rates.

Network tokens completely resolve this issue because issuing banks are mandated by card networks to update their tokens in real time to reflect any account changes. This reduces the rate of false declines, saves merchants the administrative effort of reaching out to consumers to update their payment credentials and creates a frictionless payments experience for consumers.

Increased fraud

According to a study from LexisNexis, every $1 of fraud costs US merchants $4.61, a figure that continues to climb as fraudsters concentrate on digital channels. Over the past few years, end-to-end encryption and EMV Specifications have made card-present, point-of-sale transactions more secure, forcing fraudsters to redirect their attention to CNP payments and increasing costs for merchants.   

Typically, when a fraudulent CNP transaction takes place, the cardholder will initiate a chargeback with their issuing bank. In many cases, merchants bear financial liability for these chargebacks, since the issuer isn’t involved until the payment is authorized. With network tokenization, the issuer is actively involved in the approval of the network token.

Poorly protected card data

For all their built-in protections, payment cards still have their vulnerabilities and can be attacked on several fronts. More specifically, criminals have the opportunity to steal payments card data wherever it is entered, stored, or transmitted. Network tokenization protects card data in transmission by generating a secure token to represent a cardholder’s PAN. This issuing network then uses this token, which cannot be decoded, in place of the cardholder’s PAN for all transactions.

Cardholder-initiated transactions also require a dynamic cryptogram generated by a card network for added security. Each cryptogram is unique to the network token, the onboarded merchant, and the authorized transaction.

Payments friction

Although strong customer authentication (SCA) requirements in Europe make card-based payments more secure, they also introduce additional security checks to the checkout process, lowering approval rates.

For merchants, a frictionless payments experience is non-negotiable. Fortunately, network tokenization facilitates SCA without the friction by replacing sensitive card details with tokens and using cryptograms for enhanced security. When strategically leveraged in combination with SCA exemptions, such as risk-based authentication, merchants can deliver a robust, compliant security framework without compromising a convenient, consumer-friendly checkout process.

Yes, there is a small fee for using network tokens, though tokenized transactions usually cost less to process overall than ones sent on the PAN. Card networks and processors may apply a per-use or assessment charge in certain cases, but lower interchange rates and the reduced fraud and decline costs that tokenization offers tend to outweigh those charges.

Yes, network tokenization can reduce both chargebacks and the dispute costs attached to them. Because a network token is bound to one merchant and every transaction comes with a single-use cryptogram, it’s harder to reuse stolen credentials, so fewer fraudulent charges go through in the first place. Fewer fraudulent charges lead to fewer chargebacks, which lowers dispute fees and helps merchants stay clear of card network chargeback-monitoring programs.

Merchants that store cards on file and charge customers more than once stand to benefit most from network tokenization because stale or reissued card credentials can cause issues with payments. Because a network token is bound to one merchant and every transaction carries a single-use cryptogram, stolen credentials are far harder to reuse, so fewer fraudulent charges go through in the first place. Fewer fraudulent charges lead to fewer chargebacks, which lowers dispute fees and helps a merchant stay clear of card network chargeback-monitoring programs.

This benefits a wide range of businesses:

• Streaming services and software as a service (SaaS) providers that bill on a subscription basis depend on the credentials they have on file staying valid. Network tokenization keeps these credentials current throughout reissues without the customer having to lift a finger, which protects recurring revenue from involuntary churn.
• Travel and hospitality businesses, such as airlines and hotels, often authorize a card at booking and capture the payment weeks or months later, by which point the original card may have changed. A network token that updates in the background prevents that delayed capture from failing.
• Marketplaces and platforms that route payments through more than one acquirer benefit as well, since a network token is recognized across the payments ecosystem rather than locked to a single processor. 
• High-volume retailers often see authorization-rate improvement applied to every transaction, where even a fraction of a percent can add up to a significant amount of recovered revenue across millions of orders.

Network tokenization does not make merchants PCI compliant on its own, though it can reduce merchants’ PCI Data Security Standard (PCI DSS) compliance burden. PCI DSS compliance depends on how a business handles cardholder data across all of its systems, and network tokenization addresses one important piece of that puzzle.

When a network token stands in for the PAN, the merchant stores and transmits far less sensitive card data directly, which shrinks the portion of the environment that falls within PCI scope. A business that already meets PCI DSS can still narrow what it has to assess by replacing stored PANs with tokens. What network tokenization doesn’t do is eliminate a merchant’s obligation to assess and document compliance. They still need to know where cardholder data lives and confirm that the controls around it meet the standard.

Network tokenization supports agentic commerce by enabling AI agents to make payments on customers’ behalf without ever handling the underlying card number. Agentic payments need a credential that can be scoped tightly to one agent and one set of permissions, which is exactly what network tokenization does.

For examples of network tokenization and agentic commerce working hand-in-hand, look to Visa’s Intelligent Commerce, which issues agent-specific tokenized credentials and manages their lifecycle through a dedicated set of application programming interfaces. Mastercard’s Agent Pay works similarly, issuing tokenized “Agentic Tokens” that bind a credential to a specific agent and a defined set of permissions, so a model completing a purchase never sees the raw card. 

This only works because network tokens are hard to misuse and only valuable within a very specific context. When that same restriction is applied to AI agents, it helps merchants tell the difference between authorized and malicious agents. Merchants without a network token strategy may struggle to participate in agentic commerce as this channel grows, so it’s important to lay the groundwork for tokenization as soon as possible.

Network tokenization isn’t strictly mandatory for merchants in most markets, though it’s increasingly difficult to avoid. Card networks are steering the payments industry toward network tokens through pricing incentives and, in some regions, direct mandates. Merchants who postpone adoption risk higher costs and lower approval rates as token-based payments processing becomes the norm.

The most effective way for merchants to implement network tokenization is to partner with a token service provider, such as ACI Worldwide, that integrates with the card network on their behalf and manages those connections as the networks evolve. Setting up a direct integration with the major card networks is the obvious alternative, but their rules and APIs change frequently, which can be difficult for merchants to manage. Handling network tokens across multiple payment gateways builds in an additional layer of complexity, which a provider can manage on your behalf.

The ACI Payments Orchestration Platform is capable of not only integrating with all major card networks for network tokenization but also processing payments via multiple acquirers. By consolidating both payments and tokens within a single platform, the ACI Payments Orchestration Platform enables merchants to enhance payments security and PCI compliance, create frictionless omnichannel customer experiences, and increase conversion rates.