The digital world offers many opportunities and challenges. We frequently hear reports of online fraud. With fintechs, neobanks and banking apps emerging, protecting banking data has become a major concern. Every time a customer enters a card number on a website or app, there is a risk if those data are poorly protected.
Financial institutions and technical partners are encouraged to follow security good practices: VPNs, encryption, multifactor authentication, ISO 27001 certification and PCI DSS. Yet we can never be too careful. Tokenisation adds to existing security layers.
This article explores tokenisation, how it works and where it is used, specifically for online card payments.
What is tokenisation?
In brief, it is a technology designed to protect sensitive information.
2. The problem: protecting card data
A bank card contains sensitive information: its primary account number, or PAN, expiry date and CVV.
If compromised through hacking, poor storage or unauthorised database access, these data can be used for fraud.
3. The solution: tokenisation
Tokenisation replaces sensitive data with a substitute identifier called a token. It:
• has no value outside the system;
• does not directly reveal the card;
• is often restricted to a specific use.
4. An analogy
This week I sent my coat to the dry cleaner. The shop took it and gave me a ticket, a token. Its matching system links the ticket number to my coat. Clothes are sent elsewhere for cleaning. Losing my ticket, or someone fraudulently accessing the shop's data, does not give that person access to the clothes.
• Coat = sensitive data.
• Ticket = token.
• I use the ticket to retrieve my coat.
The ticket does not contain the coat, but allows it to be located. Tokenisation works in the same way.
Real card number: 4123 4567 8901 2345.
Token: X9A7-PLK2-889Q-ZT11.
5. A token's lifecycle
Step 1 — Token generation by the tokenisation provider
When a buyer enters card details—PAN, expiry date and CVV—on a merchant's site, they are sent directly to the provider, often through a secure form field or iframe. The provider:
• checks card validity;
• generates a token, such as tok_visa_42f9a1e3;
• stores a mapping in its vault: token X ↔ real PAN plus merchant, channel and limit metadata.
The token is not calculated mathematically from the card. It is a random or pseudorandom reference.
Step 2 — Delivering the token to the merchant
The provider sends the token without the PAN. It is tied to that merchant and cannot be reused elsewhere.
Step 3 — Using it for payment
The merchant sends the token to the provider. Using its mapping table, the provider sends the real data to the issuing bank for authorisation and returns the bank's approval or decline. The PAN is never disclosed to the merchant.
Step 4 — Storage for recurring payments, optional
This is common for subscriptions such as Starlink or Netflix. The merchant stores the token instead of the PAN. However, the token has a lifetime and may become invalid when the card expires or is lost.
Step 5 — Exchange, or detokenisation
For later payments, the customer returns to the site and selects their saved card and associated token. The merchant submits a new payment request with the same token. This operation is called detokenisation. It cannot be reversed by the merchant, which never retrieves the PAN.
Step 6 — Token expiry or revocation
A token has a limited lifetime and can become invalid for several reasons.
6. What happens after revocation?
The vault deletes the mapping or marks it invalid. Attempts to use the token return a token invalid error. The merchant must request tokenisation again, requiring the customer to re-enter the card.
7. Chronological overview
Types of tokenisation
There are three main types or providers:
• Schemes, such as Visa or Mastercard.
• Service providers: fintechs and Payment Service Providers, or PSPs.
• Internal vault tokenisation used by large banks for secure internal storage.
8. Benefits
Security is the main benefit: protected sensitive data and reduced fraud risk. Tokenisation can also support PCI DSS compliance and improve the user experience through security and fraud reduction.
9. Difference from encryption
In practice, both are often used together.
10. How many tokens can be linked to one card?
Several tokens can refer to the same card, with multiple benefits.
Isolating data leaks
Different tokens at each merchant improve security: a hacker cannot use my Udemy token at Netflix or Amazon.
Granular control
A token can carry specific rules: transaction limits, permitted channels and expiry dates, preventing malicious use.
Independent revocation
Deleting my Amazon token does not stop my Udemy or Netflix tokens working.
By design and for security, tokens are not interchangeable between merchants, although a single merchant may have several tokens for one card.
The provider coordinates this through its PAN-to-token mapping table. The consequences for customers are summarised in the table below.
Closing thoughts
Payment tokenisation is an essential pillar of financial security. It allows confident card use without exposing sensitive information and drastically reduces fraud risk.
As digital payments grow rapidly in Central Africa—e-commerce, Mobile Money and super-apps—tokenisation is a strategic necessity for banks, fintechs and businesses. Financial institutions that have not considered it should get started.
What do you think about tokenisation? I welcome your views.
#DigitalBanking, #tokenisation, #MobileMoney, #Banque, #Wallet, #Monétique
Reasons a token becomes invalid
| Reason | Explanation |
|---|---|
| Card expiry | A token linked to an expired card becomes unusable. |
| Lost / stolen card | The issuing bank notifies the token provider → all tokens linked to that card are revoked. |
| Customer request | The customer removes the card from their account (the merchant requests revocation from the token provider). |
| Inactivity | Some token providers impose a maximum period without use. |
| Blacklisted merchant | If the merchant account is closed, its tokens are revoked. |
Token lifecycle summary
| Stage | Main participant | Data handled |
|---|---|---|
| 1. Generation | Token provider | PAN → token |
| 2. Delivery | Token provider → Merchant | token (without PAN) |
| 3. First payment | Merchant → Token provider → Bank | token → PAN → authorisation |
| 4. Storage | Merchant | token only |
| 5. Subsequent payments | Merchant → Token provider | token → detokenisation → PAN |
| 6. Expiry | Token provider | token deactivated |
Tokenisation and encryption
| Criterion | Tokenisation | Encryption |
|---|---|---|
| Main objective | Replace sensitive data with a token that has no reusable value elsewhere. | Make data unreadable using an algorithm and a secret key. |
| Data format | A token often retains a card-data format (e.g. XXXX-XXXX-XXXX-1234), but cannot be mathematically reversed without access to a mapping table. | Ciphertext is binary, longer than the original data, and never resembles a card number. |
| Reversibility | Only through a secure vault (a mapping database linking the token to the actual card). | Reversible with the correct decryption key (a symmetric algorithm such as AES). |
| Portability | Low: a token is valid for a specific merchant, channel or transaction. | High: once decrypted, the card number can be reused anywhere (dangerous if intercepted). |
| Typical use | Recurring payments, digital wallets (Apple Pay, Google Pay), one-click payments and subscriptions. | Secure card transmission between the payment terminal and the merchant or provider server. |
| Protection level | Primarily protects data after authorisation (storage) and against database leaks. | Protects data in transit (network) and sometimes at rest. |
| Practical example | The merchant stores tok_abc123 instead of the actual PAN (Primary Account Number). | The payment terminal encrypts the PAN with the bank server’s public key before transmission. |