Fintech, Payments

Network Tokenization vs. Vendor Tokenization

Every merchant that stores cards has to decide who holds the real card number and who hands out the tokens. There are two very different answers: network tokenization, where Visa, Mastercard, American Express or Discover issues the token, and vendor tokenization (also called PSP or PCI tokenization), where your payment processor or a third-party vault issues it. Both keep the raw card number (the PAN) out of your systems. Only one of them changes how issuers treat your transactions.

This guide goes deeper than a definitions page. It covers how a network token is provisioned, what the cryptogram does, why approval rates move, how lifecycle updates work, what the rollout really involves, and where the two models fit together. If you want the short side-by-side comparison, see Network Tokenization vs PCI Tokenization: Key Differences.

The Short Answer

Vendor tokenization is a data-security tool. It reduces your PCI DSS scope by swapping the PAN for a reference that only your processor or vault can turn back into a card number.
Network tokenization is a payment credential.

The card network issues a replacement card number that is bound to you (the merchant or token requestor), kept current by the issuer, and used with a one-time cryptogram on each customer-initiated payment.
Most mature merchants use both: a vendor token as the internal reference, with a network token underneath it for authorization.

How Vendor Tokenization Works

When a customer enters a card, your checkout (usually a hosted field or SDK) sends the PAN straight to your processor or vault. The vault stores the PAN in its PCI-certified environment and returns a random string such as tok_8Kd2.... You store that string in your customer profile. When you charge the card later, you send the token to the same vendor, which looks up the PAN and sends a normal authorization to the card network.

Three things follow from that design:

The issuer never sees a token. The authorization carries the real PAN, so the issuer treats it like any other stored-card payment.
The token only means something inside that vendor. A Stripe token cannot be charged through Adyen. Moving processors means a PAN migration between vaults, which is possible but is a project with security reviews and cut-over risk.
The card can go stale. When the card expires or is reissued after a fraud event, the stored PAN stops working unless your processor runs an account updater service (Visa Account Updater, Mastercard Automatic Billing Updater), which is batch-based and not universal.

How Network Tokenization Works

Network tokenization is defined by the EMVCo Payment Tokenisation framework, first published in 2014 and implemented by the networks as the Visa Token Service (VTS), Mastercard Digital Enablement Service (MDES), American Express Token Service and Discover’s token service. The actors are:

Token Requestor: the party asking for the token. This is the merchant, a PSP acting on the merchant’s behalf, or a wallet such as Apple Pay.

Each requestor is registered and gets a Token Requestor ID (TRID).
Token Service Provider (TSP): the card network, which creates the token and keeps the mapping to the real PAN.
Issuer: the cardholder’s bank, which approves provisioning and later approves each transaction.

Step 1: Provisioning

When a customer saves a card, the token requestor sends the PAN to the network’s TSP. The network checks with the issuer, which can approve, decline, or ask for extra verification. If approved, the network returns a network token, a 16-digit number that looks like a card number but is restricted to that requestor, plus token metadata such as a masked PAN and card art. From then on you store and use the token, not the PAN.

Step 2: The Cryptogram

For each customer-initiated payment, the requestor asks the network for a one-time cryptogram (Visa calls it the TAVV). The cryptogram is tied to that token and that transaction. A stolen token without a fresh cryptogram, or used by a different requestor, fails domain controls at the network. This is why a breach of network tokens is far less damaging than a breach of PANs.

For merchant-initiated transactions, such as a subscription renewal, the network rules generally let you reference the original customer-initiated transaction instead of generating a new cryptogram. Check the current rules for each network with your acquirer, because they differ in detail.

Step 3: Authorization and De-tokenization

Your acquirer sends the authorization with the token and cryptogram. The network validates the cryptogram, swaps the token for the real PAN, and passes the request to the issuer along with the fact that it was a tokenized, cryptogram-validated transaction. The issuer sees a higher-assurance payment than a bare stored PAN.

Step 4: Lifecycle Management

When the underlying card is reissued, expires, or is reported lost, the issuer updates the token mapping at the network. The token you hold usually keeps working with no action from you, and you can receive lifecycle notifications to refresh the last four digits and expiry shown to the customer. If the account is closed, the token is suspended or deleted, which stops you from retrying a card that will never approve.

Why Network Tokens Improve Approval Rates

This is the part that matters most to a payments P&L. Network tokens raise authorization rates for three separate reasons:

Fewer declines from stale credentials. Expired and reissued cards are one of the biggest sources of avoidable declines in card-on-file businesses. Lifecycle management fixes most of them in real time instead of on a batch cycle.
Higher issuer confidence. The cryptogram and the requestor binding tell the issuer that the credential came from a known merchant and was not lifted from a breach dump. Issuers’ risk models treat that as a positive signal, which cuts false-positive fraud declines.
Less fraud reaching the issuer. A token stolen from your database cannot be used at another merchant, so card-testing and account-takeover attacks against your stored cards lose most of their value.

Card networks publicly report approval lifts in the low single-digit percentage points and noticeable fraud reductions for tokenized card-not-present traffic. Your own result depends on your mix: subscription and card-on-file businesses gain the most, and one-time guest checkouts gain the least. Measure it with an A/B split or by comparing tokenized and non-tokenized cohorts on the same issuers, and read the result by issuer and by decline code, not only as a blended number. For a full framework, see Authorization Rate Optimization: A Payments PM’s Complete Guide.

Side-by-Side: Network vs Vendor Tokenization

	Network token	Vendor (PSP/PCI) token
Issued by	Card network (TSP)	Processor or third-party vault
What the issuer sees	Token + cryptogram, flagged as tokenized	Real PAN
Portability	Works through any acquirer that supports it, under the same requestor	Locked to the issuing vendor
Card updates	Real time, issuer-driven	Account updater batches, if enabled
Approval rate impact	Positive, often measurable	Neutral
PCI scope reduction	Yes, when you never touch the PAN	Yes, this is its main purpose
Coverage	Depends on issuer and region participation	Any card the vendor accepts

Why You Usually Need Both

Network tokens do not cover everything. Some issuers and regions do not support provisioning, some card types are excluded, and provisioning can fail. You still need a vault reference for those cards, and you need a stable internal ID that does not change when the network token is re-provisioned. The common architecture is:

Your customer profile stores a vendor token as the permanent reference.
Behind it, the vault or PSP holds the PAN and, where available, a network token.
At authorization, the system sends the network token and cryptogram when one exists and falls back to the PAN when it does not.

This setup is also what makes payment orchestration work across processors. If your network tokens are provisioned under your own token requestor (or a vault that can share them), you can route the same card through different acquirers.

See What Is Payment Orchestration? for how routing and token strategy connect.

Implementation Options

1. Let your PSP do it

Stripe, Adyen, Braintree, Checkout.com and most large gateways provision network tokens automatically for stored cards. This is the fastest route and often just a setting. The catch is ownership: the tokens are usually requested under the PSP’s TRID, so they do not move with you if you change processors.

2. Use a network-token-capable vault

Independent vaults and orchestration platforms can act as token requestor for you and pass network tokens to several acquirers. You gain portability and a single view of card lifecycle, at the cost of another vendor in the payment path.

3. Become a token requestor yourself

Large merchants can register directly with each network’s TSP. This gives full control and the best portability, but it means certification work with each network, PCI DSS Level 1 obligations for the PANs you handle during provisioning, and operating the cryptogram and lifecycle calls yourself. It usually makes sense only at high volume.

Rollout Checklist for Product Teams

Baseline first. Record approval rate, fraud rate and decline-code mix by issuer, card brand and transaction type (CIT vs MIT) before you switch anything on.
Back-provision the existing card-on-file base, not just new cards. Most of the lifecycle value sits in cards saved months or years ago.
Track provisioning success rate. Failed provisioning is silent unless you log it. Report it by issuer and by BIN range.
Handle lifecycle events in the product. Update the displayed last four and expiry, and stop retry logic on suspended or deleted tokens. This connects directly to dunning and retry strategy.
Confirm MIT flagging. Renewals must reference the original customer-initiated transaction correctly, or you lose the benefit and may trigger declines.
Decide token ownership early. Whose TRID the tokens live under decides how hard a future processor migration will be.
Check the fee schedule. Network token fees and incentives vary by network, region and acquirer contract. Model them against the approval-rate gain, not in isolation. See Payment Processing Fees for where these costs sit.

Common Mistakes

Treating tokenization as a security-only project. The approval-rate and lifecycle gains are usually the bigger business case, so involve the payments P&L owner, not just security.
Measuring only the blended approval rate. A lift on renewals can be hidden by traffic mix. Compare like-for-like cohorts.
Letting a PSP own all tokens without a plan. Fine for a single-processor business, painful when you add a second acquirer.
Ignoring wallets. Apple Pay and Google Pay already use network tokens (device-bound, under the wallet’s requestor). Card-on-file network tokens are a different, merchant-bound token for the same card.

Where This Is Heading

The networks are pushing tokenization toward the default for e-commerce. Mastercard has said it aims to tokenize all e-commerce transactions in Europe by 2030, and Visa has reported that billions of network tokens are already in use. Tokens are also the foundation for newer flows such as click-to-pay, passkey-based authentication and payments started by AI agents, where the network needs to know which requestor and device a credential is bound to. A merchant without a token strategy will find more of these features out of reach.

Network Tokenization: Key Takeaways

Vendor tokens reduce PCI scope; network tokenization improves approval rates and keeps cards up to date.
Network tokenization replaces the card number with a network-issued token and a cryptogram per transaction.
Most merchants need both: vendor tokens for security and network tokenization for authorization and card lifecycle.
Baseline approval rates before rollout so you can measure what network tokenization actually delivers.

FAQ

Is network tokenization the same as encryption?

No. Encryption scrambles the PAN so it can be decrypted with a key. A token is a substitute value with no mathematical link to the PAN; only the token vault can map it back. See Tokenization vs Encryption.

Does network tokenization remove PCI DSS requirements?

It reduces scope when you never store or process the PAN, but you still have PCI obligations for any environment that touches card data, including provisioning. Your QSA makes the final call.

Can I use network tokens with more than one processor?

Yes, if the tokens are provisioned under a token requestor you control (directly or through a vault) and each acquirer supports network token processing. Tokens provisioned under a PSP’s own requestor ID usually stay with that PSP.

Do all cards support network tokens?

No. Coverage depends on the issuer, the card product and the region. Plan for a PAN fallback and track provisioning success by issuer.

What is a Token Requestor ID (TRID)?

It is the identifier the card network assigns to each registered token requestor. Tokens are bound to it, which is why a token issued to one merchant or PSP cannot be used by another.