Everything you need to know about network tokens

Network tokens have been around for a while. Early adoption was closely tied to digital wallets, but they’re being used more broadly these days. If you're evaluating network tokens for the first time, or looking to improve how you use them today, this post is for you. We’ll cover what network tokens are, why businesses use them, and what to think about when building a strategy around them.

What network tokens are

In the world of payments, network tokens might have one of the more intuitive names. They’re quite literally tokens that card networks (Visa, Mastercard, etc.) create. They’re unique IDs that tie back to specific cards. They look and act a lot like primary account numbers (PANs, or raw PANs), but are safer to store and are out of scope for PCI DSS. You can use them to charge the underlying card, but they have many other benefits. If you’re familiar with how tokenization works with PSPs or payment orchestrators, you’re probably wondering why we have a different way to tokenize cards.

The short version is that when Apple built Apple Pay, they didn’t want raw PANs to be involved (for various reasons). Apple approached some of the card networks when they started building Apple Pay, and it turned out some of the card networks were already looking into replacing raw card numbers with digital tokens. Banks would eventually get involved too, and out of this multiparty collaboration came network tokens, and an official EMVCo standard for payment tokenization. Although the initial push for the solution was partially driven by Apple Pay, the implementation supports other wallets (Google Pay, etc.).

How network tokens work

To understand how network tokens work, there are a couple of parties to cover, and a few steps to walk through. We’ll provide a quick reference later, so don’t feel like you need to remember the acronyms.

Creating a network token

Token Service Providers (TSPs) are responsible for creating (provisioning) and managing network tokens. Card networks all have their own systems for doing this. The names vary but their purpose is the same. They verify cardholders, issue tokens, enforce domain restrictions at authorization time, and push lifecycle updates when the underlying card changes.

Provisioning starts with the real card number, called the Funding PAN (FPAN). The Token Requestor (usually a merchant, PSP, etc.) sends the FPAN to a TSP, which checks with the issuing bank and, if approved, generates a network token in its place. That network token (could be an MPAN or a DPAN depending on the request) is what gets returned to the requestor and stored for later use.

Using a network token in a transaction

How a token gets used depends on who's initiating the charge. A customer-initiated transaction (CIT) is when the cardholder is actively completing a purchase. In addition to the network token, CITs include a one-time-use cryptogram generated by the TSP. The cryptogram kind of takes the place of a traditional CVC. It helps validate the transaction, and it ensures the network token is active and being used for the type of transaction it was meant for.

Merchant-initiated transactions (MITs) work a little differently. If you use a subscription as an example, the process looks like this:

1. The first transaction to set up the subscription is actually a CIT.

2. Out of that CIT comes a unique ID for that authorization. The card networks have different names for this ID, but they serve the same purpose. Visa calls it a Transaction Identifier, and Mastercard calls it a Transaction Lifecycle ID (formerly a Trace ID).

3. Every MIT after the initial CIT refers back to that unique ID and the original authorization. This is what enables recurring charges.

This means that MITs don’t have cryptograms. The initial CIT should, but subsequent MITs use the network token and just refer back to the original authorization.

Network token quick reference

How network tokens differ from traditional tokenization

Traditional card tokenization (offered by PSPs, orchestrators, vault providers, etc.) replaces card numbers with tokens. These tokens can only be used within the provider’s environment. When you want to charge a customer, you send a request to the provider with information about the charge (amount, etc.), and you include the token. To complete the charge, the provider reverses the token into the raw PAN and uses that with downstream partners to process the transaction.

Network tokens work a little differently because the card networks create and manage the token. This has a few consequences. Network tokens carry constraints called Token Domain Restriction Controls. These are set when the token is created, and they scope the token to a specific transaction type, merchant, or wallet. They might also require a cryptogram for authorization.

Because networks control the tokens, they can update them automatically as the underlying card changes. This can be a big benefit for merchants and customers because they don’t have to update card details manually if the card is reissued because it was expired, lost, or stolen.

The gotcha here is that even though network tokens are managed by the card networks, you can still experience the same kind of lock-in with PSPs that you do for traditional tokenization. Basically, providers integrate with card networks directly in order to offer network token APIs to their users. This often ends up tying the network token to that provider, which means you can’t use the network token with any other PSP, orchestrator, etc. The determining factor for this is who owns the Token Requestor ID (TRID).

TRID ownership

TRIDs are issued by the card network to whoever requests tokens on behalf of cardholders. That could be a PSP, a standalone provider, or a merchant going direct to the networks. The party that holds the TRID is the only one that can request the cryptogram for CITs, and they’re the only one that receives lifecycle updates (expiry changes, reissues, suspensions) from the networks. That’s really what “owning” a token means in practice, and it's why a token requested under a PSP's TRID stays functionally tied to that PSP, even though the token itself is issued by the network.

TRIDs are often assumed to be merchant-specific, but they aren’t the same thing as a Merchant ID (MID), and the two aren't linked by default. Most issuers don't compare TRIDs against MIDs during authorization, and many PSPs and payment facilitators use a single umbrella TRID across many merchants. This matters for platforms that need to segment tokens across sub-merchants or brands. Mastercard's On-Behalf-Of Token Requestor (OBOTR) model exists specifically to support these more flexible multi-merchant setups.

CITs and EMV liability shift

Every CIT that uses a network token has an ECI (Electronic Commerce Indicator) in addition to the cryptogram. The ECI value tells the acquirer how (or if) the transaction was authenticated. That value determines whether the transaction qualifies for something called EMV (Europay, Mastercard, and Visa) liability shift. This is very similar to the liability shift you get with a successful 3DS authentication. It moves liability for fraud-related chargebacks from the merchant to the issuer. Eligibility isn't universal though. It depends on the card network and their own rules around region, merchant category code, etc.

Network token lifecycle management

After a network token is provisioned, the TSP keeps it current for as long as it's in use. Issuers push lifecycle changes to the TSP whenever something happens on the underlying account, and merchants or PSPs can subscribe to webhooks to receive those updates in near-real-time rather than having to poll or request them on a schedule.

There are two kinds of updates to be aware of. The first covers the token's own status: whether it's active, temporarily suspended (maybe because of suspected fraud), or permanently deleted because the account was closed. The second covers metadata tied to the underlying card, most commonly a new expiration date or a new card number after a reissue. Either way, the token requestor finds out automatically, rather than discovering it the hard way when a transaction declines.

Where network tokens sit relative to PCI DSS

Network tokens aren't considered cardholder data under PCI DSS. This is one of their more meaningful advantages. However, to provision a network token, you still need the original PAN. In practice, that means you're relying on a PSP to provision tokens on your behalf, or using a Token Requestor that offers PCI-reducing card collection iframes. Otherwise, you end up in PCI scope anyway despite adopting network tokens.

If you use Evervault, you can optionally encrypt the network tokens that you store. It’s not a requirement for PCI DSS though, it’s just another way to further limit exposure.

Where network tokens sit relative to 3D Secure

Network tokens aren't a replacement for 3D Secure, and adopting them doesn't satisfy Strong Customer Authentication (SCA) requirements in the EU, or eliminate the need to use 3D Secure to block fraudulent chargebacks. What they do is reduce fraud exposure, since a stolen network token can't be typed into a normal checkout form the way a stolen PAN can.

Structurally, authentication doesn't change. A network token gets passed to the 3DS Server in place of the raw PAN, and the rest of the flow, including liability shift, works the same way. For MITs specifically, this can also mean reusing an authentication result from an earlier cardholder-present transaction, rather than running a fresh challenge for every charge. Issuers might still require re-authentication at some point, but network tokens reduce the frequency.

Why businesses use network tokens

Issues with card-not-present payments break down in a few consistent ways, and network tokens address many of them.

• Soft declines: an issuer rejects a legitimate transaction (common codes include 05, Do Not Honor, and 59, Suspected Fraud) because its risk systems are uncertain, not because anything is actually wrong with the card.

• Hard declines: the underlying card is genuinely no longer valid (expired, reissued, lost, or stolen). These are costly for recurring billing, where they drive involuntary churn, and most customers won't proactively update a stored card unless forced or reminded to do it.

• Fraud: stolen PANs from data breaches get reused across merchants or against stored cards-on-file.

How network tokens help

Network tokens address these through three mechanisms: fresher credentials, better issuer trust, and more transaction context. Because card networks update tokens automatically, hard declines from expired or reissued cards mostly disappear without merchant or customer action. MPANs specifically are also more durable in situations where customers get new devices or have multiple devices.

For example, if a subscription is paid for through Apple Pay on an iPhone, and the customer gets a new device (and wipes the previous phone before getting rid of it), future payments for that subscription can silently fail. MPANs avoid this problem because they’re tied to the merchant and not the device, which also means the same token can work in parallel across a customer’s iPhone, iPad, etc.

On the trust side, every use of a token effectively gives the issuer a second opportunity to evaluate the transaction, once at provisioning and again at each authorization. Merchant and domain binding, plus cryptograms, also give issuers more signal than a standard PAN carries on its own. That combination converts some soft declines into approvals. For example, cryptograms and merchant binding can reduce issuer suspicion behind a Do Not Honor (05) decline, and the same signals help lower false fraud flags behind Suspected Fraud codes (59, 62).

On fraud specifically, because tokens are merchant- and domain-bound, a token stolen from one merchant can't be used at another, and the network can block it without affecting a customer's tokens elsewhere. Cryptograms are also single-use, which limits replay and credential-stuffing attacks. None of this eliminates fraud entirely, but it narrows exposure to a single merchant rather than the underlying card number. And if the card number is compromised and shut down because of fraud, it can’t be used with you even if the fraud was originally flagged by a transaction with a different merchant.

Card networks are actively pushing adoption

Network tokens are becoming less optional, regardless of their benefits. Mastercard is targeting 100% ecommerce tokenization in Europe by 2030. As of mid-2026, three in five of its European ecommerce transactions are already tokenized. Visa hasn't set a public deadline the same way, but it's headed in the same direction. As of early 2026, more than 50% of its transactions are tokenized, and the network is actively pushing to close the remaining gap, particularly around guest checkout and stored cards on file.

Both Visa and Mastercard also offer reduced interchange fees for transactions that use network tokens. Their programs work a little differently, but the reduced fees can have a meaningful impact depending on your business (industry, transaction volume, where you operate, whether you have local acquiring, etc.).

Network token strategy considerations

Businesses end up using network tokens for different reasons. Usually it’s a combination of the things we covered previously, but how you implement them impacts how valuable they end up being to your business.

High value use cases

Network tokens deliver the most value for card-on-file scenarios (subscriptions, stored cards, and other deferred payment). These use cases are where lifecycle management and repeat-use build trust signals over time. Single transactions and guest checkout use cases might see a small lift in performance and a reduction in interchange fees, but they aren’t as common a reason to use network tokens. There’s less long term benefit like there is with subscriptions or repeat purchases with a card-on-file, but acceptance rates can sometimes get a boost on higher risk transactions because issuers have more data and can see them as lower-risk.

PAN fallback

Even with high issuer support, it’s common for businesses to retain access to the underlying PAN so they can retry transactions if a token is unavailable or invalid. Evervault provides an encryption solution for this, but you can retain access through your PSP, orchestrator, etc. as well.

Depending on your strategy and infrastructure, you might want to run a Card Account Updater service to keep stored credentials fresh. It can be more expensive per update than network token lifecycle services, but you can reduce costs if you can limit requests to cards you're actually about to charge through Real-time Account Updater, rather than running full batches.

Routing and retry logic

Issuers use their own risk-based decisioning for tokenization requests, and even a fully operational issuer can decline a request due to internal fraud rules. First-attempt success rates are generally high, but you should still plan for retries, since some tokenization requests only succeed after multiple attempts over time.

Initial payment flow and tokenization timing

Depending on your payment stack, you might choose to process initial payments using the PAN, and then create a network token for it later. For example, let’s say you run a subscription service. When a new customer signs up, you collect payment information and charge the customer using the PAN. After that, you create a network token and use that to charge the customer every time their subscription is up for renewal. This can reduce the number of network calls you have to make during the initial checkout, reducing checkout latency while still benefiting from network tokens for subsequent charges.

How you do this will depend a lot on how your payment stack is set up. With Evervault, you’d encrypt card credentials, then create the network token whenever you wanted. If you use a PSP or similar provider, you’ll have to see if they support this kind of flow.

Sub-merchant segmentation for platforms

If you're a platform issuing tokens on behalf of multiple sub-merchants or brands, you'll need multiple TRIDs, one per merchant or business unit depending on how you want ownership and reporting structured. This is manageable at small scale, but most providers still handle it as a manual, per-customer onboarding process (form submissions and network approvals), which becomes a bottleneck if you're trying to onboard sub-merchants at volume.

Network token solutions and their implications

There are a few categories of solutions to choose from. Portability and who owns the TRID are probably the biggest factors in making a decision.

Payment service providers

Many PSPs offer network tokens as a built-in feature, and it's one of the faster ways to get started. There’s no separate vendor relationship, and the PSP typically handles the token-vs-PAN decision automatically. The tradeoff is that the PSP owns the TRID, and that shows up in a few ways:

• You can’t transfer network tokens to a different PSP. You can potentially migrate the raw PANs or recollect card details, but both options cause a lot of friction and require you to create new network tokens.

• You might have limited or no visibility into whether a given transaction used a token or fell back to a PAN.

• You might have little to no performance data to measure ROI or to debug failures.

• You potentially pay to tokenize the same card multiple times if you run multiple PSPs.

Standalone providers

A standalone provider lets you own the TRID yourself, independent of any PSP (this is what Evervault enables you to do). Owning it yourself gets you:

• Token portability across PSPs and acquirers.

• Routing control over where each transaction goes.

• Full visibility into whether a token was used, and why it failed if it wasn't.

• Centralized, cheaper tokenization instead of duplicating it per PSP.

The cost is integration effort, since you're adding a vendor relationship rather than flipping on a feature your PSP already has. Providers also differ in how they handle onboarding at scale. Most standalone token platforms provision one TRID per customer through a manual process, which becomes an operational bottleneck for a platform trying to onboard many sub-merchants. Some standalone providers, including Evervault, offer API-based provisioning that lets a platform programmatically create and manage a TRID per merchant or sub-merchant.

Building in-house

Several of the major card networks offer direct integrations. Building in-house gets you the same TRID ownership as a standalone provider, and might be the lowest cost option if you operate at scale. But the networks only onboard extremely large merchants directly, typically requiring hundreds of millions of transactions a year. Smaller and mid-sized merchants get pushed toward bundled gateway offerings instead. If you did integrate directly, you're taking on the full compliance and maintenance burden, and the PCI scope for touching raw PANs. You’d also need to support lifecycle events and scheme updates going forward. For nearly everyone, integrating directly isn't worth the overhead.

Wrapping up

For a while, network tokens have been moving from a nice-to-have to something closer to the default way card credentials work online. Pressure to use them is coming from multiple directions: better acceptance rates and fraud outcomes for merchants, and active fee and mandate pressure from the card networks. For many businesses, this means the decision to use network tokens is already made, and they’re primarily just figuring out how to implement them.

Evervault's Network Tokens product is a standalone, PSP-independent solution. Tokens are portable across any PSP that supports them, and you can automate merchant onboarding with our API. If you’re looking at implementing network tokens for the first time, or want to improve your current setup, reach out to us.