Every online store that saves a card ends up holding a reference to it. What that reference actually is, and who issues it, turns out to matter a great deal for how many payments get approved and how many quietly fail eighteen months later when the plastic gets reissued.
Network tokens are the card networks’ answer to that problem. Instead of the merchant or the payment service provider holding a surrogate for the card, the network itself (Visa, Mastercard, American Express, Discover) issues a token that is bound to the merchant, kept current by the issuer, and refreshed automatically when the underlying account changes.
This guide explains the mechanics, the realistic upside, and the parts that vendors tend to oversell. It sits inside our wider work on payment fraud and chargeback prevention, because tokenization is as much a risk control as it is a conversion lever.
In short
- Network tokens are issued by the card networks, not by your gateway, and they stay valid across card reissues and expiry changes.
- The reported authorisation lift is real but modest, typically quoted in the low single digits of percentage points, and it is concentrated in recurring and card-on-file traffic rather than one-off guest checkouts.
- Wallets already run on tokens. Apple Pay and Google Pay have used network tokenization since launch, so wallet volume is not incremental token adoption.
- Migration is a data project, not a checkout project. The work sits in your vault, your retry logic, and your reconciliation, not in the payment form.
- Tokens do not reduce fraud liability by themselves. Liability still moves through authentication rules such as 3-D Secure 2, not through the token format.
Card on file, PSP tokens and network tokens are not the same thing
Three different things get called “tokenization” in payment conversations, and conflating them is the most common source of confusion in vendor calls. They differ in who issues the surrogate value, where it is valid, and what happens when the cardholder’s account changes.
Card on file as a commercial arrangement
Card on file is not a technology. It is an agreement with the cardholder that you may charge a stored credential again later, and the card networks attach specific rules to it. Those rules cover how you flag the initial transaction, what consent language you show, and how subsequent charges must be identified in the authorisation message.
You can run card on file with a PSP token, a network token, or, in a shrinking number of legacy cases, with raw card data held inside a compliant environment. The commercial arrangement and the storage format are separate decisions.
PSP or gateway tokens
A PSP token is a reference issued by your payment provider that points to a card record inside their vault. It is convenient, it keeps primary account numbers out of your systems, and it substantially narrows the scope of your Payment Card Industry Data Security Standard obligations, which are published by the PCI Security Standards Council.
The limitation is portability and freshness. A gateway token is valid only with that gateway. If the card behind it is reissued, the token still resolves to a stale account number unless the provider subscribes to an updater service and applies the change.
Network tokens
A network token is issued by the card network under the EMV Payment Tokenisation specification maintained by EMVCo. It looks like a card number, it passes through the same message formats, and it is restricted to a defined domain, usually one merchant or one wallet on one device.
The important property is that the network holds the mapping to the real account. When the issuer reissues the card, the mapping is updated at the network and your token keeps working without you doing anything.
| Property | PSP or gateway token | Network token | Raw card on file |
|---|---|---|---|
| Issued by | Your payment provider | Visa, Mastercard, Amex, Discover | Nobody, it is the real number |
| Valid where | That provider only | The merchant or wallet domain it was provisioned for | Anywhere the card works |
| Survives card reissue | Only via an updater subscription | Yes, by design | No |
| Survives expiry date change | Only via an updater subscription | Yes, the token carries its own expiry | No |
| PCI DSS scope impact | Large reduction | Large reduction | Full scope |
| Portable to a second provider | Migration project with the incumbent | Easier, the token requestor identity governs access | Not applicable |
| Typical failure mode | Stale account number, soft decline | Provisioning failure at enrolment | Hard decline after reissue |
How a network token is issued and updated
The provisioning flow is worth understanding because most migration problems are provisioning problems, not transaction problems. Nothing here is exotic, but each step has a failure mode that shows up as a silent gap in your token coverage.
The token requestor
Every party that asks for a network token registers with the networks as a token requestor and receives an identifier. In practice your PSP or acquirer holds that registration and requests tokens on your behalf, so the token requestor identity and your merchant identity are linked but not identical.
This matters for portability. If you later change providers, whether your tokens travel with you depends on how that requestor relationship was set up, and it is a question worth asking before you sign rather than after.
Provisioning and issuer approval
Provisioning sends the card details, the merchant context and the requestor identity to the network, which asks the issuer to approve the token. The issuer can decline. Coverage is not universal, and it varies by issuer, by country and by card product, particularly for smaller regional banks and some commercial card portfolios.
Plan for partial coverage. A realistic migration ends with a mixed vault where some credentials are network tokens and some remain provider tokens, and your systems need to handle both without special casing every code path.
Cryptograms and domain restriction
A network token on its own is not a payment credential in the way a card number is. For most flows it is accompanied by a cryptogram, a single use value that proves the token is being presented by the party entitled to use it. For merchant initiated recurring charges the rules differ by network and by transaction type.
Domain restriction is the security payoff. A token provisioned for your store cannot be replayed at another merchant, which is why a token vault breach is a materially smaller event than a card data breach. It is not zero risk, but the stolen material has far less resale value.
Lifecycle events
Once a token exists, the network pushes lifecycle events: the card was reissued, the account was closed, the token was suspended, the customer’s issuer changed the expiry. Your provider should surface these to you, and you should be doing something with them, such as suppressing dunning attempts on a closed account instead of retrying it eleven times.
Authorisation rate gains and where they come from
The headline claim in most vendor decks is an authorisation rate uplift. The claim is directionally true, and the mechanism is understandable, but the size depends almost entirely on the composition of your traffic.
The four mechanisms
First, credential freshness. Charges that would have failed against a reissued card now succeed because the network resolved the token to the current account. This is the single largest contributor for subscription and repeat purchase businesses.
Second, issuer risk scoring. Some issuers treat a tokenized transaction as lower risk because domain restriction limits the blast radius of a compromise, and that can nudge a marginal decision from decline to approve.
Third, data quality. Token provisioning tends to force cleaner merchant and transaction metadata into the authorisation message, and better data is generally scored better.
Fourth, fewer step-ups. In markets with strong customer authentication requirements, a well provisioned token combined with an appropriate exemption can reduce the number of transactions pushed into a challenge, and every avoided challenge is abandonment you did not suffer. The interaction with 3-D Secure 2 is where most of the practical tuning happens.
Realistic expectations by traffic type
Figures quoted publicly by the networks and by large processors have generally sat in the low single digits of percentage points. Treat any specific number you are given as a claim to be tested on your own traffic, because published averages blend merchant categories that behave nothing like each other.
| Traffic type | Where the gain comes from | Expected relative benefit | What to measure |
|---|---|---|---|
| Subscription billing | Credential freshness across reissues | Highest | Involuntary churn rate, month 13 and later |
| Card on file repeat purchase | Freshness plus issuer scoring | High | Approval rate on returning customers |
| Wallet checkout | Already tokenized, no incremental gain | None from migration | Wallet share of checkout, not approval delta |
| Guest one-off checkout | Marginal issuer scoring only | Lowest | First attempt approval rate |
| High risk or high ticket | Scoring, offset by unchanged fraud rules | Variable | Approval rate and fraud rate together |
How to measure it honestly
The common measurement mistake is comparing tokenized traffic against untokenized traffic in the same period. Those two populations are not comparable, because the cards that failed to provision skew toward the issuers and card products that decline more often anyway.
The cleaner approach is a holdout: provision tokens for a random share of eligible credentials, leave a control group on provider tokens, and compare approval rates within the eligible population only. If your provider cannot support a holdout, compare the same cohort before and after migration and be honest that seasonality is confounding you.
A worked example of the arithmetic
Take a subscription business with 200,000 active monthly billings and a blended renewal approval rate of 91 percent. That is 18,000 failed renewals a month before any retry logic runs. Suppose analysis of decline reasons shows that roughly a third of those failures map to invalid, expired or closed credentials rather than to insufficient funds or fraud rules.
That subset, about 6,000 attempts, is the part network tokens can plausibly address. If freshness recovers even half of it, the effect on the blended approval rate is around 1.5 percentage points, which sounds unimpressive until you convert it into retained subscribers and multiply by lifetime value.
Run that same arithmetic before you commit budget. If your decline mix is dominated by insufficient funds, which it often is in lower ticket consumer categories, the honest forecast is close to zero and the project should be justified on security scope reduction instead.
Decline codes are the diagnostic, not the approval rate
Blended approval rate is a poor primary metric because it moves for reasons that have nothing to do with tokenization: traffic mix, seasonality, a new market, a pricing change. Decline reason codes are far more diagnostic, and most providers expose them in some normalised form.
Build the baseline as a distribution rather than a single number. Group the codes into credential problems, funding problems, fraud or risk refusals, and technical failures. Tokenization should visibly compress the first group and leave the others broadly untouched. If your dashboard shows the fraud refusals dropping too, be suspicious of the measurement before you celebrate.
Card reissues, expiries and the updater services
Before network tokens, the answer to card churn was account updater services. Visa Account Updater and Mastercard Automatic Billing Updater let a merchant or provider query for refreshed card details on a batch cadence, and they remain widely used.
Updater services versus token lifecycle management
An updater is a pull model with latency. You submit a batch, you get changes back, you apply them. Depending on how often you run it and how quickly the issuer publishes the change, a customer can sit with a stale credential for days or weeks, which is exactly when a renewal charge fails.
Token lifecycle management is closer to a push model. The mapping is updated centrally, so the next authorisation resolves correctly even if you never received or processed a notification. In practice most teams run both for a period, because updater coverage and token coverage do not overlap perfectly.
| Dimension | Account updater | Network token lifecycle |
|---|---|---|
| Model | Batch pull, merchant initiated | Central mapping, updated at the network |
| Latency | Depends on your batch cadence | Effective at the next authorisation |
| Coverage | Participating issuers only | Participating issuers only, different list |
| Cost basis | Usually per record queried | Usually per token or bundled |
| Data you receive | Updated PAN and expiry | Usually a status event, not the PAN |
| Good for | Legacy vaults, non tokenized cards | Ongoing card on file and subscriptions |
What this does to involuntary churn
Involuntary churn, meaning subscribers lost to a failed payment rather than a decision to cancel, is where the money usually is. If your renewal failure rate is meaningfully driven by reissues, freshness improvements show up in retained revenue faster than in any approval rate dashboard.
Instrument it that way. Track failed renewals split by decline reason, and watch the reasons that map to invalid or expired credentials specifically. A migration that does nothing to your blended approval rate can still cut that category substantially.
Wallets: how Apple Pay and Google Pay use tokens
Wallets are the reason network tokenization scaled in the first place, and understanding the difference between wallet tokens and merchant tokens prevents a lot of double counting.
Device tokens versus merchant tokens
When a cardholder adds a card to a wallet, the wallet provider acts as the token requestor and a token is provisioned to that device. It is bound to the device, and each transaction carries a cryptogram generated by the secure element or its software equivalent. The merchant never sees the underlying card number.
A merchant token, sometimes called a card on file token, is provisioned to you rather than to a device. It is the thing you store for future charges. Both are network tokens, but they are different instruments with different lifecycles, and you cannot use a wallet device token to bill a customer later.
What that means for your metrics
If your wallet share is already high, a card on file tokenization project will move a smaller slice of your volume than the vendor forecast assumes, because the wallet portion was tokenized before you started. Segment your baseline before you model the benefit.
Wallet adoption itself keeps moving. In August 2026 Walmart switched on Apple Pay after years as the most prominent US holdout, which is a useful reminder that wallet share in your category can shift on a single large retailer’s decision.
In store versus online
In store, the token plus cryptogram model has been the norm for contactless wallet payments for years. Online and in app, the same underlying mechanism applies, but the merchant integration differs and the exemption and authentication rules that apply to the transaction differ by market.
What the merchant actually controls
Very little of the wallet token flow is under merchant control, which is mostly a good thing. You do not manage provisioning, you do not hold the credential, and you do not handle the cryptogram beyond passing it on. What you do control is presentation: whether the wallet button appears, where it appears, and whether it is offered before the customer starts typing a card number.
Those presentation decisions move wallet share more than any backend work, and wallet share is itself an approval rate lever because wallet transactions are authenticated and tokenized by default. Teams chasing a token migration sometimes ignore the cheaper win sitting on their own checkout page.
Migration: moving an existing card vault to network tokens
The migration is mostly unglamorous data work. It rarely touches the checkout page, which surprises teams who expect a front end project.
A workable sequence
- Inventory the vault: how many stored credentials, by card network, by issuer country, by last use date.
- Prune first. Credentials unused for a long period are unlikely to provision cleanly and are not worth paying to tokenize.
- Confirm who holds the token requestor registration and what happens to your tokens if you leave that provider.
- Run a bulk provisioning pass on a subset, measure the provisioning success rate, and inspect the failures by issuer.
- Decide the fallback rule: what your system does when a token is unavailable, and whether it retries on the provider token.
- Wire lifecycle events into your billing logic before you scale up, not after.
- Provision the remaining vault, keeping a control group if you intend to measure the lift credibly.
Where migrations go wrong
The recurring failures are predictable. Teams treat provisioning as fire and forget and never notice that a fifth of the vault silently failed. Retry logic keeps hammering tokens that lifecycle events already reported as closed. Reconciliation breaks because the token, not the card, now appears in the transaction record and the finance team’s matching rules were written against the last four digits of the real card.
That last one is worth flagging early. Network tokens carry their own last four digits, which are usually different from the card’s. Anything in your stack that displays or matches on those digits, including customer service tooling and receipts, needs to be checked.
Consent and disclosure obligations do not change
Changing the storage format does not alter what you told the cardholder when they agreed to let you store the credential. The card on file consent, the notice requirements for recurring charges, and the cancellation paths all remain as they were. If anything, migration is a good moment to audit whether your current disclosures match what the networks and your acquirer actually require.
Questions to put to your payment provider
Most of the value in a provider conversation comes from asking about coverage and portability rather than about the headline uplift figure. These questions surface the constraints that will actually shape your project.
- What is your observed provisioning success rate for merchants in our category and our issuing markets, and how does it break down by network?
- Who is the registered token requestor, and if we move to another provider, what specifically happens to our tokens?
- How are lifecycle events delivered to us, at what latency, and what is the retry behaviour if we fail to acknowledge one?
- Do you support a randomised holdout so we can measure the approval lift against a real control group?
- How are network tokens priced here: per provisioning, per token per month, per transaction, or bundled into the processing rate?
- What happens to a transaction when a token is unavailable or suspended, and can we configure that fallback?
- How do tokens interact with our authentication and exemption strategy in each market where we trade?
- Which parts of the reporting change, specifically what identifier appears in settlement files and chargeback notices?
Costs, risks and what tokens do not fix
Network tokens are a genuine improvement, and they are also routinely oversold. Being clear about the limits keeps the business case honest.
What they do not do
They do not shift fraud liability. Liability moves through authentication and network rules, not through the format of the stored credential. A tokenized transaction that was not authenticated sits in the same liability position as an untokenized one.
They do not stop disputes. If a customer denies a charge they in fact made, the token is irrelevant to the outcome, which is a matter for chargeback representment and the evidence you can assemble. The same applies to friendly fraud, where the credential was legitimate and the dispute is about intent.
They do not remove PCI DSS obligations entirely. Scope narrows, sometimes dramatically, but the assessment still applies to whatever remains in your environment, and the determination is between you, your assessor and your acquirer.
New operational risks
Concentration is the main one. If the network’s tokenization service is degraded, the affected transactions are the ones you migrated, so a documented fallback path matters more after migration than before. Ask what that fallback is and test it rather than assuming it exists.
There is also a reporting discontinuity at cutover. Metrics that looked stable can jump for structural reasons, and if nobody expects that, the team spends a week chasing an incident that is really a definitional change.
How the costs land
Pricing models vary. Some providers charge per provisioning request, some charge a small monthly fee per active token, some fold it into the processing rate, and some offer it at no incremental line item because the approval lift benefits them as well. None of these is inherently better, but they behave very differently against a large dormant vault.
A per token monthly fee applied to a vault full of credentials that have not been charged in two years is pure cost with no offsetting revenue, which is the practical argument for pruning before provisioning. Model the fee against active credentials only, then check what the contract actually bills against.
The engineering cost is usually larger than the network fee and is concentrated in three places: the provisioning job and its error handling, the lifecycle event consumer, and the reconciliation changes. Scope those explicitly rather than treating the work as a configuration change.
Fitting it into a wider payments programme
Tokenization pays off best alongside decline handling, retry scheduling, authentication tuning and dispute operations, because those levers compound. Our guide to payment fraud and chargeback prevention covers how these pieces fit together across the payment lifecycle.
How to use this guide
This article is general information for retail and e-commerce teams, not legal, tax, compliance or regulatory advice, and it is not a substitute for your own scheme and acquirer documentation. Card network rules, tokenization specifications and authentication requirements change regularly and differ by market and card product.
Verify current rules, rates and thresholds against the primary sources: the EMV Payment Tokenisation specification published by EMVCo, the standards published by the PCI Security Standards Council, and the operating regulations issued by Visa, Mastercard, American Express and Discover. For obligations that apply to your specific business, consult your acquirer, a qualified security assessor, or a payments lawyer in the relevant jurisdiction.
FAQ on network tokens
What is a network token in simple terms?
It is a substitute card number issued by a card network such as Visa or Mastercard, tied to a specific merchant or wallet, that the network keeps pointing at the customer’s current card even after the card is reissued.
Do network tokens actually increase approval rates?
Usually yes, but modestly. Publicly quoted gains have generally been in the low single digits of percentage points, and the benefit concentrates in recurring and card on file traffic. Measure it on your own volume with a holdout rather than accepting a vendor average.
Are network tokens the same as the tokens my gateway already gives me?
No. A gateway token is a reference into your provider’s vault and is valid only with that provider. A network token is issued by the card network, carries its own expiry, and is refreshed by the issuer when the account changes.
Does Apple Pay already use network tokens?
Yes. Wallet payments have used network tokenization since launch, with a token provisioned to the device and a cryptogram generated per transaction. That volume is already tokenized, so it is not incremental when you model a card on file migration.
Do I still need an account updater service?
Often yes, at least during a transition. Token lifecycle coverage and updater coverage do not overlap perfectly, and any credential that failed to provision as a network token still depends on the updater to stay current.
Do network tokens reduce chargebacks?
Not directly. They reduce the value of stolen credential data and can help with some fraud scoring, but disputes are decided on authentication status and the evidence you present, not on the storage format of the credential.
Can I take my network tokens to a different payment provider?
Sometimes, and it depends on how the token requestor registration was structured. It is materially easier than migrating a proprietary gateway vault, but it is not automatic. Get the answer in writing before you sign.
What breaks in reporting after migration?
Most often, anything matching on the last four digits. A network token has its own last four, which differ from the card’s, so customer service tooling, receipts and finance reconciliation rules built on those digits need updating.
Is every card eligible for a network token?
No. Issuer participation varies by bank, country and card product, and some commercial and regional portfolios have thinner coverage. Expect a mixed vault and design your fallback logic accordingly.