Founder, CEO
Network Tokens are the talk of the (payments) town thanks to the cumulative marketing efforts of the card networks and issuers, but they remain a bit of a “dark art” and getting solid data points about their actual impact and implementation is tricky. Over the past number of months, we’ve had a bunch of conversations with payments leaders and thought it would be a good idea to distill network tokens down to their essence, and try to give companies a tactical guide on implementing network tokens. While the term gets thrown around frequently in fintech circles, there's often confusion about what network tokens actually are and how they differ from other tokenization methods.
Mastercard recently announced an ambitious goal: eliminating primary account numbers (PANs: the 16 digit number written on your card) by 2030. This is a nice marketing statement, and it represents a fundamental shift in how we handle payment credentials — but it’s also an effective way for the card networks to build direct relationships with merchants and ensure they can earn more of the payments processing “pie”.
In 2014, EMVCo (the technical standardization body formed by a consortium of card networks: Europay, Mastercard and Visa) published a new standard for Payment Tokenization after a 2013 project between Apple, Mastercard, Visa, and American Express. The standard was initially designed around the requirements of the (then highly secretive) Apple Pay product launch, but the goal was to design an interoperable standard that could be used by other wallet providers, issuing banks, acquirers and Token Service Providers (TSPs).
Interestingly, the original EMVCo Payment Tokenization specification includes zero references to the term “network tokens”, and instead refers only to Token Service Providers. Alongside the launch of Apple Pay, the card networks (Visa, Mastercard, and Amex) each launched their own respective Token Service Providers which coined the term “network token”. Visa launched Visa Token Service (VTS), Mastercard launched Mastercard Digital Enablement Service (MDES — now called Secure Card on File), and Amex launched the American Express Token Service. Since then, a number of companies also launched their own EMVCo-approved Token Service Provider products; some of which are integrated with the card networks, and some are standalone token vaults.
Definitions
What is a Payment Token, and what is a Network Token?
According to the EMVCo Technical Framework, a Payment Token is a surrogate value that replaces the Primary Account Number (PAN) in the payments ecosystem. In practice, they are numbers that look very similar to a typical PANs and they share similar characteristics:
They also differ in a few ways:
What is a Token Service Provider?
A Token Service Provider manages the generation, storage, verification and lifecycle management of a payment token. They maintain the mapping between the payment token and the original card PAN in a token vault. A TSP is typically a card network, an issuing bank, or any other third-party Token Service Provider offerings.
Tokens are requested from a Token Service Provider by a Token Requestor.
What is a Token Requestor?
Token Requestors are entities who initiate the process of tokenization by requesting a token from a Token Service Provider for a given PAN. Token Requestors are normally user-facing products, and include services like Mobile Wallet providers (Apple Pay, Google Pay, Samsung) and eCommerce merchants who want to tokenize cards on file.
In the Apple Pay scenario, Apple fills the role of the Token Requestor. While Apple Pay follows the EMVCo Payment Tokenization standards, it includes additional security features not specified in the core EMVCo specification:
Apple managed to convince partner banks to implement these additional security measures, creating a more secure but slightly different implementation than standard network tokens. This is why, technically speaking, Apple Pay isn't just a "network token" – it's an EMVCo token with additional proprietary security layers. These additional security features meant that Apple had to integrate directly with issuing banks and effectively build their own “network”, which very few businesses would have been able to pull off.
What is a Token Domain?
The EMVCo Payment Tokenization specification defines the concept of Token Domains. Token Domains are the types of transactions for which a Payment Token may be used. Token Domains may be channel-specific (e.g. NFC only), merchant-specific, digital wallet-specific, or a combination of any of the above.
Token Domains allow for certain parameters defining how the token can be used to be passed at the point of token creation. These are known as Token Domain Restriction Controls, and for example a token could be restricted to a particular presentment type (e.g. e-commerce or contactless only), at a particular merchant that can be uniquely identified, or ensuring that a token cryptogram is provided for all payment authorizations for a given token.
In conclusion, a network token is an EMVCo Payment Token provided by a Token Service Provider which is one of the card networks. For example, a Visa Token Service token or a Mastercard Secure Card on File token. Unlike other forms of tokenization, network tokens are created and managed by the card networks themselves or their authorized partners rather than a merchant, a payment gateway, or a token vault — making them inherently better from a security & compliance standpoint as they are not in scope for PCI DSS and allow for Token Domain Restriction Controls to be implemented.
A common misconception is that Token Requestor IDs (TRIDs) are merchant-specific identifiers. In reality, Token Requestor IDs are not Merchant IDs (MIDs) and they are not related in any way. TRIDs are used to uniquely identify a specific Token Domain from a Token Requestor, who could potentially implement additional Token Domain Restriction Controls to ensure that a token is only used/authorized by a specific Merchant ID.
In practice, most issuers do not compare Token Requestor IDs to Merchant IDs during payment authorizations. In fact, many PSPs and payment facilitators (payfacs) often use a single umbrella TRID for multiple merchants.
A common concern that global merchants have is how to segment their network tokens in a multi-merchant setup. For example, imagine you are a multinational chain of fitness clubs and you want to provision network tokens that can be processed by any of your local branches/subsidiaries. Mastercard's On-Behalf-Of Token Requestor (OBOTR) model allows for more flexible multi-merchant setups, as detailed in the diagram below:
When making purchases online, most consumers are used to providing a CVV/CVC value (the 3-4 digit code on the back of your card) to authenticate a payment. How does this work when a network token is persisted on file?
Network tokens handle Merchant-Initiated Transactions (MIT) and Customer-Initiated Transactions (CIT) differently:
Cardholder-initiated transactions (e.g. when a user clicks a “buy” button) with network tokens use a similar value to a CVV under the hood known as a cryptogram. A cryptogram is a one-time-use random value that’s provided by your Token Service Provider and used as an additional authentication value during payment authorization. In practice, this additional value doesn’t materially improve the fraud/risk profile of a payment (as the user is not involved in this cryptogram generation step) but nonetheless it does prove that the network token is still active and the issuer can prevent failed authorizations by providing an upfront guarantee that the network token is valid.
For merchant-initiated transactions (e.g. a recurring subscription) with network tokens, cardholder authentication operates in much the same way as non-network token payments. Transactions can simply be performed without an additional verification step (i.e. no CVV/CVC or cryptogram is required).
The distinction between CITs and MITs is important to understand in the context of working with third-party Token Service Providers, as generating a cryptogram for a network token is an additional API call and (usually) another billable event — an important aspect to consider from a cost forecasting perspective.
Many merchants need to authenticate cardholders using systems like 3D-Secure — either for regulatory reasons (3DS is mandated by Strong Customer Authentication/SCA requirements in Europe under PSD2) or fraud mitigation reasons (successful 3DS authentication eliminates chargebacks for fraud reason codes).
Network Tokens are not a direct replacement for 3D-Secure authentication, and do not directly address the requirements of Strong Customer Authentication in the EU. They also do not block or prevent fraudulent chargeback attempts. That being said, they do help reduce fraud rates as stolen network tokens can not be provided directly to merchants on a checkout page. Stolen network tokens could in theory be used directly by a rogue merchant with a merchant account and payment gateway, but issuers are also less likely to approve these payments as they have a higher fraud footprint.
The good news is that network tokens work out of the box with traditional 3D-Secure Servers, requiring no additional configuration or modification to your existing 3DS setup. The network token simply gets passed to the 3DS Server instead of the raw PAN and the authentication continues as normal — so merchants can continue to shift chargeback liability and comply with SCA in the same way as they do with normal PANs.
PCI DSS Implications
One of the major advantages of network tokens is that they are not considered cardholder data under PCI DSS. PCI is an extremely costly and time-consuming compliance framework. However, while network tokens themselves are out of PCI scope, there's a catch: you still need to collect the original card number to provision the network token. This means you're either locked into your Payment Service Provider (PSP), you need a Token Requestor who offers card collection iframes to reduce your scope, or you ultimately end up fully in scope for PCI DSS despite making the network token switch.
In general, merchants and service providers have aimed to descope their PCI environment wherever possible in recent years to mitigate cost by embedding payment iframes in their checkout flows — but unless you rely on your PSP to provision and control network tokens on your behalf, it means you’ll need a Token Service Provider to provision tokens on your behalf without you touching network tokens in any form.
For merchants who process a lot of recurring payments for subscriptions or repeat purchases, one of the major causes of churn is expired cards. In recent years, merchants have taken advantage of Card Account Updater services from the card networks. Card Account Updater requests are generally performed in batches (generally a couple of days before a recurring payment as the card networks take up to 48 hours to return a response) and they can be extremely costly — the standard rate for card updates is typically in the region of $0.25 per card. Assuming on average a card is re-issued (because of loss, theft, or expiry) on average every 3 years this can become a very material cost for merchants with large customer bases.
Network tokens offer similar functionality known as Card Account Lifecycle Management (abbreviated as “CALM”). CALM is the network tokens equivalent of account updater services, and although it provides much of the same value it differs in two important ways:
Join our webinar with Shane Curran, CEO of Evervault, on December 4th as he dives into the world of Network Tokens with Liam Wiltshire, Overwolf's Head of Payments.
Register nowNetwork tokens affect payment performance in four main ways: authorization rates, interchange fees, fraud decreases, and churn reduction.
According to Deloitte, merchants report an average authorization rate uplift of 2.1% with network tokens. In our experience, this figure is reasonably accurate — we have seen recurring merchants with ~1% uplifts on the lower end but also significantly higher auth rate uplifts at 4%. It’s important to ensure you’re comparing off a fair benchmark (many PSPs are already using network tokens under the hood without merchants realizing it). However, as network token adoption increases, this advantage might diminish as the uplift gets eroded away. The real long-term value lies in:
Reduced fraud rates: Deloitte also claim that merchants have seen a 26% reduction in fraud rates as the theft of network tokens does not mean they can be used for fraudulent payments.
Reduced churn from expired cards: CALM can ensure that card details are always kept up-to-date, reducing unintentional churn for subscription businesses.
Interchange fee reductions: The card networks are heavily incentivizing network token adoption, and are moving towards a model where merchants and acquirers will be penalized for not using network tokens. In October 2025, Visa will be increasing their network fees threefold for payments that are not using the Secure Credential Framework (i.e. either network tokens or 3D-Secure authentication)
There are four primary ways to implement network tokens:
Direct Integration with Card Networks
All of the card networks offer their own Token Service Provider offerings (Visa VTS, Mastercard MDES, Amex AETS), which merchants can integrate with directly. This is likely the best option for merchants who are extremely cost sensitive, as they are likely to get the best rates for network token provisioning from the networks. That being said, the card networks have limited capacity to onboard individual merchants and only allow extremely large merchants to access these products directly. For smaller or mid-sized merchants, they are instead encouraging integrations with their payment gateway offerings (like Visa’s Cybersource) which bundle cross-network network token provisioning.
Token Requestor / Token Service Provider (TR-TSP)
Some companies (including Evervault) offer standalone Network Tokens APIs which can be used to provision Token Requestor IDs and network tokens which can be used across all acquirers. This is a great fit for merchants who value independence and who may already have a multi-PSP or multi-acquirer setup. Network tokens can be provisioned once, stored on file, and used for all subsequent payments across all acquirers.
Payment Service Provider (PSP)
For many (especially smaller) merchants who are using just one PSP, leveraging their existing network token offering is a great choice. Generally, they can be enabled very easily with minimal (if any) engineering work. It’s important to consider the long-term lock-in that this leads to, as the network tokens do not belong to you and can’t easily be migrated to other PSPs or TSPs.
Click to Pay and Cloud Tokens
One argument for why the card networks are pushing network tokens quite heavily is it allows them to embed themselves more deeply with merchants, as creating and retrieving network tokens involves the card schemes in one extra round-trip for a payment.
Placing the card networks front and center on a merchant’s website is a clear part of their strategy with their Click to Pay offerings. Click to Pay allows cardholders to share their payment credentials directly with a merchant through a card-scheme controlled page in the form of a network token. These Click to Pay products act similarly to mobile wallets like Apple and Google Pay for e-commerce transactions where mobile wallets are not available, and in these cases the card networks act as Token Requestors.
As we move towards Mastercard's 2030 vision of a PAN-less world, network tokens will become increasingly important. Using network tokens instead of PANs is a question of when, not if — and as time goes on, it will be increasingly difficult to conduct business online without using network tokens. Some of the main areas to consider (and outstanding challenges) for companies as they think through their network token rollout is:
Network tokens are going to become the default, so take advantage of the short-term opportunity while you can.
Create and use network tokens in minutes with Evervault’s streamlined APIs. Avoid payment gateway lock-in and time-consuming direct integrations with card networks.
Learn more
Multi-payment processor systems integrate multiple payment providers to handle transactions. Use Multi-psp to boost coverage to local populations and minimizes net transaction fees.
Mathew Pregasen
We've launched new payment extensions, 3D-Secure, account updater, and made many enhancements to our core product!
The Evervault Team