Series: Own Your Tokens — Part 2 of 3

"We provide Network Tokens."

That sentence appears in almost every PSP and gateway pitch deck in the market. It is, in many cases, technically accurate. And it is almost always incomplete in ways that matter strategically.

This article covers the three token types that operate at or near network level — Scheme Tokens, Network Tokens, and Gateway Tokens — and the structural distinction between them that determines whether your tokenization strategy gives you independence or quietly deepens your dependence.

Scheme Tokens: Network-Level Tokenization

The card networks have built their own tokenization infrastructure. Most merchants interact with it without fully understanding what it is or what it does.

Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) are the two primary implementations of the EMVCo tokenization standard at scheme level. The tokens they produce — Scheme Tokens — replace the PAN at network level, not at PSP or gateway level. That distinction is foundational.

What makes Scheme Tokens structurally different

A Scheme Token is bound to the network, not to any downstream provider. A token issued through Visa Token Service is valid across any Visa-accepting acquirer. It is not tied to the PSP that requested it. It does not expire when you change providers. It is portable across the acquiring relationship — which is a fundamentally different portability profile than anything issued within a single gateway's token domain.

Scheme Tokens were designed for two primary use cases, and they perform well at both.

Recurring and card-on-file transactions. Stored credentials backed by Scheme Tokens are treated differently by issuers than raw PAN-based stored credentials. They carry higher inherent trust — the issuer knows the token was properly registered through the network's tokenization infrastructure — and this translates directly into measurably higher authorization rates for recurring and subscription flows.

Automatic lifecycle management. When a cardholder receives a new card — due to expiry, loss, or fraud replacement — the network can update the token mapping directly, without any action required from the merchant or the customer. The token remains valid. The next recurring charge succeeds. There is no decline, no failed dunning notification, no involuntary churn event. This alone makes Scheme Tokens materially valuable for subscription businesses at scale.

The access model and why it matters

Here is where the architecture gets complicated.

You cannot request Scheme Tokens directly. Access requires a Token Requestor — an entity registered with the network that has a formal Token Requestor ID and the technical capability to request, manage, and maintain tokens on behalf of merchants.

Token Requestors include:

• PSPs and payment gateways

• Independent tokenization infrastructure providers

• In rare cases, large merchants with direct network relationships

Who your Token Requestor is — and critically, whose Token Requestor ID your tokens are registered under — determines whether those tokens belong to you or to your provider.

Network Tokens: The Gold Standard With a Structural Catch

Network Tokens are Scheme Tokens accessed through a Token Requestor and used in the transaction flow. They represent the highest-quality token type available to merchants today, and the authorization rate evidence supports that claim.

Published network data consistently shows Network Token-backed transactions authorizing at 1-3 percentage points above equivalent PAN-based transactions. At meaningful transaction volumes, that gap is significant revenue — not a rounding error.

Beyond raw auth rate, Network Tokens carry cryptographic binding: each transaction uses a unique cryptogram generated for that specific transaction event. Issuers treat this as a stronger signal than a static stored PAN, which contributes to the authorization rate differential.

Network Token lifecycle management — the automatic re-linking of tokens to new card accounts — works without polling, without Automatic Account Updater enrollment, and without merchant intervention. The network handles it at the token layer.

All of this is real. The business case for Network Tokens is legitimate.

The Token Requestor ID problem

Here is what the pitch deck doesn't explain.

When a PSP or gateway requests a Network Token on your behalf, they use their own Token Requestor ID — the credential registered with Visa or Mastercard that authorizes token requests. That Token Requestor ID is theirs, not yours.

The consequences of this are structural:

The token is bound to the Token Requestor, not the merchant. The Network Token is technically genuine — it was issued by the network, it carries all the auth rate benefits, the lifecycle management works. But it is registered under the provider's identifier. The merchant never directly holds the network-level credential.

Portability is zero. If you switch PSPs, you cannot take those tokens. They cannot be migrated to a new Token Requestor without the network re-issuing new tokens against the same underlying PANs — which requires either PAN access (which you may not have) or customer re-enrollment (which you want to avoid). Either way, you lose your stored credentials.

Exit cost is structurally embedded. This is not a contractual lock-in that lawyers can negotiate away. It is an architectural lock-in built into how the tokens are registered. Every Network Token issued under a provider's Token Requestor ID is a unit of switching cost that compounds with every new stored credential.

The question that cuts through the pitch

When evaluating any provider that claims to offer Network Tokens, one question resolves the ambiguity:

Under whose Token Requestor ID are our Network Tokens registered — yours or ours?

If the answer is the provider's Token Requestor ID, you are receiving genuine Network Tokens with genuine performance benefits — but you do not own them. You are licensing access to them through that provider relationship.

If the answer is your own Token Requestor ID — or a setup where an independent provider registers tokens under a merchant-controlled identity — the tokens are portable and the architecture is genuinely merchant-sovereign.

The answer to this question is the most important piece of information in any tokenization vendor evaluation.

Gateway Tokens: Where the Confusion Happens

Gateway Tokens are proprietary surrogate values issued by a payment gateway or PSP within their own infrastructure. They replace the PAN within that provider's system. They are valid only within that system. They do not travel.

Gateway Tokens serve a legitimate purpose: they reduce PCI scope for the merchant within a given provider relationship, they work consistently within that ecosystem, and they require no additional network registration. For merchants with a single PSP and no plans to change, they function adequately.

The problem is not that Gateway Tokens exist. The problem is what happens when they are presented — or misrepresented — as Network Tokens.

The wrapping pattern

Some providers issue genuine Network Tokens through their Token Requestor ID and then wrap those tokens inside their own gateway token layer before surfacing them to the merchant. The merchant-facing reference is a gateway token. The underlying asset is a Network Token — registered under the provider's Token Requestor ID.

From the merchant's perspective, this looks like Network Token access. The auth rate benefits may be real, because the underlying transaction uses the Network Token. But the merchant never directly holds the network-level credential. The portability is gateway-token portability: zero.

This pattern is not universally disclosed. It is detectable through direct questioning, but requires the merchant to know which questions to ask.

Identifying the difference

Three questions that reliably distinguish genuine merchant-sovereign Network Token access from gateway-wrapped Network Token access:

Are our tokens registered under our Token Requestor ID at Visa and Mastercard — or under yours?

Can we port our stored token inventory to a different acquirer or PSP without re-enrolling customers?

If we terminate this contract, what is the migration path for our stored credentials?

Evasive or incomplete answers to these questions are themselves informative. Providers with genuinely portable, merchant-sovereign token infrastructure answer them directly.

The Structural Logic

It's worth being precise about why this situation exists, rather than attributing it to bad actors.

Gateways and PSPs have rational economic incentives to hold token custody. Stored credentials are a switching cost, and switching costs are a retention mechanism. Building infrastructure that locks in customer data is a coherent business strategy.

Merchants have equally rational incentives to own their stored credentials. Portability enables negotiating leverage, multi-acquirer routing, authorization rate optimization through provider competition, and resilience against any single provider's failures or pricing changes.

These incentives are structurally opposed. The gap between them is measured in switching costs — which are denominated in stored credentials, and therefore in Network Tokens registered under provider-owned Token Requestor IDs.

Understanding this dynamic doesn't change the market. But it changes how you read a vendor pitch, how you structure an RFP, and what you negotiate into a contract before you sign.

What Comes Next

The final article in this series covers the remaining token types — Device Tokens from mobile wallet flows, Merchant Tokens as the merchant-sovereign layer that makes everything else composable, and Token Lifecycle Management as the operational discipline that determines whether your tokenization investment actually performs over time.

It closes with a five-point audit framework for assessing any existing payment stack against the sovereignty criteria this series has established.

Own Your Tokens is a Hellgate® editorial series on payment tokenization, credential sovereignty, and the architectural decisions that determine who controls your payment stack.

Book a demo at hellgate.io/demo — or read the technical documentation at developer.hellgate.io.