Tokenisation overview

Learn the fundamentals of tokenisation and choose your implementation type.

Introduction

With tokenisation, your customers can save their card details securely, enabling faster and easier repeat payments without the need to re-enter them each time. Common use cases include one-click checkout, subscriptions, in-app payments, merchant-initiated transactions, and other recurring or repeat payment scenarios.

This article explains how tokenisation works, its main benefits, and the different types of tokenisation, including how they differ and when to use each.

How tokenisation works

Tokenisation replaces the customer’s original card number with a token that you store instead of the actual card details. All primary cardholder data fields can be tokenised, including card number, cardholder name, and expiry date; the CVV/CVC is never stored. There is no limit to the number of tokens you can generate for a customer or card.

The token acts as a secure reference to the underlying payment credential. When a payment is made, the token is used to retrieve and process the associated payment details without exposing the actual card information. Your systems cannot decrypt the token back into the original card number, and the token has no direct value outside its intended payment context. The result is a significantly reduced risk of sensitive card data exposure.

Customers can also remove a saved card when they no longer want it to be available for future payments. In this case, you must delete the associated token. After deletion, the token can no longer be used for subsequent payments.

The exact flow depends on the tokenisation type, but the process generally works as follows:

A customer enters their card details during checkout or as part of a registration flow.
The card details are stored securely, either in a token vault or through a card scheme token service, depending on the tokenisation type.
A token is generated, linked to the original card number, and returned instead of the actual card details.
You store the token and use it for future payments instead of storing or resubmitting the original card details.
When you submit a payment with the token, emerchantpay resolves it to the underlying credential and processes the transaction.

Tokenisation is available for both server-to-server and Web Payment Form (WPF) integrations.

You can tokenise payments made using the following transaction types:

For more details about tokenisation and how it compares to encryption, see the emerchantpay blog.

Note: Tokenisation protects stored payment credentials, but it doesn’t replace cardholder authentication. If Strong Customer Authentication is required, you still need an authentication method such as 3D Secure.

Why use tokenisation

Tokenisation benefits all parties, supporting both better payment experiences and stronger data protection.

For customers, it makes repeat payments faster, easier, and more secure by letting them save their card details for future use. In most cases, returning customers only need to enter their CVV/CVC code to confirm the payment.
For businesses, tokenisation facilitates repeat payments without the need to store sensitive card data in-house. By reducing the amount of cardholder data you retain and process, tokenisation helps lower security risk and can potentially reduce your PCI DSS scope. It also improves operational efficiency by separating stored payment reuse from raw card storage and simplifying repeat payment flows.

Tokenisation types

With emerchantpay, you can implement two types of tokenisation:

gateway tokenisation
scheme tokenisation

The key differences are:

who issues the token
where the token can be used
who manages token updates and lifecycle events

These differences affect how portable the token is, how much operational overhead you take on, and how well the token supports long-term card-on-file performance.

The following sections explain how each type works, what benefits it offers, and when one approach may be a better fit than the other.

Note: With a server-to-server integration, you can run both gateway and scheme tokenisation in parallel.

Gateway tokenisation

With gateway tokenisation, the token is issued and used only within the Genesis environment. When a token is used for a payment, emerchantpay resolves it to the underlying card details for processing.

Gateway tokenisation is a good fit when you want to introduce stored credentials quickly, when emerchantpay is your main payment environment, or when your priority is simplicity rather than token portability or scheme-managed lifecycle support.

Gateway tokenisation offers the following benefits over scheme tokenisation:

Faster rollout – It gives you a quicker route to supporting stored credentials.
Simpler implementation – You only store the token to submit for future payments.
Consistent payment flows – Your stored credential model stays aligned with the rest of your emerchantpay integration.

Scheme tokenisation

With scheme tokenisation, the token is issued by the card schemes rather than by emerchantpay. It is part of the EMVCo Tokenisation Framework and is implemented through scheme token services such as the Visa Token Service (VTS) and the Mastercard Digital Enablement Service (MDES).

Unlike a gateway token, a scheme token is designed for use in a broader payments ecosystem across multiple processors or acquirers and comes with scheme-managed lifecycle support. Scheme tokenisation can keep the token mapped to updated card credentials when a card is renewed, replaced, or reissued. This makes scheme tokenisation particularly useful for long-term card-on-file use cases.

Processing payments with scheme tokens provides the following benefits:

Automatic updates – When a customer’s card is renewed, replaced, or reissued, the card scheme automatically maps their token to the new card credentials, reducing declines due to outdated card details.
Cost optimisation – Card schemes may apply higher fees to non-tokenised or non-scheme-tokenised transactions. By using scheme tokenisation, you can avoid these premiums.
Higher authorisation rates – Scheme tokenisation can improve authorisation performance by helping issuers assess risk more accurately.
Interoperability – Scheme tokenisation works across major card schemes, enabling broad acceptance.

Key differences

The following table summarises the key differences between gateway and scheme tokenisation:

Aspect	Gateway tokenisation	Scheme tokenisation
Who issues the token	emerchantpay	Card schemes, for example VTS and MDES
Where the token can be used	Within the Genesis environment	Across all acquirers and payment processors that support scheme tokens
Lifecycle management	Managed within the gateway model; card details must be updated manually or via account updater services	Managed by the card scheme; card schemes automatically update tokens when cards expire or are replaced
Operational focus	Simplicity, quick implementation	Long-term optimisation of stored credentials, better security
Authorisation rate impact	Neutral or variable	Higher – tokens are trusted by issuers
Best fit	Single-gateway setups, internal routing, straightforward card-on-file use cases, fallback options	Recurring payments, subscriptions, repeat billing at global scale

Choose gateway tokenisation for simplicity and faster implementation within the emerchantpay platform. Choose scheme tokenisation when token portability, automatic lifecycle updates, and long-term card-on-file performance are priorities.

Next steps

See the following links to start setting up tokenisation:

Was this page helpful?