Network tokens vs. gateway vs. vault tokens: Which lifts approval rates?

A merchant working with several payment providers will usually hold more than one token for the same card at the same time. This makes determining what role each token type should play within the payment setup, an important question.

This is particularly useful for enterprise merchants, where credentials are often stored across multiple providers. Network, gateway, and vault tokens differ in who controls the mapping back to the card number. They also differ in where the credential can be used, and how it stays relevant when a card is reissued.

Those differences also determine when one token may perform better than another. This guide compares all 3 directly: who issues each token, where it works, and the specific conditions in which a network token can improve authorization rates, rather than assuming that improvement happens automatically.

What are network, gateway, and vault tokens?

Network, gateway, and vault tokens differ by who issues the credential and controls the mapping back to the Primary Account Number (PAN):

• Network token: Issued by the card network (Visa, Mastercard). It replaces the PAN with an alternative value, and the mapping stays with the network itself.
• Gateway token: Issued by an individual payment provider. It's a private reference back to the PAN that only that provider can resolve.
• Vault token: Issued by an independent vault operator. The mapping sits outside any single payment provider.

These token types aren't mutually exclusive. A merchant may hold network, vault, and gateway tokens for the same underlying payment instrument, with each serving a different role in the payment stack.

Payrails, the financial operating system merchants use to store and route payment credentials across providers, treats that credential as a vault token because the mapping sits outside any single payment provider, allowing it to be used across payment providers.

Do merchants have to choose one token type?

Merchants can use multiple token types for the same payment instrument, with each serving a different role. A vault token is stored by default, a PSP token is added when a payment request routes through a configured provider, and a network token is added when network tokenization is configured for that instrument.

That means a single payment instrument can hold multiple tokens without one replacing another. The vault token provides the underlying reference, while PSP and network tokens layer on top as the merchant's payment setup requires.

The reason for that layering becomes clearer when you look at what each token does. The vault token handles storage, keeping the card data itself in one independent place. The network token handles lifecycle updates, so a reissued card doesn't break every stored reference to it. And the PSP token handles the provider payload, giving whichever processor receives the transaction the specific credential format it expects.

So rather than asking "which token wins?". The more useful question is "which tokens does this payment instrument actually need?" Once each token is understood as serving a different part of the payment lifecycle, it becomes much easier to see how they work together.

When do network tokens lift authorization rates?

Authorization rates improve when the issuer recognizes the token and its accompanying data. That depends on eligibility and the specific transaction type, not simply on whether tokenization is being used.

That's an important distinction. Approval gains depend on issuer recognition, while tokenization itself has no effect on funds availability or fraud-based declines. A network token can't rescue a transaction that would have failed for an unrelated reason.

Where the data does exist, the impact is meaningful: Visa reports a 4.6 percent lift in authorization rates globally for tokenized card-not-present transactions, although that figure needs some context. It covers merchants processing more than 1,000 token transactions per month in each country, and Visa notes that individual results can vary considerably outside that baseline. With Payrails, tokenization becomes part of the wider payment optimization picture, ensuring the right token is used within the right payment flow.

Network tokens are one lever in a broader optimization strategy, not a standalone fix. They sit alongside the other 4 payment optimization levers that collectively shape authorization performance, rather than acting as a single switch that improves everything on its own.

Which type of payment token should you use?

If you're handling recurring billing that needs to survive a card being reissued, a network token is usually the better fit. Because it's issued through the card network and can be automatically updated when the underlying card changes, it prevents avoidable declines without asking the customer to enter new details.

If you want the freedom to switch PSPs without asking customers to re-enter their card details, a vault token is more useful. The payment credentials remain securely stored in a vault while the token gives your payment infrastructure a consistent reference to them, reducing your dependence on any one PSP.

And if you have a single, stable integration with one processor, a gateway token may be perfectly sufficient. It replaces the card details within that provider's environment, keeping sensitive data out of your systems without adding portability you don't currently need.

How do network tokens differ from gateway tokens?

Gateway tokens tend to tie you more closely to a particular provider. Network and vault tokens, by contrast, can support a payment setup designed to remain resilient as cards, PSPs, and routing strategies change.

A network token is issued by the card network and can be used across its token domain, while a gateway token can only be resolved by the provider that issued it. That's the core difference, and 2 practical distinctions follow from it.

The first is control: who owns the mapping between the token and the actual card number. With a network token, that mapping sits with the card network itself, independent of any individual payment provider. With a gateway token, the mapping exists entirely within the provider that created it, and nowhere else.

The second is reach: where the credential actually works. A network token's domain extends across providers that recognize network tokens from that card network, giving it a meaningfully wider reach than a single integration. A gateway token, by contrast, is limited to the provider that issued it and doesn't work outside that relationship.

Together, these 2 differences – who controls the mapping and where the credential works – explain most of what matters when comparing the two in practice.

Where can each token be used and moved?

A network token stays with the merchant across a PSP switch because the card network, rather than the provider, owns the token relationship. A gateway token doesn't move at all because it exists only within the PSP that issued it.

This difference is best understood as 2 separate questions, as usage rights and migration rights sit with different parties. Treating them as the same thing can lead to incorrect assumptions about what's actually portable.

Even network tokens aren't automatically portable everywhere. Each is constrained to a specific merchant, device, or payment scenario, which limits where it can be used even though the network owns the underlying relationship. The token service provider registers the token requestor, and that specific registration determines whether and how migration can happen. So network tokens shouldn't be assumed to travel freely in every scenario.

Who updates a card credential when it changes?

The card network updates a network token when the underlying card is reissued, while a gateway token is refreshed through the provider's own vault instead.

Network tokens are "maintained by card networks and updated when cards expire," so the update happens centrally at the network level, regardless of which providers a merchant uses downstream. A gateway or PSP token works differently: it's refreshed by that specific provider's vault, or through an account updater service connected to that provider.

This matters more than you might expect for anything running on a schedule. Recurring charges can fail unless the service that owns the credential has refreshed it, and assuming one update covers every stored token is the kind of mistake that can break subscription billing months later.

Which credential is sent on each transaction?

The credential sent depends on the route selected, because each provider accepts a different token rather than one fixed default that works everywhere.

The stored credential is one field within the authorization request, rather than the request itself. Several other elements travel alongside it, including, in some cases, a cryptogram: “a dynamic, one-time-use cryptographic value,” required for customer-initiated payments, a token's first use, and after a BIN update. It's typically not required for later merchant-initiated payments, where the relationship has already been established.

Payrails' proxy API defaults to the vault token when both a vault and network token exist on an instrument, unless the request explicitly calls the network token placeholder instead. In practice, that means routing configuration, rather than token type alone, determines what actually gets sent on any given transaction.

What stays in PCI scope after tokenization?

Tokenization can reduce PCI scope, but any system that collects, stores, or detokenizes card data remains inside the cardholder data environment.

PCI SSC explicitly includes “de-tokenization and PAN storage” as part of that environment, so tokenization doesn't provide a clean exit from PCI obligations simply because a card number has been replaced with a token somewhere downstream.

Tokenization doesn't eliminate PCI DSS obligations. It can, however, reduce the number of specific components that fall within scope, narrowing the boundary rather than removing it. Any system that still touches the raw PAN, whether during initial collection or a later detokenization step, remains firmly inside the cardholder data environment, even if the rest of the stack has moved to tokens.

What is the difference between network, gateway, and vault tokens?

Review your own token setup with Payrails

Reviewing your token setup is most useful at the individual payment instrument level, rather than as a single audit of the system as a whole. Start by identifying which credentials exist for each stored instrument and who controls the mapping behind each one.

From there, look at what happens when the preferred credential isn't available. If a network token can't be used for a particular transaction, which credential takes its place, and how is that fallback handled? Payrails lets merchants manage multiple token types for the same payment instrument, giving them more control over which credential is used.

That gives you a clearer picture of where your current setup is working well and where coordination could improve. Try it with Token Vault, or book a demo to see it across your provider mix.