Payment Tokenization Explained: PSP, Network and Device Tokens

Visatk Team · September 21, 2026 · 8 min read · اقرأ بالعربية

Payment tokenization explained: how PSP, network and device tokens replace card numbers, how network tokens work, and what they mean for security and PCI DSS.

Every stored card number is a liability. If it leaks, it can be misused; if the card is reissued, the stored number stops working; and while you hold it, your systems sit inside the scope of PCI DSS. Payment tokenization solves all three problems by replacing the real card number with a substitute value, a token, that is useless to anyone who steals it outside its intended context.

Tokenization is now everywhere: in one-click checkouts, subscriptions, mobile wallets and card-on-file programs. Yet "token" means different things depending on who issues it. This guide explains the three main kinds of payment tokens, walks through how network tokenization works step by step, and outlines the benefits, limits and practical steps for merchants.

What Is Payment Tokenization? #

Tokenization is the process of swapping a sensitive value, here the Primary Account Number (PAN), for a surrogate value that has no exploitable meaning on its own. The mapping between the token and the real PAN is kept in a secure system called a token vault. Only the party that controls the vault can convert the token back into the card number, a step called detokenization.

For a merchant, this means you can keep a reference to a customer's card, charge it again later and issue refunds, without ever holding the actual card number. If an attacker steals your database, they get tokens that cannot be used at another merchant.

Tokens can also be scoped. A token might be valid only for one merchant, one channel such as e-commerce, one device, or even a single transaction. The narrower the scope, the less damage a leaked token can do, which is why modern payment systems layer several kinds of tokens rather than relying on one.

Tokenization vs Encryption #

The two are often confused, and both have a place in a secure payment stack. The key difference is that encrypted data can be decrypted by anyone with the key, while a token has no mathematical relationship to the original number.

The Three Kinds of Payment Tokens #

1. PSP or gateway tokens #

When you save a card through your payment provider, it stores the PAN in its own vault and gives you a token, often an alphanumeric string. These tokens only work with that provider. They are excellent for reducing your PCI scope, but they create a degree of lock-in: if you switch providers, you need a secure card data migration between the old and new vaults.

2. Network tokens #

Network tokens are issued by the card networks themselves through services such as Visa Token Service and Mastercard Digital Enablement Service (MDES), following the EMVCo payment tokenization framework. A network token looks like a card number, is linked to the underlying card by the network and issuer, and is restricted to a specific merchant or token requestor. It is used together with a one-time cryptogram for each transaction.

3. Device tokens #

Mobile wallets such as Apple Pay and Google Pay use network tokens provisioned to a specific device. The device token, sometimes called a device PAN, is stored securely on the phone or watch, and each payment includes a cryptogram generated on the device after the user authenticates with a fingerprint, face or passcode.

These layers often stack. A provider can hold a network token in its vault and hand you a PSP token that points to it, so you get the convenience of one and the benefits of the other.

How Network Tokenization Works Step by Step #

1. Provisioning request: when a customer saves a card, the token requestor (usually your payment provider acting for you) asks the network's token service for a token.
2. Issuer approval: the network checks with the issuer, which can approve or decline the provisioning.
3. Token issued: the network returns a token tied to the card and restricted to that requestor and domain.
4. Payment: at checkout, the provider requests a fresh cryptogram for the token and sends both in the authorization.
5. Detokenization: the network validates the cryptogram, maps the token to the real PAN and forwards the request to the issuer.
6. Lifecycle updates: if the card is reissued, expires or is closed, the network updates or suspends the token automatically.

If you want the wider picture of how an authorization travels between merchant, acquirer, network and issuer, see our guide to how card payments work.

Benefits of Network Tokens for Merchants #

• Fewer failed renewals: when a customer gets a new card, the token stays valid, which keeps subscriptions and stored cards working without asking the customer to update details.
• Stronger security: a stolen network token is restricted to one merchant and cannot be used without a valid cryptogram.
• Better issuer confidence: issuers can see that a transaction uses a token and cryptogram, which many treat as a positive signal. Networks report improved approval rates for tokenized transactions, although results vary by market and issuer.
• Reduced breach impact: a database of tokens is far less valuable to criminals than a database of card numbers.
• Possible cost incentives: some networks and acquirers offer pricing incentives for tokenized card-not-present transactions in certain markets; check with your provider.

Limitations and Trade-Offs #

Tokenization is powerful, but it is not a cure-all. Keep these points in mind:

• Not every card can be tokenized. Some issuers or card programs do not support network tokens, so your system must fall back to a PSP token on the PAN.
• Tokens do not stop every kind of fraud. Account takeover, friendly fraud and social engineering still happen with tokenized cards, so keep your risk controls in place.
• Portability needs planning. Ask your provider up front how you can export card data securely to another PCI-compliant vault if you ever switch.
• Analytics change. Because the token differs from the PAN, the same card can appear under different values across channels.

Tokens in Subscriptions and Card-on-File Payments #

Recurring billing is where tokenization pays off most visibly. Without tokens, a subscription business stores card numbers (or PSP tokens tied to them) and watches a steady share of renewals fail every month because cards expired, were lost or were replaced after a breach. Card updater services help, but they run in batches and do not cover every issuer.

With network tokens, the update happens at the network level as soon as the issuer reissues the card, so the next charge simply uses the same token. To get the most out of this, follow a few practices:

• Flag stored-credential transactions correctly (customer-initiated versus merchant-initiated) so issuers understand the context.
• Keep the original transaction reference from the first payment and send it with later recurring charges where your provider supports it.
• Listen for token lifecycle webhooks, such as a token being suspended, and contact the customer before the next billing date.
• Retry declines thoughtfully, following network rules on retry limits instead of hammering the issuer.

Tokenization and PCI DSS #

If tokens are generated and stored by your provider and you have no way to convert them back to card numbers, systems that hold only tokens can often fall outside your PCI DSS scope. That is why tokenization, combined with hosted payment fields, is the foundation of most low-effort compliance strategies described in our PCI DSS guide for small merchants.

Scope reduction is not scope elimination. The pages that load payment fields, the accounts that can trigger charges and your provider relationships still need protection. Confirm the final scope with your acquirer or assessor.

Tokens, BINs and Fraud Analysis #

Network and device tokens come from token ranges assigned by the networks, so the first digits of a token are not always the same as the BIN of the underlying card. If you run a BIN lookup on a token, you may get the token range rather than the issuer's original card details. Most providers return the underlying card's BIN, last four digits, brand and type as separate metadata; use those fields for risk rules and look them up with the BIN checker.

Tokenized wallet payments authenticated on the device also interact with strong customer authentication rules. Our explainer on 3-D Secure covers how authentication and liability shift work alongside tokens.

How to Get Started #

1. Ask your provider whether it supports network tokens for card-on-file and recurring payments, and whether they are enabled by default.
2. Confirm that card metadata such as BIN, last four, expiry and PAR is returned with each token.
3. Remove any stored PANs from your own systems and replace them with tokens.
4. Offer wallets such as Apple Pay and Google Pay to benefit from device tokens.
5. Track approval rates and renewal failures before and after enabling network tokens.
6. Document data portability terms in your provider contract.

Check the issuer, type and country behind a card's BIN

Frequently Asked Questions #