What Is a Network Token?
A network token is a card number issued by the card network — Visa Token Service (VTS) for Visa, Mastercard Digital Enablement Service (MDES) for Mastercard — that replaces the real Primary Account Number in a transaction. Unlike a PSP token, which only works inside one gateway, a network token works everywhere that card brand is accepted. It updates itself when the underlying card is reissued, lifts authorisation rates, and lets the merchant keep using a token-on-file long after the original card has expired.
A network token is a card-number-shaped value issued by Visa or Mastercard (or Amex, or Discover) that replaces the real PAN in transactions. Visa calls its programme the Visa Token Service (VTS); Mastercard calls its programme Mastercard Digital Enablement Service (MDES). A network token is functionally a card number — it has the same length, the same checksum, the same BIN — but it routes through the network's token vault before reaching the issuer, and it's scoped to a specific merchant or wallet rather than to the cardholder's real account. Crucially, when the underlying card is reissued, lost or replaced, the network updates the token in the background so the merchant doesn't have to chase the customer for new details. It's the most important piece of card-data infrastructure most people have never heard of.
If you've used Apple Pay, Google Pay or Click to Pay, you've already used network tokens — they're the data format flowing under the bonnet of all three. They've quietly become the default way card data is stored at most large e-commerce merchants, subscription businesses and ride-share apps. The reason isn't compliance theatre; it's that authorisation rates are measurably better and lifecycle headaches measurably smaller when the merchant stores a network token instead of a raw PAN.
What a Network Token Is (and Isn't)
A network token is issued by the card network's token vault — VTS for Visa, MDES for Mastercard. It looks like a normal card number: 16 digits (or 15 for Amex), valid Luhn checksum, BIN belonging to the issuer. The merchant stores the token in place of the real PAN. When the merchant submits an authorisation request, the network recognises the token, de-tokenises it inside its own systems, and forwards the request to the issuer with the real card number. The issuer never sees the token; the merchant never sees the real PAN.
What it isn't: a PSP token. PSP tokens are what your payment gateway hands back when you ask it to tokenise a card — Stripe's cus_xxx identifiers, Worldpay's vault references, Braintree's payment-method nonces. They serve the same compliance purpose (the merchant doesn't store the PAN) but they're proprietary to that gateway and only meaningful inside it. Move the token to a different gateway and it doesn't work. Network tokens work everywhere the card brand is accepted, because the token vault sits at the network level, above any individual processor.
Why Network Tokens Lift Authorisation Rates
This is the part that matters to a CFO. The networks publish authorisation uplift figures for tokenised transactions, and they're consistently in the 2-4% range. The mechanism is straightforward.
When an issuer sees an authorisation request come in, it runs the card details and the transaction context through its risk engine. A typed-in PAN with no extra context (a card-not-present transaction with the card details just sitting in the merchant's database) is the highest-risk profile the issuer sees. A network token, on the other hand, carries metadata signalling that it was provisioned through an authenticated channel — Click to Pay, Apple Pay, a verified card-on-file enrolment — and that it's been kept up to date by the network. The issuer's risk engine treats it more favourably. The same transaction that might have been declined as a fraud-flag with a raw PAN gets approved with a network token.
The effect compounds for subscription businesses. A monthly subscription on a card-on-file model gets hit by reissued-card declines, expired-card declines and fraud-flag declines on a recurring basis. Switch to network tokens and the network's lifecycle service silently updates the token when the underlying card is reissued, so the renewal goes through without the customer ever knowing. Voluntary churn from involuntary churn (broken billing) drops measurably.
Network Tokens vs PSP Tokens
The cleanest way to think about this is layers. A PSP token is owned by your gateway. A network token is owned by the card network. The data flow looks like this:
With a PSP token, the gateway holds the real PAN in its vault, hands the merchant a reference, and de-tokenises that reference inside its own systems on the way to the network. If the merchant moves to a different gateway, the new gateway has to be supplied with the real PANs (a one-off migration that requires both gateways to cooperate, plus PCI evidence), and the old tokens become useless.
With a network token, the card network's vault holds the canonical mapping, the gateway and the merchant both work with the token, and a gateway switch is a non-event from the token's point of view — the token still works at the new gateway because the network is what de-tokenises it, not the gateway. Vendor lock-in goes away.
Most modern gateways now offer network tokens as an option on top of their own PSP tokens — Stripe, Adyen, Braintree, Worldpay, a major gateway all have it. Where it matters, ask explicitly whether you're storing a PSP token or a network token; the difference is what shows up on your balance sheet in two years' time if you ever want to switch processors.
Lifecycle: What Happens When a Card Is Reissued
This is the underrated benefit. Cards get reissued for all sorts of reasons — expiry, loss, fraud reset, design refresh — and historically that meant the merchant's stored card-on-file stopped working until the customer manually updated it. Subscription businesses lost meaningful revenue to this; ride-share and food-delivery apps spent engineering time on "please update your card" prompts.
Network tokens fix this at the source. When the issuer reissues a card, it tells the network. The network updates every network token mapped to the old PAN to point at the new PAN. The merchant's stored token doesn't change, but the next authorisation against it routes to the new card automatically. The customer never needs to know.
The schemes call this token lifecycle management. It's the single most valuable feature for card-on-file merchants and the one most likely to be the business case for migrating to network tokens.
Which Transactions Get a Network Token
Network tokens get generated when a card is enrolled through an authenticated channel. Apple Pay, Google Pay and Samsung Pay all use network tokens by design — adding a card to the wallet provisions a device-specific token, and that's what's transmitted at the point of payment. Every SRC transaction produces one too. And for card-on-file at large e-commerce merchants, the gateway enrols the card with the network at first use and stores the network token instead of (or alongside) its own PSP token. What doesn't automatically produce one: a one-off guest checkout where the customer types the card number once and doesn't save it.
The PCI DSS Angle
Network tokens, like any tokenisation approach, take card data out of the merchant's environment. The merchant stores a token; the real PAN sits in the network's vault. That puts the merchant in roughly the same PCI DSS scope position as one using a fully hosted checkout — SAQ A territory rather than SAQ D.
Paytia's core business is keeping card data out of contact centres on voice calls. Network tokens are the e-commerce equivalent of what we do on the phone: they keep card data out of the merchant's environment on the web. When a Paytia customer takes payments on both channels — voice plus a web checkout — we work alongside whatever network-token capability their payment gateway provides, so the cardholder data stays out of the merchant's network in both directions.
On the voice side, our telephone payment platform captures the digits via masked DTMF and sends them straight to the gateway. If that gateway is set up to enrol a network token at the same time (most modern PSPs are), the merchant ends up storing a network token for future recurring or repeat payments — keyed in once over the phone, then reusable for the lifetime of the customer relationship with all the lifecycle benefits the network provides. The agent never hears the card number, and the merchant never stores a raw PAN.
Frequently Asked Questions
What's the difference between a network token and a PSP token?
A PSP token is issued by your payment gateway and only works inside that gateway. A network token is issued by Visa or Mastercard themselves and works anywhere that card brand is accepted. The practical implication is portability: if you ever switch payment gateways, your PSP tokens are stuck; your network tokens move with you. Most modern gateways now offer network tokens as an option on top of their own PSP tokens — ask your gateway which one you're actually storing.
Do network tokens really improve authorisation rates?
Yes, by 2-4% on average according to figures Visa and Mastercard publish. The reason is that issuers see network tokens as authenticated and properly maintained, so their risk engines treat them more favourably than raw card-on-file PANs. The effect is biggest for subscription businesses, where reissued-card declines also drop sharply because the network silently updates tokens when cards are reissued.
What happens to my stored network token when the customer's card is reissued?
Nothing visible to you — the network updates the underlying mapping in the background. Your stored token stays the same, but the next authorisation against it routes to the new card automatically. The customer doesn't need to update their details, and you don't lose the subscription to involuntary churn. This is the single most valuable feature of network tokens for card-on-file businesses.
Are Apple Pay and Google Pay using network tokens?
Yes — wallet payments have been built on network tokens since the start. When you add a card to Apple Pay or Google Pay, the wallet provisions a device-specific network token. That's what's transmitted at the point of payment, not your real card number. The token is bound to the device, so even if it leaked, it would only be useful from that specific phone.
Do I need PCI DSS compliance if I'm using network tokens?
You still need PCI DSS — every business that accepts card payments does. But network tokens dramatically shrink your scope, because you're not storing the real PAN. Most merchants using network tokens end up on SAQ A or SAQ A-EP rather than the much heavier SAQ D, similar to merchants using fully hosted checkout pages. Your QSA will want to see the integration evidence, but the controls list is short.
See how Paytia handles network token
Book a personalised demo and we'll show you how our platform works with your setup.
Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia