Network Tokenization Architecture for Card Payments (2026)

A stored 16-digit Primary Account Number is a liability that decays. It leaks in breaches, it dies when a card is reissued, and it drags every system that touches it into the harshest tier of PCI DSS. Network tokenization answers all three problems at once by replacing the PAN in a merchant’s card-on-file store with a domain-restricted token minted by the card network’s Token Service Provider, then binding each authorization to a one-time cryptogram that a stolen token cannot reproduce. The token is not a random opaque string sitting in a merchant vault; it is a live credential the network keeps synchronized with the underlying account. That distinction — a network-controlled credential versus a merchant-controlled placeholder — is the entire subject of this article, and it is routinely blurred in vendor marketing.

This article is a systems and architecture analysis. It describes how these components behave and interconnect; it is not payment, security, or compliance advice, and it makes no predictions.

What this covers: the TSP, token vault, and token requestor model; provisioning, ID&V, and lifecycle; the tokenized authorization flow with a domain-controlled cryptogram; a reference architecture; how network tokens differ from PCI-vault and PSP tokens; integration paths; and the failure modes that a token is not a silver bullet for.

Context and Background

Tokenization in payments is an overloaded word covering at least three unrelated mechanisms, and conflating them produces bad architecture. The oldest form is the merchant or acquirer PCI vault token: a format-preserving surrogate value that a payment vault swaps in for a PAN so that downstream systems — order management, analytics, recurring billing — never store the real number. It lives entirely inside the merchant or processor domain, carries no cryptographic material, and means nothing to the card network. Its sole job is to shrink the cardholder-data footprint and, with it, PCI DSS scope.

Network tokenization is a different animal, standardized by EMVCo in the EMV Payment Tokenisation Specification. Here the token is issued by a Token Service Provider operated by the card network — Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES) are the canonical examples — and the relationship between the token and the PAN is managed inside a network-operated token vault. Because the network mints and controls the token, it can do things a merchant vault fundamentally cannot: attach a per-transaction cryptogram, restrict the token to specific use domains, and keep the token alive across card reissuance. The same machinery underpins Apple Pay and Google Pay device tokens; card-on-file network tokenization applies it to e-commerce credentials stored by merchants and PSPs.

The commercial pull is measurable. Visa has published VisaNet data attributing roughly a 3% authorization-rate uplift on global card-not-present traffic to network tokens, alongside a material fraud reduction (Visa Token Service). Those two numbers — more approvals, less fraud — are why network tokenization moved from a wallet curiosity to a card-on-file default. This site’s payment orchestration platform architecture guide treats the token vault as a first-class routing concern for exactly this reason. For the specification itself, EMVCo’s tokenisation framework is the primary source (EMVCo Payment Tokenisation).

The reference architecture: TSP, token vault, and token requestor

Network tokenization is a four-role system, and the roles matter more than any single box. The token requestor is the entity that asks for a token — a PSP, a merchant, or a wallet — identified by a unique Token Requestor ID (TRID) it must register for with the network. The Token Service Provider (TSP) mints tokens, performs identification and verification, and generates cryptograms. The token vault is the secured repository holding the token-to-PAN mapping. The card network routes and detokenizes traffic in the authorization path, and the issuer ultimately authorizes against the real PAN.

Under EMVCo’s model the TSP role can be assumed by different entities — card networks, issuers, or their agents — but in practice for card-on-file commerce it is the network. The vault, holding the most sensitive mapping in the system, is protected by strong physical and logical controls, and it lets tokens and PANs carry independent lifecycles: one PAN can back many tokens, and a token can survive a PAN change.

Figure 1: Reference architecture for card-on-file network tokenization. The token requestor obtains tokens from the TSP; the vault holds the token-to-PAN mapping; detokenization happens inside the network in the authorization path.

Figure 1 shows the two distinct planes that every network tokenization design must separate cleanly. The provisioning plane (merchant to PSP to TSP to vault) runs when a credential is first stored. The transaction plane (PSP to network to TSP to issuer) runs on every authorization, where the network resolves the token to a PAN via the vault and forwards the real PAN to the issuer. A frequent design error is treating these as one path; they have different latency budgets, different failure semantics, and different security boundaries.

The TRID is the unit of trust and control

Every token in the system is scoped to a TRID. The network uses the TRID to enforce which requestor may transact a given token, to apply requestor-specific domain controls, and to bill and report. Two merchants storing the same card produce two different tokens under two different TRIDs — a property Indian regulation makes explicit by requiring tokens to be unique to the combination of customer, card, token requestor, and merchant. Architecturally, the TRID is where portability is won or lost: whoever holds the TRID holds the tokens.

The vault is network-operated, not merchant-operated

The single most important structural fact is that the token-to-PAN mapping lives in a network-operated vault, not in the merchant’s database. The merchant stores only the token. Detokenization — redeeming the token for the PAN — happens inside the network during authorization, described plainly in MDES as mapping the token back to the real PAN, validating the cryptogram, and forwarding to authorization (MDES overview, Solidgate). This is why the merchant’s environment can fall out of scope for storing real PANs even while it continues to transact.

Domain restriction is what makes a token safer than a PAN

A raw PAN is a bearer credential: anyone holding it can attempt a charge anywhere. A network token is not, because the TSP applies domain restriction controls. EMVCo defines token domains as the set of transaction contexts in which a token may be used, and restriction controls can pin a token to a presentment mode (e-commerce or contactless only), to a specific merchant, or can require that a valid cryptogram accompany every authorization. A token stolen from an e-commerce card-on-file store, restricted to that domain and requiring a cryptogram the thief cannot mint, is far less useful than a stolen PAN.

What actually changes in the authorization message

It helps to be concrete about the wire-level effect, because the value of the design lives in the message format. In a non-tokenized card-on-file authorization the merchant’s stored PAN travels in the primary account number field, and anyone who can read that message reads a reusable card number. In a tokenized authorization the token occupies that field instead, and the cryptogram rides in the fields the network reserves for tokenized-transaction data alongside a token-assurance indicator. The issuer’s host may receive either the resolved PAN plus token metadata or a mapping it can resolve, depending on the network’s implementation, but the merchant-facing message never carries the real PAN. The practical consequence is that log capture, message replay, and man-in-the-middle interception all yield a token bound to a domain and a spent cryptogram rather than a live credential. This is a different security posture from encryption alone, which protects data in transit but restores a reusable PAN the moment it is decrypted at the endpoint.

Provisioning, ID&V, and the tokenized authorization flow

Provisioning is the act of creating a token and binding it to a PAN, and its trustworthiness is captured by the Token Assurance Level (TAL). TAL represents the confidence in the token-to-PAN binding, derived from the Identification and Verification (ID&V) performed at provisioning time. Weak ID&V — merely confirming the card number, expiry, and CVV are internally valid — yields a lower assurance level; stronger ID&V, such as an issuer step-up, yields a higher one. Issuers can use TAL as a signal in their authorization decision, so the quality of provisioning directly shapes downstream approval behavior.

Figure 2: Provisioning followed by a tokenized authorization. ID&V sets the assurance level at provisioning; at transaction time the TSP issues a per-transaction cryptogram that the network verifies during detokenization before the issuer authorizes on the real PAN.

Figure 2 traces both phases. During provisioning the requestor submits the PAN under its TRID, the TSP runs ID&V (often round-tripping to the issuer for confirmation), sets the assurance level, and returns the token plus the cryptographic material the requestor will need. At transaction time the requestor asks the TSP for a cryptogram — a dynamic, one-time value bound to that specific authorization — and presents the token and cryptogram to the network. The network detokenizes against the vault, verifies the cryptogram, and forwards the real PAN to the issuer. The one-time nature of the cryptogram is what defeats replay: a captured token-plus-cryptogram pair from a prior authorization cannot be reused, because MDES and VTS generate a fresh cryptogram per purchase using keys held in the TSP.

The cryptogram is the difference between a token and a placeholder

This point deserves isolation because it is the crux of the whole design. A PCI-vault token can be replayed if stolen, because it carries no per-transaction proof; it is just a substitute string. A network token authorization carries a cryptogram that binds the token to one transaction context, functioning roughly as a dynamic CVV computed under the hood. Strip the cryptogram away and a network token degrades toward the security profile of a plain vault token. Any architecture that stores network tokens but fails to request and present cryptograms is leaving most of the security value on the table.

Card-on-file versus wallet cryptograms

The same cryptogram machinery serves two contexts with different key custody. In a device wallet, keys live in the phone’s secure element and the device computes the cryptogram. In card-on-file commerce there is no consumer device in the loop, so the TSP generates the cryptogram on the requestor’s behalf when asked. The security property — a fresh value per authorization — is identical; the custody model differs, and that difference shapes how a PSP integrates. This is also why 3-D Secure authentication data feeds cleanly into the same request; see this site’s EMV 3-D Secure 2 authentication architecture for how that authentication signal is carried.

Lifecycle management: suspend, resume, and automatic credential updates

Because the token and PAN have independent lifecycles managed in the vault, the network can operate on the token without the merchant ever touching a card number. This is where network tokenization earns its keep beyond the single-transaction view.

Figure 3: Token lifecycle. A token moves from provisioning through ID&V into an active, domain-restricted state, and can be suspended and resumed, automatically updated when the underlying card is reissued, or permanently deleted — all inside the vault.

Figure 3 shows the states a token traverses. After ID&V a token becomes active and domain-restricted. It can be suspended — a temporary hold, useful when a cardholder reports suspicious activity or a merchant pauses a subscription — and later resumed to active without re-provisioning. It can be permanently deleted. And, most valuably for card-on-file, it can be automatically updated when the underlying card changes.

Automatic credential updates replace the account-updater dance

When an issuer reissues a card — expiry change, lost or stolen replacement, product upgrade — the PAN behind the token changes, but the token does not. The network updates the token-to-PAN mapping in the vault, and the merchant’s stored token keeps working; the next recurring charge authorizes against the new card without the cardholder re-entering anything. This is a structural improvement over legacy account-updater batch services, which push new PANs to merchants on a delayed schedule and require the merchant to store and rotate real card numbers. With network tokens the merchant never learns the new PAN; the update is invisible and, in effect, continuous. For subscription and card-on-file businesses this is often the single largest driver of involuntary-churn reduction, because failed renewals on stale cards simply stop happening.

Suspend and resume give issuers a scalpel instead of a hammer

Independent lifecycles also let an issuer or network act on a single token without killing the account. A token compromised at one merchant can be suspended or deleted while every other token on the same PAN, and the PAN itself, remains untouched. Contrast this with a raw-PAN breach, where the only remedy is reissuing the card and disrupting every merchant that stored it. Containment at the token level is a first-order resilience property, and it is only possible because the vault decouples the two identifiers.

The vault is now on the critical path

Decoupling has a cost worth naming: the network-operated vault sits directly in the authorization path, because detokenization must resolve the token to a PAN before the issuer can decide. A vault that is slow or unavailable does not merely delay a lifecycle update — it can stall live authorizations. Networks therefore run vaults as high-availability, geographically redundant systems, and a merchant or PSP consuming tokenization inherits a dependency on that availability. The architectural implication is that a tokenized stack does not remove infrastructure risk, it relocates it: the merchant sheds the burden of storing PANs and takes on a hard runtime dependency on the TSP’s detokenization service. Designs that treat the token vault as a background convenience rather than a transaction-critical dependency misjudge where their availability budget is actually spent.

Network tokens vs PCI-vault tokens vs PSP tokens

The three token types are not competitors so much as different layers, but architects must choose deliberately because they carry very different guarantees. The decision matrix below is the fastest way to see the axes that matter. The network tokenization vs PCI vault distinction — the phrase teams reach for most — reduces to two questions: who issues the token, and does an authorization carry a cryptogram.

Dimension	Network token	PCI-vault token	PSP token
Who issues	Card network TSP (VTS, MDES)	Merchant or acquirer vault	Payment service provider
Domain	Network / cross-acquirer	Merchant domain only	PSP domain only
Per-transaction cryptogram	Yes, one-time	No	No
Replaces PAN in auth message	Yes, detokenized by network	No, PAN restored before auth	No, PAN restored by PSP
PCI DSS scope effect	Removes stored PANs from scope	Removes stored PANs from scope	Removes stored PANs from scope
Automatic credential updates	Yes, via vault on reissue	No	Only if PSP layers network tokens underneath
Auth-rate lift	Yes, network-reported uplift	No inherent lift	Only via underlying network tokens
Portability across providers	Tied to the TRID holder	Portable if you control the vault	Low, locked to the PSP
Primary purpose	Security, resilience, approvals	Scope and footprint reduction	Convenience and PSP lock-in

Two rows deserve emphasis. First, all three reduce PCI scope by keeping raw PANs out of the merchant’s stored data — scope reduction is not unique to network tokens, a point vendors selling vaults are correct about. What network tokens add on top is the cryptogram, the auth-rate lift, and the automatic updates, none of which a plain vault or PSP token delivers on its own. Second, a PSP token is frequently a network token in disguise: a good PSP provisions network tokens under its own TRID and hands the merchant a PSP-branded reference. That is convenient and fast, but it means the tokens live under the PSP’s TRID — the portability row is where that decision comes home to roost. Juspay’s teardown of the two models is a useful practitioner reference on exactly this trade-off (Juspay, network vs PCI tokenization).

PCI scope is necessary but not sufficient

It is worth being precise about what tokenization does and does not do for compliance. Removing stored PANs can move a merchant from the heavyweight SAQ-D self-assessment toward the far lighter SAQ-A, because systems that neither store, process, nor transmit cardholder data fall out of scope (Cybersource on PCI scope reduction). But any path where a raw PAN transits the merchant’s systems — even briefly, even only at capture — keeps that capture path in scope. Tokenization narrows scope; it does not by itself eliminate it, and the capture surface is where the residual obligation concentrates.

Integration paths: via PSP versus direct to the TSP

There are two ways to consume network tokenization, and the choice is strategic rather than merely technical.

Figure 4: Integration paths. The PSP-managed path is fast to ship but binds tokens to the PSP’s TRID; the direct-TSP path owns the TRID for portability at the cost of running cryptogram and vault operations, and both routes shape least-cost routing options.

Figure 4 lays out the fork. The PSP-managed path is the common on-ramp: the PSP holds the TRID, provisions and manages tokens, generates cryptograms, and exposes a simple API. It is fast to integrate and offloads the cryptogram and lifecycle operations entirely. Its cost is that the tokens are bound to that PSP’s TRID, so leaving the PSP means re-tokenizing the entire card-on-file base — a migration that ranges from painful to impractical at scale.

The direct-TSP path — the merchant or platform registers its own TRID with the networks and integrates directly with VTS and MDES — inverts the trade. It is a heavier build: you own cryptogram management, vault interactions, lifecycle webhooks, and the operational burden of running against multiple networks. In return the tokens are yours, portable across any acquirer or PSP you route through, which is precisely what makes multi-acquirer and least-cost routing feasible.

Routing is where the TRID decision compounds

Least-cost and dual routing depend on being able to send the same stored credential through more than one acquirer or network path. If your tokens are bound to a single PSP’s TRID, your routing freedom is bounded by that PSP. This is the connective tissue between tokenization and switching: the card authorization switch and issuer processing architecture can only route what the token layer lets it route. Teams that adopt PSP-managed tokens for speed and later discover their routing options are frozen are living out the most common regret in this space.

Trade-offs, gotchas, and what goes wrong

Network tokenization is genuinely strong architecture, and it is not a silver bullet. The honest limits matter as much as the benefits.

Domain restriction cuts both ways. The same controls that make a stolen token less useful can break legitimate flows if provisioned too narrowly. A token restricted to e-commerce presentment will fail if a later flow needs a different mode; a token pinned to one merchant identifier breaks if the merchant’s acquiring setup changes. Domain controls are a security asset and an operational footgun, and they must be provisioned against the full set of flows the credential will actually serve.

Cross-PSP portability is a design-time decision, not a runtime one. Once tokens are minted under a PSP’s TRID, they cannot be lifted out and used elsewhere; you re-provision. Choosing the PSP-managed path is choosing a portability ceiling, and the time to weigh it is before the first token is minted, not during a later migration crisis.

Cryptogram management is a real operational surface. Cryptograms are one-time and time-sensitive. Requesting them, presenting them in the correct authorization fields, handling expiry and regeneration, and reconciling failures add moving parts. An integration that stores tokens but mishandles cryptograms can see declines that are hard to diagnose because the token itself looks valid.

Dual-routing and least-cost routing get more complex, not less. A stored credential that must traverse multiple networks or acquirers needs token coverage on each path. Where a token is bound to one TRID or one network relationship, the routing engine’s freedom shrinks. Tokenization and routing must be designed together, or the routing layer inherits constraints it cannot see.

It is not a fix for card-not-present fraud on its own. A token plus cryptogram defeats replay of stolen credentials, and it reduces the value of a breached vault. It does not authenticate the shopper. Account-takeover, phished-through legitimate provisioning, and friendly fraud all survive tokenization untouched. The cardholder-authentication job belongs to 3-D Secure and risk engines; the token secures the credential, not the person. Reconciling tokenized flows end to end also introduces its own matching work, which the reconciliation engine architecture for payments has to account for when tokens, PANs, and cryptograms all appear across the settlement records.

Mapping drift and stale bindings. Because the vault owns the token-to-PAN mapping, any lag or error in propagating an update — a reissue not yet reflected, a suspend not yet honored — surfaces as an authorization anomaly the merchant cannot directly inspect, since the merchant never sees the PAN. Observability of token state depends on the lifecycle webhooks the TSP or PSP exposes, and those must be wired and monitored.

Practical recommendations

Treat network tokenization as an architectural decision about who owns the credential, not as a checkbox feature. The most consequential choice is the TRID: whoever holds it holds the tokens and, with them, your portability and routing latitude. Decide that deliberately, with a full view of the multi-acquirer future you may want, before minting the first token.

Design the provisioning and transaction planes as separate paths with separate failure handling, because they have different latency and security profiles. Wire lifecycle webhooks — suspend, resume, delete, update — from day one; the resilience and involuntary-churn benefits depend entirely on acting on those events. Provision domain restrictions against the real set of flows a credential serves, not the narrowest one, to avoid self-inflicted declines. And never store network tokens without the cryptogram discipline to go with them, because a cryptogram-less network token is little more than an expensive vault token.

A short readiness checklist:

• Confirm who holds the TRID and what portability that implies before minting tokens.
• Separate provisioning-plane and transaction-plane paths, with distinct retry and failure logic.
• Subscribe to and act on lifecycle events: suspend, resume, delete, automatic update.
• Request and correctly present per-transaction cryptograms on every authorization.
• Provision domain restrictions to match all legitimate presentment modes, not just one.
• Keep the credential-capture surface tightly scoped, since it carries the residual PCI obligation.
• Verify token-state observability through TSP or PSP webhooks, not by inspecting PANs you no longer hold.

Frequently Asked Questions

What is the difference between a network token and a PCI-vault token?

A network token is issued by a card network’s Token Service Provider, carries a per-transaction one-time cryptogram, and is kept synchronized with the underlying card through the network-operated vault. A PCI-vault token is a format-preserving surrogate created inside a merchant or acquirer vault; it carries no cryptogram and means nothing to the network. Both reduce PCI scope by keeping raw PANs out of stored data, but only the network token adds replay resistance, automatic credential updates, and the network-reported authorization-rate lift.

Does network tokenization eliminate PCI DSS obligations?

No. It narrows scope substantially — removing stored PANs can move a merchant from SAQ-D toward SAQ-A because out-of-scope systems neither store, process, nor transmit cardholder data. But any path where a raw PAN transits the environment, especially the credential-capture surface, stays in scope. Tokenization reduces the cardholder-data footprint; it does not by itself make a merchant PCI-exempt, and the capture path remains the residual obligation.

How does a token keep working after a card is reissued?

The token and PAN have independent lifecycles inside the vault. When an issuer reissues a card, the network updates the token-to-PAN mapping while the token the merchant stored stays unchanged. The next authorization resolves the same token to the new PAN, so recurring charges continue without the cardholder re-entering details. The merchant never sees the new PAN, which is why this is structurally cleaner than legacy account-updater batch files.

What is the cryptogram and why does it matter?

The cryptogram is a dynamic, one-time value bound to a single authorization, generated using keys held by the Token Service Provider (or a device secure element in wallet flows). It functions like a dynamic CVV and defeats replay: a captured token-plus-cryptogram pair cannot be reused because the next authorization needs a fresh cryptogram. Without it, a network token degrades toward the security profile of a plain vault token, which is why cryptogram handling is not optional.

Should I integrate network tokens through my PSP or directly with the TSP?

It depends on the priority. The PSP-managed path is fast and offloads cryptogram and lifecycle work, but binds tokens to the PSP’s Token Requestor ID, capping portability and routing freedom. The direct-TSP path means registering your own TRID and running cryptogram, vault, and lifecycle operations yourself, but the tokens are portable across acquirers and PSPs, which is what makes least-cost and dual routing viable. This is a strategic trade between speed and control, decided before the first token is minted.

Does network tokenization stop card-not-present fraud?

Not on its own. It defeats replay of stolen credentials and reduces the value of a breached vault, but it does not authenticate the shopper. Account-takeover, fraud committed through legitimately provisioned tokens, and friendly fraud all survive tokenization. Cardholder authentication is the job of 3-D Secure and risk engines; the token secures the credential, not the person behind it. Network tokenization and authentication are complementary layers, not substitutes.

Further Reading

• Payment orchestration platform architecture — where the token vault sits as a routing concern in a multi-PSP stack.
• Card authorization switch and issuer processing architecture — how detokenized traffic reaches the issuer and how routing depends on the token layer.
• EMV 3-D Secure 2 authentication architecture — the cardholder-authentication layer that complements tokenization.
• Reconciliation engine architecture for payments — reconciling tokens, PANs, and cryptograms across settlement records.
• External: EMVCo Payment Tokenisation — the primary specification and technical framework.
• External: Visa Token Service — the canonical TSP implementation and published authorization-lift data.

By Riju — about