The tokenisation landscape is more fragmented than ever. On one side, international card schemes such as Visa and Mastercard have launched their own tokenisation services - Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES). On the other, infrastructure-level solutions like PCI Proxy offer PSP-independent tokenisation that operates entirely autonomously from any payment scheme. Both approaches replace sensitive card data with non-sensitive tokens, but they do so at different levels of the payments stack, for different reasons, and with different implications for your architecture.
Understanding this distinction is fundamental for any European merchant or payment service provider building a long-term strategy for card data management. Choosing the wrong approach - or failing to recognise that both can coexist - can lead to unnecessary lock-in, higher integration costs, or missed opportunities to improve authorisation rates.
- Network tokens (Visa/Mastercard) live in the scheme's infrastructure and improve authorisation rates; PCI Proxy tokens live in the provider's vault and reduce PCI scope.
- Network tokens are PSP-specific and travel with the acquirer relationship; PCI Proxy tokens are PSP-agnostic, allowing you to switch acquirers without re-collecting card data.
- The optimal strategy combines both: a PCI Proxy token for compliance and portability, with network tokenisation layered on top for better authorisation rates.
What is Network Tokenisation?
Network tokenisation is a scheme-level service provided directly by payment networks. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) are the two primary implementations in Europe, though American Express and other schemes offer similar programmes. The core concept is straightforward: the scheme itself issues a token that maps to the cardholder's Primary Account Number (PAN) within the scheme's infrastructure.
The process starts with a Token Requestor - typically a merchant, wallet provider, or payment facilitator - registering with the scheme and requesting a token for a specific card. The scheme validates the card with the issuing bank, generates a token, and returns it along with a dynamic cryptogram that must accompany every transaction. This cryptogram is unique per transaction and binds the token to a specific domain (e-commerce, in-app, or contactless), preventing misuse if intercepted.
The Token Lifecycle
Network tokens have a managed lifecycle. When the underlying card is reissued - due to expiry, loss, or compromise - the scheme automatically updates the token mapping via services like Visa Account Updater (VAU) or Mastercard Automatic Billing Updater (ABU). This means recurring transactions continue without interruption, reducing involuntary churn for subscription businesses. The token itself remains stable; only the PAN mapping changes behind the scenes.
Domain restrictions add a further layer of control. A token provisioned for e-commerce cannot be used for in-store contactless payments, and vice versa. This limits the blast radius of a token compromise and gives issuers granular control over how and where their cards are used in tokenised form.
What Are PCI Proxy Tokens?
PCI Proxy tokens operate at the infrastructure level - completely independent of payment schemes. When a card number enters your ecosystem - via a checkout form, a call centre operator, a booking API, or any other channel - PCI Proxy intercepts the PAN before it reaches your servers, replaces it with a randomly generated token, and stores the original securely in an isolated, PCI DSS Level 1 certified vault hosted in European data centres.
The token itself can be format-preserving (maintaining the same length and numerical structure as the original PAN, optionally preserving the first six and last four digits) or opaque (an alphanumeric string with a prefix like tok_9f8e7d6c5b4a). In either case, the token has no exploitable value outside the PCI Proxy vault. Your systems store, transmit, and process only the token - never raw card data.
The defining characteristic of PCI Proxy tokenisation is PSP-agnosticism. The token is not tied to Visa, Mastercard, or any specific payment processor. When you need to charge the card, PCI Proxy detokenises and forwards the real PAN to whichever designated PSP you choose - Adyen, Stripe, Worldline, Nexi, or any other provider. You can switch PSPs, route to multiple processors simultaneously, or add new acquirers without ever needing to re-collect card data from your customers.
Detailed Comparison
The table below highlights the key differences between network tokens and PCI Proxy tokens across the dimensions that matter most for European businesses:
| Feature | Network Token | PCI Proxy Token |
|---|---|---|
| Issuer | Card scheme (Visa, Mastercard) | PCI Proxy platform |
| Scope | Scheme-specific (Visa OR Mastercard) | PSP-agnostic, all card brands |
| Authorisation rates | Higher (issuer trust) | Neutral (passes real PAN to PSP) |
| PCI scope reduction | Partial | Complete |
| Cross-PSP portability | No | Yes |
| MOTO support | Limited | Yes |
| Implementation complexity | High (scheme registration, cryptograms) | Low (REST API) |
When to Use Network Tokenisation
Network tokenisation delivers the most value in scenarios where issuer trust directly impacts your revenue. Because the token is issued by the scheme itself, issuing banks recognise it as a verified credential. This recognition typically translates into higher authorisation rates - some merchants report improvements of 2–5% - which can represent significant revenue for high-volume e-commerce operations.
Network tokens also excel in card-on-file scenarios where automatic card lifecycle management is essential. Subscription businesses benefit from automatic card updates provided by VTS and MDES. When a cardholder's bank reissues the card, the network token mapping updates automatically - preventing failed recurring charges and reducing involuntary churn.
Ideal for
High-volume e-commerce merchants processing primarily through a single acquirer, subscription platforms seeking to maximise card-on-file success rates, and digital wallet providers requiring scheme-level domain restrictions.
When to Use PCI Proxy Tokens
PCI Proxy tokenisation is the right choice when your priority is architectural flexibility and complete PCI scope elimination. If you route transactions to multiple PSPs - for geographic optimisation, cost reduction, or redundancy - network tokens will not help, because they are scheme-specific and cannot be detokenised and sent to an arbitrary processor. PCI Proxy tokens, by contrast, work with any downstream PSP because detokenisation happens at the proxy level, not the scheme level.
PCI Proxy is also the natural solution for MOTO (Mail Order / Telephone Order) environments, where network tokenisation support is limited. Call centres, travel agencies, and B2B order offices that collect card data by telephone can use PCI Proxy to tokenise the PAN at the point of capture - ensuring no system in their infrastructure ever stores or processes raw card numbers. This reduces PCI scope from SAQ D (over 300 controls) to SAQ A or SAQ A-EP (fewer than 30 controls).
Additionally, PCI Proxy tokenisation is valuable for any business that needs to future-proof its payments stack. Switching PSPs is no longer a migration nightmare - tokens remain valid regardless of which processor you route to, and you will never need to ask customers to re-enter their card data.
Using Them Together
Network tokenisation and PCI Proxy tokenisation are not mutually exclusive - in fact, the most sophisticated payment architectures in Europe use both in a complementary strategy. The idea is to layer the benefits: use PCI Proxy to completely eliminate card data from your infrastructure, then apply network tokens at the transactional level to boost authorisation rates with issuers.
In practice, it works like this: card data enters your ecosystem and is immediately tokenised by PCI Proxy. Your systems store and reference only the PCI Proxy token. When a transaction is initiated, PCI Proxy detokenises the PAN and - before forwarding it to the PSP acquirer - requests a network token from Visa or Mastercard. The PSP sends the transaction using the network token and the associated cryptogram, gaining the authorisation rate benefits of scheme-level tokenisation. Your infrastructure never sees the real PAN and never manages network token provisioning - PCI Proxy handles both layers.
The layered approach
PCI Proxy tokenisation removes card data from your scope. Network tokenisation improves authorisation rates at the scheme level. Together, they deliver maximum security, maximum flexibility, and maximum authorisation performance - without adding complexity to your systems.
Conclusion
Network tokenisation and PCI Proxy tokenisation solve different problems at different levels. Network tokens optimise the transaction itself - improving authorisation rates, enabling automatic card updates, and providing domain-restriction security. PCI Proxy tokens optimise your infrastructure - removing card data from your environment, enabling multi-PSP routing, and eliminating lock-in.
For European merchants and PSPs, the question is rarely "which should I use?" but rather "how do I combine them effectively?" A well-designed tokenisation architecture uses PCI Proxy as the foundational layer - ensuring raw card data never touches your systems - and then applies network tokens where they deliver measurable value, particularly for high-volume e-commerce flows where every percentage point in authorisation rates counts.
Whether you are building a new payments platform or modernising an existing one, understanding these two approaches - and how they complement each other - is essential for making informed architectural decisions.