The Complete Guide to Network Tokenisation

What is network tokenisation and how does it work?

Put simply, a network token is a substitute for a customer’s primary account number, or PAN. It looks like a card number, but is a string of digits generated and controlled by the card network itself, connected to a specific merchant (and often a specific device).

Crucially, the token is useless to anyone who doesn't have the cryptographic keys to process a transaction with it.

Who issues the token?

Network tokens come from card networks directly, as opposed to a payment orchestration platform (like APEXX) or your payment gateway.

They are issued through services such as Visa's Token Service (VTS) and Mastercard's Digital Enablement Service (MDES).

That detail matters because it's what gives network tokens their two defining properties: the networks maintain the live link between a token and the underlying card, and because the networks issue the token, it belongs to your relationship with the card network rather than to whichever platform happened to process the transaction that created it.

In practice, the process means that a customer’s card details are captured only once, during a first purchase or sign-up. Your payment provider requests a token from the relevant card network on your behalf.

The card network checks that a card is genuine and active, then generates a token tied to you as the merchant, and returns it along with the cryptographic material needed to use it.

From that point on, the merchant stores and transacts with the token instead of the PAN. When a payment is actually authorised, your acquirer and the network exchange the information needed to process it against the real card, a step called detokenisation, entirely outside your own systems.

How network tokens compare to other token types

Most merchants will hear the word "token" coming from several places at once: their gateway, their PSP, their orchestration platform, and now the card networks themselves. It's easy to assume that they're all interchangeable, but that’s not the case, and the difference matters most when you try to switch a payment provider and discover that the tokens you built up over years don't travel with you.

Network tokens vs. gateway tokens

A gateway token solves a real problem: it lets you store a reference to a card instead of the card itself, inside that one gateway's systems. 

However, the token only exists because that gateway created it, and it generally can't be used anywhere else. If you add a second PSP for a new market, or move away from your existing gateway entirely, those tokens don't come with you.

This results in needing to ask customers to re-enter their card details, which is exactly the friction tokenisation is designed to remove.

Network tokens vs PCI / vault tokens (and where APEXX tokens fit)

PCI, or vault, tokens work on the same principle as gateway tokens: a reference number stands in for the card, and the actual PAN sits in a vault operated by whichever platform you're using.

APEXX tokens are a version of this. They're generated and held within the APEXX platform, and they work across every acquirer and gateway you've connected through APEXX, which is enough to get most merchants the operational and compliance benefits of tokenisation immediately.

The difference between PCI and network tokens is where the registration sits. A network token is registered to you, with the card network, independent of any one platform. An APEXX token is registered to your account within APEXX.

The approach taken by APEXX offers PAN redundancy, so if a network is unavailable for detokenisation, APEXX can still retrieve the underlying card details and attempt authorisation with your preferred acquirer.

Most merchants running on APEXX end up using both types of token: network tokens for the portability, with APEXX orchestrating how and where they're used.

Tokenisation vs. encryption

Tokenisation and encryption commonly get confused, primarily because they are both ways of protecting card data. Crucially, they work in opposite directions. In summary, tokenisation is a reference to information that lives elsewhere, whereas encryption is a ‘transformed’ version of information that requires a ‘key’ to transform it back.

Encryption transforms data using a key, and the same key (or its counterpart) can transform it back. It's reversible by design, which is what makes it right for protecting data in transit or at rest.

Tokenisation doesn't transform the card number at all; instead, it replaces it with a value that has no mathematical relationship to the original, held in a lookup that only the issuing network controls.

There's no key that turns a token back into a PAN; there's only a record, held elsewhere, of which token maps to which card. That's why tokenisation removes card data from your environment altogether, rather than just disguising it while it's there.

How network tokenisation reduces PCI DSS compliance scope

Rather than removing PCI DSS compliance scope, network tokenisation reduces it.

Firstly, as soon as your systems stop holding PANs, storage requirements fall away. That means the controls built around stored cardholder data (encryption at rest, restricted access, quarterly internal scans of anywhere card data might live, key management for that data) largely stop applying to you.

Given that this is the element that makes PCI DSS assessment expensive and time-consuming, this is where a significant saving in effort can be found.

What doesn't disappear is everything to do with how card data reaches you in the first place, if it reaches you at all. If your checkout still captures card details before tokenisation happens, even briefly, the controls around that entry point and its transmission still apply.

Access controls around the tokens themselves, and around whichever systems can request detokenisation, still need to be in place. Your actual PCI DSS level, and the specific requirements that remain, depend on how your checkout is built and how card data flows through it before it becomes a token, so it's worth having that conversation with your QSA rather than assuming tokenisation alone settles your compliance position.

How network tokens cut card-not-present fraud

Because a stolen network token isn’t the same thing as a stolen card number, network tokens have been shown to reduce fraud. The reduction in fraud has been reported to be as much as 26%.

Because it's cryptographically bound to a specific merchant (and frequently a specific device), a token intercepted in one place has no value anywhere else. A stolen PAN, in contrast, works wherever card details alone are enough to transact.

Card networks also use additional risk signals with token-based transactions, which acquirers and issuers use to authorise genuine payments with more confidence. The practical effect for the merchant is that fewer fraudulent transactions get through. Likewise, the mechanism in place means fewer legitimate transactions are incorrectly declined because the systems assessing them have more information to act upon than with a bare card number.

We’ve previously written a guide on the wider toolkit for fraud prevention, you can read that here.

How network tokens keep recurring payments and subscriptions running

When a customer’s payment card is re-issued, be that as part of a routine refresh or the replacement of a lost or compromised card, subscription payments that relied upon the old card will fail.

If a subscription system retains the customer’s original PAN, payment will fail at the point of issue of a new card.

This is another area that network tokens can solve the issue before it happens. With a network token in place, the card network updates the token behind the scenes before a card renewal date arrives, using the same card-on-file update service that keeps the token linked to the live account.

Token portability and why network tokens travel across acquirers and gateways

Token portability matters most when you run an orchestration setup rather than a single PSP. It answers a common question in our industry; what happens to my tokens if I add or switch a provider?

With a network token, the answer is that nothing has to happen.

Because the token is provisioned once and registered to you rather than to any single gateway, it's usable across every acquirer and gateway connected through your orchestration layer. If you add a new acquirer for a market you're expanding into, or route transactions dynamically across several acquirers for resilience, the same tokens will continue working without being re-provisioned for each one.

In the case of a single PSP setup, adding a secondary provider will often mean asking customers to re-enter their card details.

Network tokenisation FAQs

What's the difference between a network token and a card number (PAN)?

A ‘primary account number’ or PAN is a customer’s actual card number. A network token is a substitute value that stands in for it during a transaction, with no mathematical way to derive the PAN from the token itself. Think of it like a reference to a separately stored log of the PAN.

Do I need to be PCI compliant if I use network tokens?

Yes, however the scope of what applies to you will typically be much smaller. Crucially, tokenisation removes the need to store PANs. Anything involving how card data reaches you prior to tokenisation and how tokenisation is controlled still falls under PCI DSS.

Which card networks support tokenisation?

Visa (through the Visa Token Service) and Mastercard (through the Mastercard Digital Enablement Service) are the most widely supported, with American Express and other regional schemes offering equivalent services. Exact coverage depends on your card mix and the markets you operate in, so it's worth checking with your APEXX account team which schemes apply to you.

What happens to my network token when a customer's card is reissued?

The card network updates the token automatically through its card-on-file update service. Your customer won’t need to provide their new details, and in most cases you won't need to do anything on your end either.

Can I use the same network token across multiple acquirers or gateways?

Yes, and it’s a core advantage over gateway or vault tokens. Because a network token is registered to you rather than to any one platform, it works across every acquirer and gateway that supports network tokens, which is what makes multi-acquirer orchestration practical without repeatedly re-collecting card details.

Do network tokens lower interchange or processing fees?

In some cases, network tokens do lower fees. Some card networks offer improved authorisation rates on token-based transactions, and some fee structures pass on savings for certain token transaction types.

Is a network token the same as an Apple Pay or Google Pay token?

It’s related, but not the same thing. Apple Pay and Google Pay use device tokens, a form of network token tied to a specific customer device, provisioned when a card is added to that wallet. The network tokens covered in this guide are merchant tokens: provisioned by you, so you can securely store a customer's card for future transactions.

Both rely on the same underlying network infrastructure, and both replace the PAN, but a device token belongs to the customer's device, while a merchant token belongs to your relationship with the customer.

Is network tokenisation the same as APEXX's own tokenisation?

No, because network tokens are issued by the card networks and registered to the merchant. APEXX token are generated and held within the APEXX platform, and work across every acquirer connected through your APEXX setup.

Ready to add network tokenisation to your stack?

Network tokens cut fraud, shrink your PCI scope, keep subscription revenue flowing through card reissues, and travel with you if you ever add or switch an acquirer. If you're ready to see how it works inside an orchestration platform, visit our tokenisation page or book a demo with the team.