Tokenisation: A Deeper Dive

Tokenisation has revolutionised digital payments by enhancing security while maintaining a seamless user experience. While many understand its fundamentals, few dive into the intricate processes that power it. This article aims to explore the deeper layers of tokenisation—how it works in different environments, the key players, and the security mechanisms that protect it.

A simple swap-and-go process?

Now, here’s where it gets interesting. Many people assume that tokenisation is as simple as swapping out a card number for a single token and voilà—payment processed! But if only it were that straightforward. In reality, a token alone isn’t enough to process a payment. It’s just one piece of the puzzle. To complete a transaction, additional credentials—like cryptograms, signed digital certificates , and more—are required. But don’t worry, we’ll dive into those juicy details a little later in the article.

Meet the players:

• Customer: The cardholder who initiates the transaction.
• Merchant: The business accepting tokenised payments/ Entity selling goods and/or services to the customer.
• Issuer: Entity issuing the card and responsible for managing the ACS (Access Control Server) to authenticate the cardholder/customer.
• Acquirer: The entity which holds the merchant account and sends payment transaction request to the card network.
• Token Requestor (TR): Entities (like merchants, payment aggregators, and mobile wallets) that request a token from a TSP on behalf of users or merchants.
• Token Service Provider (TSP): Token Service Provider refers to the entity which tokenises the actual card credentials and de-tokenises them whenever required. Earlier only card networks (Visa, Mastercard, RuPay, Amex, Diners) were allowed to act as token service providers. Currently Issuers are also allowed to create tokens and act as token service providers. Simply, these entities generate, manage, and secure tokens.

Note- TR doesn't always connect directly to TSPs. Many rely on service providers like Verestro or PayU to handle the integration and tokenisation workflows. These intermediaries simplify the process, especially for smaller merchants who might not have the resources to build direct connections to TSPs.

TR-TSP is an entity that generates tokens on behalf of TR or merchants using TSP.

• Payment Aggregators (PA): The PA processes payments using the stored/shared token, connecting merchants with multiple PA/PGs.

Some jargons:

• Cryptogram: A unique, one-time-use encrypted code generated during a tokenized payment to authenticate and secure the transaction.
• Device Binding: The process of linking a payment token to a specific device using cryptographic keys to ensure secure and device-restricted transactions.
• JWT (JSON Web Token): A compact, URL-safe token used for securely transmitting authentication and authorization data between parties in a digital payment ecosystem.

Types of Tokenisation

• Merchant Tokenisation (CoFT) is when the token is specific to a single merchant. For example, when you save your card on an e-commerce platform, the platform stores a token instead of your actual card number. These tokens are a unique at: User + Card + Merchant (Token requestor here).
• Device Tokenisation is a security mechanism that binds a token to a specific device, such as your smartphone or smartwatch. This type of tokenization is widely used in mobile wallets like CRED, PhonePe, Apple Pay, and Google Pay. The token is uniquely tied to your device, meaning even if someone manages to extract it, it’s completely useless on any other device—like a paperweight with no function. These tokens are uniquely at: User + Card + Device + Token Requestor

Device tokenisation powers two key payment methods:

• Tap to Pay (NFC/Tap2Pay): Enables seamless contactless payments using your mobile device at Point-of-Sale (PoS) machines. In an NFC-based transaction, a user taps their card or mobile device at a point-of-sale terminal, and the token representing the card information is transmitted securely. The card number is not shared during the transaction, enhancing security.
• In-App Payments Facilitates secure transactions within applications, allowing you to pay across multiple merchants using the same device.

Lifecycle of a Payment Token: From Birth to Retirement

Just like a physical credit card goes through different stages—getting issued, being used for payments, expiring, or being canceled—a payment token follows a well-defined lifecycle. From the moment your device or merchant is onboarded to when a token is deleted, every step ensures security, convenience, and seamless transactions.

The journey of a token involves four key phases:

• Merchant/Device Onboarding – The first step where a merchant or device is registered with a Token Service Provider (TSP) to support tokenised payments.
• Token Activation – Once approved, a unique token is generated and securely linked to the cardholder’s payment account and the specific device or merchant.
• Payment Processing via Token – Every transaction replaces the actual card details with the token, ensuring enhanced security while making payments.
• Token Deletion – When a user removes a card, switches devices, or no longer needs the token, it is securely deactivated and deleted.

This article is structured into key categories for a clear understanding of tokenisation. It covers

Guest Checkout Based Payments

Merchant Tokenisation

• M1: Merchant Onboarding
• M2: Merchant Token Activation
• M3: Merchant Token Payment Processing

Device Tokenisation

• D1: Device Onboarding
• D2: Device Token Activation
• D3: Device Token Payment Processing

Token Deletion

Cybersecurity Challenges in Tokenization

Summary

What's Next?- Token Sharing

Each section provides insights into the processes involved in enabling and using tokenised payments effectively.

Guest Checkout Based Payments

For customers who prefer not to save their card details, tokenisation still works behind the scenes to ensure security and convenience. Here’s how the Guest Checkout flow works:

• Customer Enters Card Details: The customer clicks to add a card during checkout, enters their card details, and chooses to skip or decline tokenisation. This is often the preferred option for one-time shoppers or those who don’t want their card details stored.
• Token Requestor (TR): Fetches Guest Checkout Credentials

Even though the customer opts out of tokenisation, the Token Requestor (TR) still ensures the transaction is secure. Here’s what happens:

- The TR sends a request to the Token Service Provider (TSP) to fetch guest checkout credentials.

- The request includes the card details entered by the user.

• TSP Returns Guest Checkout Credentials: The TSP generates and returns the following guest checkout credentials:

- Token Number/AltID: A temporary token or alternate identifier for the transaction. (not usable for future transactions).

- Token Expiry: The validity period of the token.

- Cryptogram: A one-time-use code to authenticate the transaction.

These credentials ensure the transaction is secure without requiring the customer to save their card details.

• Payment Processing ("the well-known payment flow"): The PA/PG forwards the payment request with the credentials to the acquirers, who then pass it along to the card networks (Visa, Mastercard, or your friendly neighbourhood RuPay). The card networks validates the token credentials and finally route it to the issuer for authorisation and authentication.

M1. Merchant Onboarding to a Token Service Provider (TSP)

Before a merchant can participate in the tokenisation party, they need to get onboarded with a Token Service Provider (TSP) like Visa, Mastercard, or RuPay. This process makes sure the merchant is legit and secure enough to handle tokenised payments.

• KYC & Merchant Verification: The merchant submits Know Your Customer (KYC) documents, including merchant business registration details, PAN, GST, and compliance certifications.
• Token Requestor Registration: The merchant applies to become a Token Requestor (TR) with the TSP. They share the Merchant ID (MID), platform details, and security capabilities.
• TSP Review & Approval: The TSP verifies the merchant’s business legitimacy, security infrastructure, and compliance adherence. If approved, the merchant is issued Token Requestor (TR) credentials to be used in the next steps of token activation/ processing.

Merchant onboarding can be done directly with TSPs via merchant or via any TR onboarded or any other payment service provider.

M2. Merchant Token Activation

Token activation is the process that brings a token to life, making it ready for secure payment processing. Once activated, the token becomes the backbone of every transaction, replacing sensitive card details and ensuring a smooth, secure payment experience. Here’s a step-by-step look at how token activation and payment processing work together:

• User Enters Card Details: The journey begins when the user enters their card details on the payment application’s checkout page. This could be during a purchase or when saving the card for future use.
• Explicit Consent for Tokenisation: The user provides explicit consent to tokenise their card details. This step is crucial for compliance with privacy regulations and ensures the user has control over how their data is used. Consent can be given through a checkbox, a pop-up, or a similar mechanism.
• Token Activation Process: While the user completes the payment (using an AltID or Guest Checkout for temporary processing), the system simultaneously initiates the token activation process. Here’s what happens behind the scenes:

• Token Request: A request is sent to the Token Service Provider (TSP) to generate a Card-on-File Token (CoFT). The request includes:

- TR credentials (from the merchant onboarding flow)

- Card details (PAN, expiry, etc.)

- User details (e.g., userID, name, contact information)

• Token Generation: The TSP generates the token at their end and returns:

- Token Provisioned ID: A unique identifier for the token that acts like a card number for future transactions.

- Token Expiry: The validity period of the token. (can be from a few months to four years)

• Storage: The storage of these credentials is decided between the TSP and the Token Requestor (TR), ensuring security and compliance.

At this point, the token is activated and ready to be used for payments.

M3. Payment Processing with Merchant Tokens

Once the token is activated, it becomes the primary tool for processing payments. Here’s how it works:

• User Initiates Payment: The user selects the saved card (identified via last 4 digits of the card shown) for a new transaction.
• Cryptogram Request: The merchant or payment application sends the Provisioned ID to the TSP, requesting a cryptogram—a unique, one-time-use code that authenticates the transaction.
• Cryptogram Generation: The TSP generates the cryptogram and returns it to the merchant or payment application. (This makes sure every transaction is really coming from your device or a genuine merchant account.)
• Payment Processing: The PA/PG forwards the payment request with the credentials to the acquirers, who then pass it along to the card networks (Visa, Mastercard, or your friendly neighbourhood RuPay). The card networks validates the token credentials and finally route it to the issuer.
• Issuer Verification: The issuer authorises the transaction, card details and authenticates the user. If everything checks out, the issuer approves the transaction.
• Payment Completion: The approval is sent back through the chain, and the payment is completed. The user receives a confirmation of the successful transaction.

D1. Device Onboarding to a Token Service Provider (TSP)

When a device needs to be onboarded with a Token Service Provider (TSP) for tokenisation, it goes through a secure and structured process. This ensures the device is authenticated, trusted, and ready to handle tokenised payments. Here’s how it works, step by step:

• Device Certificate Generation: If the device isn’t already onboarded with the TSP, the application initiates a device certificate generation request. This is handled by the device’s secure storage system. Android KeyStore or iOS Keychain or Secure Enclave.

During this process, a public-private key pair is generated.

- The private key is securely stored in the device’s KeyStore, Keychain, or Secure Enclave.

- The public key is shared as part of the certificate generation response. This step ensures the device has a unique cryptographic identity that can be used for secure communication with the TSP.

• Device Enrolment Request: Once the certificate is generated, the application makes a device enrolment request to the TSP. This request includes:

- The public key (from the certificate generation step).

- Device ID credentials (unique identifiers for the device).

The TSP stores the public key and links it to the device’s identity in its secure database. This step essentially "registers" the device with the TSP.

• TSP Checks Device Credentials: Before approving the enrolment, the TSP performs several checks to ensure the device is legitimate and secure:

- Device Authenticity: The TSP verifies that the device credentials (e.g., Device ID) are genuine and not tampered with.

- Public Key Validation: The TSP checks if the public key is valid and can be used for secure communication.

- Compliance Checks: The TSP ensures the device meets security standards (e.g., PCI DSS) and is capable of securely storing tokens.

- Risk Assessment: The TSP may evaluate the device’s risk profile based on factors like its operating system, security features, and past behaviour.

• Enrolment Status Response: After processing the enrolment request, the TSP sends back a response indicating the device enrolment status:

- If successful, the device is officially enrolled and ready for tokenisation.

- If unsuccessful, the device is not enrolled, and the application may need to retry or troubleshoot the issue.

D2. Device Token Activation

Device token activation is a critical process that ensures tokens are securely bound to a specific device and ready for payments. Depending on whether a Card-on-File Token (CoFT) already exists, the flow varies slightly. Here’s a clear, step-by-step breakdown of how it works:

Scenario 1: CoFT Already Exists-

Some Token Service Providers (TSPs) allow you to leverage an existing Card-on-File Token (CoFT) to simplify the process. Here’s how it works:

1. If a CoFT already exists for the user and card, the TSP can generate a Provisioned Token ID using the CoFT. This Provisioned Token ID acts as a reference to the token for future transactions, eliminating the need to create a new token from scratch.
2. But here’s the catch: explicit user consent is still required. The user must approve the use of the existing CoFT to generate the Provisioned Token ID, ensuring they remain in control of their payment data.
3. This approach not only saves time but also enhances security by reusing an already trusted token. It’s a win-win for both users and merchants!

Scenario 2: CoFT Does Not Exist- If no CoFT exists, the process involves creating a new token and binding it to the device. Now, the TR sends a token provisioning request to the TSP. This includes:

- Card details (PAN, expiry, etc.).

- User and merchant details.

• Token Generation: The TSP generates a token and stores it securely in its token vault. The TSP returns a Provisioned Token ID to the TR. This ID acts as a reference to the token for future transactions.

Steps below will be the same for both Scenario 1 and 2:

• Device Binding Request: The TR creates a JWT (JSON Web Token) signed using the private key (from the device onboarding flow) and shared to TSP along with

- Provisioned Token ID.

- Device ID.

• JWT Validation: The TSP validates the JWT using the public key shared during the device onboarding process.
• Step-Up Authentication: The TSP returns step-up options to the TR. These are dynamic, risk-based multi-factor authentication methods, such as:

- OTP (One-Time Password).

- Biometric authentication (fingerprint, facial recognition).

• User Authentication: The TSP issues an OTP to the user (via SMS, email, or app notification). Alternatively, the user may be prompted for biometric authentication.
• Authentication Submission: The user enters the OTP or provides biometric input, which is shared with the TSP.
• Validation: The TSP validates the OTP or biometric input.
• Token Activation: Once validated, the TSP activates the token and binds it to the device.
• Confirmation: The TR receives confirmation that the token is now active and ready for payments.

D3. Payment Processing via Device Tokenisation

Once a device token is activated, it becomes the key to processing secure payments. The process is similar to Card-on-File Token (CoFT) payments but with an added layer of device-specific security. Here’s how it works in a clear, step-by-step flow:

• Cryptogram Payment Credentials Request- User Initiates Payment and selects the saved card (linked to their device token) on the device (e.g., in a mobile wallet or app) to make a payment.
• JWT Token Creation: The app or payment system creates a JWT (JSON Web Token) signed using the private key (stored in the onboarding flow), Provisioned Token ID (the reference to the token), the Device ID (unique identifier for the device), The Card ID (optional, for additional context).
• Cryptogram Request: The app sends the signed JWT, along with the Provisioned Token ID, Device ID, and transaction details, to the Token Service Provider (TSP). This is a request for cryptogram payment credentials.
• JWT Validation: The TSP validates the JWT using the public key shared during the device onboarding process.
• Cryptogram Generation: If the JWT is valid, the TSP generates:

- A token number (the actual token to be used for the payment).

- A cryptogram (a one-time-use code to authenticate the transaction).

- The token expiry (validity period of the token).

• Response: The TSP returns the above credentials to the app or payment system.
• Payment Authorisation: The app sends the token number, cryptogram, and transaction details to the Payment Acquirer (PA) or Payment Gateway (PG).
• Routing to Card Network: The PA/PG forwards the details to the card network (e.g., Visa, Mastercard, RuPay).
• Issuer Verification: The card network routes the transaction to the issuer (the bank that issued the card). The issuer authorises and authenticates the transaction.
• Approval or Decline: The issuer approves or declines the transaction based on the verification.
• Payment Completion Response: The approval or decline response is sent back through the chain: issuer → card network → PA/PG → app.
• Confirmation: The app notifies the user of the payment status (e.g., "Payment Successful" or "Payment Declined").

Token Deletion: Taking Control of Your Stored Cards

Managing your tokenised cards is just as important as using them. Token deletion gives customers full control over their stored payment credentials, ensuring flexibility and security. There are primarily three ways to delete a token:

1. Through the Merchant App: Simply remove the saved card using the last four digits for identification.
2. Via Token Requestor Apps: Apps like PhonePe and CRED allow seamless token management of your saved cards across merchants and devices.
3. From the Issuer/Bank App: The most comprehensive way to manage and remove your card tokens across all merchants/devices, ensuring complete control over your digital payments.

Cybersecurity Challenges in Tokenization

• Man-in-the-Middle (MITM) Attacks – Attackers can intercept token transactions, mitigated by TLS encryption and mutual authentication.
• Token Replay Attacks – Captured tokens may be reused fraudulently, prevented by cryptograms and transaction-specific tokens.
• Weak Device Binding – Stolen tokens can be misused if binding is weak, secured through biometrics and public-private key cryptography.
• Tokenization Key Management Risks – Weak or exposed cryptographic keys can be exploited, requiring HSMs and frequent key rotation.
• API Security Vulnerabilities – Misconfigured APIs can be attacked, necessitating OAuth, rate limiting, and threat monitoring.
• Supply Chain Attacks on TSPs & Payment Processors – A compromised TSP can issue fraudulent tokens, mitigated by audits and risk management.
• Quantum Computing Threats – Future quantum computers may break tokenisation security, requiring quantum-resistant encryption.

Summary:

Tokenization is a crucial innovation in securing digital payments, minimizing the risks of fraud and data breaches. From merchant and device tokenization to cryptographic security and device binding, each aspect plays a vital role in ensuring seamless and secure transactions. Understanding the interplay of token requestors, TSPs, and compliance requirements helps businesses implement tokenization effectively. As digital payments evolve, tokenisation will continue to enhance security and efficiency, with advancements in cryptographic techniques, biometric authentication, and AI-driven fraud detection shaping its future.

What's Next?

As we come to the end of this deep dive into tokenisation, I’d like to leave you with: What do you think about token sharing? (Imagine a world where your token, created once, can be securely shared across multiple platforms, apps, and merchants. No more re-entering card details, no more juggling multiple saved payment methods—just a smooth, consistent payment journey, no matter where or how you pay.)

Is it the future of payments, a game-changer that will make our lives easier and more secure?

Or does it raise concerns about privacy, security, and control over our financial data?

How do we balance the convenience of a seamless ecosystem with the need to protect user data and comply with regulations?

I see token sharing as a powerful tool to transform the payment landscape. But I also know that every innovation comes with its own set of challenges and considerations.