A customer may still see a saved card at checkout, but the merchant should no longer be holding the full card number. Under RBI’s card tokenization framework, that number is replaced with a restricted token linked to a particular merchant, requestor, or device, which limits how widely reusable card data is stored.
This blog follows the process from customer consent and token creation to issuer checks, payment approval, settlement, deletion, and card renewal. It also examines what tokenization protects, where its security limits remain, and what customers, merchants, issuers, and payment providers must still manage.
What is Card Tokenization
Card tokenization is the process of replacing a card’s full Primary Account Number, or PAN, with a unique token that can be used only within an approved payment relationship. For a saved card, that token is tied to the card, token requestor, and merchant, while a device token is also linked to the registered device.
Unlike masking, which only hides selected digits, tokenization removes the need for the merchant to use the actual card number during repeat payments. Encryption still stores the original data in coded form, but a token works as a separate reference. The authorised token service provider keeps the secure link between the token and the card.
Why Card Tokenization Was Introduced in India
Merchants and payment intermediaries once stored full card details to make repeat purchases easier. That convenience came with a clear risk, because a breach at any point could expose card numbers that might be used elsewhere. Tokenization was introduced to keep saved-card payments available without leaving the original card data across multiple systems.
Effective from 01 October 2022, card issuers and card networks are the only entities allowed to store the actual card-on-file data. Allowing a card to be saved under the RBI card tokenization mandates customer consent and issuer authentication. The guest checkout facility continues to remain available.
Who Participates in a Tokenized Card Transaction
Cardholder
The cardholder chooses whether to save the card, gives consent, and completes issuer authentication. Supported tokens can later be viewed or removed.
Token Requestor
The token requestor accepts the instruction and submits it through an approved route. A merchant, payment application, or permitted participant may perform this role without retaining the full number.
Card Network and Token Service
An authorised card network or issuer creates the token, protects its mapping, applies usage restrictions, and manages suspension, deletion, or replacement.
Card Issuer
The issuer validates the card for token creation, then checks authentication, card status, funds or credit, limits, and risk before each decision.
Merchant, Acquirer, and Payment Gateway
The merchant raises the purchase request, the gateway carries messages, and the acquirer connects it to the network. A sound payment gateway integration must match the token with its order, response, refund, and settlement.
How Credit and Debit Card Tokenization Works
A saved-card payment looks simple at checkout, but several controlled steps take place before the customer can use that card again.
Card Details and Consent
The process starts when the customer enters the card information and chooses whether to save it. The merchant must present that option clearly, after which the customer gives consent and completes issuer authentication.
Token Creation
The token requestor then sends the card details through an approved channel. An authorised provider creates a unique token linked to the permitted merchant, requestor, or device environment.
Storage and Repeat Payment
The merchant stores the token with limited display details, such as the final four digits, where allowed. During a later purchase, the token moves through the payment system instead of the original card number.
Network and Issuer Review
The card network checks the token’s mapping and confirms that it is being used within its approved setting. The issuer then reviews authentication, card status, available balance or credit, transaction limits, and fraud indicators before returning an approval or decline.
Settlement and Card Terms
An approved payment proceeds to clearing and settlement, while the merchant and customer receive the result. Tokenization does not change interest, billing cycles, repayment duties, credit limits, or debit-card balances; it changes only the credential used for payment.
What Makes a Token Different from the Actual Card Number
A token may resemble a card number, but restrictions determine where it can work.
- Restricted use: A saved-card token belongs to an approved merchant relationship; a device token belongs to its registered device setting.
- Poor portability: A copied token should not work as a universal replacement for the original card number.
- Protected mapping: The merchant cannot reverse the token to reveal the PAN.
- Limited storage: The business keeps the token, permitted display details, and references rather than the complete credential.
Tokenization protects the card number, but it does not secure the customer’s account, device, browsing session, or the checkout page itself. Payment gateway security must control access, detect suspicious activity, apply updates, and support a clear response when an incident occurs.
Card-on-File vs Device Tokenization
| Area | Card-on-file tokenization | Device tokenization |
|---|
| Primary use | Repeat checkout with a saved card | Contactless, in-app, or device-led payment |
| Token binding | Card, token requestor, and merchant | Card, token requestor, and identified device |
| Typical setting | Merchant website or application | Phone, computer, wearable, or connected device |
| Where it is used | Approved merchant or requestor environment | Supported wallet, application, or secure device |
| Customer experience | Choose the saved card at that merchant | Choose the registered card on the device |
| Management route | Merchant, requestor, and issuer channels | Issuer, wallet, requestor, and device controls |
Card-on-file tokenization supports repeat online purchases without returning full credentials to the merchant. Device tokenization supports approved devices and channels. Both require authentication and issuer authorization.
Limits and Common Misconceptions
- Tokenization does not confirm that the payer is the genuine cardholder.
- It does not replace two-factor authentication where RBI rules require it.
- It cannot stop phishing, account takeover, malware, or checkout-page tampering.
- It cannot guarantee approval because the issuer may decline the payment.
- It does not remove fraud monitoring, refunds, chargebacks, settlement, or reconciliation.
- Support can differ across countries, networks, issuers, merchants, and channels.
- Recurring debits still need a valid token, compliant mandate, and issuer approval.
- A renewed or replaced card may need fresh consent before earlier merchant links return.
Under RBI’s 2025 authentication directions, effective from April 1, 2026, most domestic digital payments require two distinct authentication factors unless an exemption applies. For non-card-present transactions, one of those factors must be unique to the payment, while a 3D secure flow may support issuer verification based on the applicable rules and the issuer’s risk assessment.
How Cardholders Can Manage Tokens
Use only verified merchant, requestor, wallet, or issuer channels to manage tokens. Never disclose card credentials or authentication codes to support staff.
- Review saved cards in merchant accounts.
- Check token controls in the issuer’s application or internet banking.
- View linked merchants, devices, or applications where available.
- Delete tokens for services no longer used or recognised.
- Report a lost registered device to the issuer promptly.
- Review consent after card renewal or replacement.
- Register again when a valid token stops working.
Deleting a token does not cancel the card. It ends the covered merchant or device relationship. A subscription may fail until another token and mandate are created. Recurring billing controls should track token status separately.
Business Implementation Considerations
A merchant rollout needs technical, operational, and support preparation.
- Use authorised participants for tokenized card payments.
- Record explicit consent without preselecting the save-card option.
- Keep guest checkout available when customers decline tokenization.
- Store only permitted tokens, display details, and references.
- Protect customer and order data outside the tokenized credential.
- Test creation, deletion, renewal, replacement, and failure cases.
- Document fallback steps for provisioning and authorization failures.
- Confirm refund, reversal, chargeback, and recurring-payment behaviour.
- Reconcile orders, gateway responses, acquirer files, and settlements.
- Provide a visible token-deletion route.
- Review production access, interfaces, logs, third parties, and incidents.
A reliable payment processing flow links the customer’s consent, token, order, authorization result, clearing record, and final settlement as one traceable transaction. Fraud prevention controls then review the device, payment pattern, account history, location, and unusual activity to judge whether the request is genuine.
Conclusion
Card Tokenization changes the credential used for repeat payment. The merchant handles a restricted substitute, while the issuer or card network protects the connection to the original card. Fewer systems hold reusable card numbers.
Secure acceptance still depends on consent, authentication, issuer authorization, protected infrastructure, fraud monitoring, token controls, and reconciliation. Tokenization strengthens card-data handling but cannot replace the surrounding payment controls.
FAQs
1. Does a card token remain valid after the physical card is renewed?
Validity is not automatic. RBI requires explicit consent before a renewed or replaced card is linked with earlier merchants. The issuer or network may refresh it after consent, or the customer may need to register again.
2. Can the same token work across two unrelated merchants?
A card-on-file token belongs to a defined card, token requestor, and merchant combination. Another merchant needs a separate relationship. Device tokens are also restricted by their approved requestor and device setting.
3. Is there a customer charge for tokenizing a card?
RBI states that customers should not pay for card tokenization. Commercial arrangements may exist among issuers, networks, gateways, requestors, and merchants, but they are separate from a cardholder token-creation fee.
4. What happens to recurring payments after a saved-card token is deleted?
Future debits may fail because the merchant no longer has a valid credential. The customer may need to save the card again, create another token, and complete the required mandate or authentication.
5. Can a cardholder reverse tokenization without closing the card?
Yes, a token can be removed through supported merchant, requestor, wallet, or issuer controls without cancelling the card. Deleting it does not remove separate tokens for other merchants, devices, applications, or payment uses.
