India's RBI Card Tokenization Mandate: What Payment Operators Must Know

India’s Reserve Bank of India (RBI) issued one of the most operationally disruptive payment mandates in recent years. From October 1, 2022, payment aggregators, payment gateways, and merchants were prohibited from storing raw card numbers (PANs) for card-on-file transactions — a regime the RBI calls Card-on-File Tokenization (CoFT). Any operator that had previously saved customer card details for one-click checkout or recurring billing was required to either delete the stored PANs or convert them to network tokens issued by Visa, Mastercard, or RuPay.

The mandate affected every player in India’s card payments stack — merchants, payment gateways, PSPs, and acquirers — and required coordinated implementation across Visa, Mastercard, and RuPay simultaneously. Three years post-implementation, the tokenization ecosystem has stabilized, but operators still encounter compliance gaps, recurring payment edge cases, and integration complexity that this guide addresses directly.

What Changed: The Pre- and Post-Mandate Landscape

Before October 2022, card-on-file storage in India worked as it did globally: a merchant or gateway stored the full 16-digit PAN, expiry date, and (for non-3DS flows) cardholder name in their own database. One-click checkout worked by retrieving the stored PAN and submitting it in a new transaction. This model had obvious security implications — a data breach at any merchant exposed raw card data.

The RBI’s Card Tokenization circular (RBI/2021-22/17) changed this fundamentally. The regulation prohibits:

• Payment aggregators from storing PANs after the transaction is complete
• Merchants from storing PANs at any point in the transaction flow
• Payment gateways from storing PANs except transiently during the authorization request

The permitted alternative is network tokenization: the raw PAN is replaced by a token (a surrogate value) that is specific to the card network, the merchant (or merchant category), and the device/channel. The token is useless outside the specific context for which it was issued.

How Network Tokenization Works in India

Network tokenization in India follows the global token requestor model used by Visa and Mastercard, adapted to include RuPay (National Payments Corporation of India’s domestic network).

The key entities:

• Token Requestor (TR): The entity requesting and using the token — in practice, the payment aggregator or gateway (e.g., Razorpay, PayU, Cashfree, CCAvenue). A Token Requestor ID must be registered with each card network.
• Token Service Provider (TSP): The card network itself (Visa Token Service, Mastercard Digital Enablement Service, RuPay Token Hub). The TSP maintains the mapping between the token and the underlying PAN.
• Issuer: The cardholder’s bank, which must approve token issuance. The issuer’s approval — typically via a one-time OTP or cardholder consent — is required to create a token.

The tokenization flow for a card-on-file use case:

1. Customer enters card details for the first time at checkout
2. The payment aggregator transmits the PAN to the card network’s TSP via a tokenization request
3. The TSP returns a token (typically 16 digits, formatted to look like a PAN) specific to that aggregator-merchant pair
4. The aggregator stores the token, not the PAN
5. On subsequent transactions, the aggregator submits the token in the PAN field of the authorization request
6. The card network detokenizes (maps token → PAN) before passing the authorization to the issuer
7. The issuer sees the real PAN and processes the authorization normally

The token is merchant-scoped: a token issued for merchant A cannot be used at merchant B. This limits the blast radius of a compromise — a stolen token from one merchant has no value elsewhere.

Tokenization Across Networks

Each network maintains its own token vault and issues tokens independently:

• Visa Token Service (VTS): Visa-issued tokens for Visa cards
• Mastercard Digital Enablement Service (MDES): Mastercard-issued tokens for Mastercard cards
• RuPay Token Hub: NPCI-operated token service for RuPay cards

For operators, this means separate Token Requestor registrations with each network. A payment aggregator processing Visa, Mastercard, and RuPay transactions needs three TR registrations, three API integrations with the respective TSPs, and three token storage systems (or a unified internal mapping table). Major payment aggregators (Razorpay, PayU, Juspay) have handled this abstraction for operators who use their services — operators integrating directly with acquiring banks need to build or license this infrastructure themselves.

Impact on Recurring Payments: The E-Mandate Framework

The RBI’s authorization framework for recurring card transactions — the e-mandate regime — predates the tokenization mandate but interacts with it critically. Understanding both together is essential for operators running subscription billing or EMI (equated monthly installment) products in India.

The e-mandate framework (RBI circular RBI/2019-20/193) requires:

• First transaction: Always requires cardholder authentication (AFA — Additional Factor of Authentication, in practice OTP)
• Recurring transactions up to INR 15,000 (~$180 USD): Can proceed without per-transaction AFA, but require a pre-registered mandate
• Recurring transactions above INR 15,000: Require AFA at each transaction — except for specific categories (mutual fund SIPs, insurance premiums, and credit card bill payments) where the RBI raised the threshold to INR 1,00,000 (1 lakh) in June 2022
• Pre-debit notification: the issuer must notify the cardholder at least 24 hours before each recurring debit. The aggregator initiates the recurring authorization; the issuer is responsible for the notification.
• Pre-debit notification: Issuer must notify cardholder at least 24 hours before a recurring debit

Post-tokenization, the mandate must be registered against the token, not the raw PAN. This creates a registration challenge: if a customer’s card is re-issued (new card number, same or different expiry), the token associated with the old PAN is invalidated. The operator needs a mechanism to detect token invalidation and trigger re-registration.

Visa and Mastercard have addressed this through token lifecycle management: when a card is re-issued, the network can issue a new token and notify registered Token Requestors (via the “Token Notification Service” or equivalent). Operators using aggregators that implement token lifecycle callbacks can handle card re-issuance transparently. Operators that built raw PAN storage before the mandate and converted without implementing lifecycle management are exposed to silent authorization failures when cards expire or are re-issued.

E-Mandate Registration in Practice

For a SaaS operator or subscription platform running recurring billing in India:

1. At initial signup, customer enters card details
2. The aggregator tokenizes the card (as above) and registers a mandate with the issuer via the e-mandate API
3. Issuer sends OTP to cardholder for mandate authentication; cardholder approves
4. Mandate is registered: the aggregator has a token + mandate ID for future charges
5. For each billing cycle, the aggregator initiates the debit; the issuer is responsible for sending the pre-debit notification to the cardholder at least 24 hours in advance
6. On the billing date, the aggregator submits a recurring authorization using the token and mandate ID
7. For amounts above INR 15,000, the issuer blocks the transaction until the cardholder authenticates

The 24-hour pre-debit notification requirement is operationally significant. Operators cannot simply charge a stored card at midnight on the billing date — they must initiate the notification pipeline the previous day. Aggregators expose this as a mandatory parameter in their recurring charge API.

Compliance Requirements for Payment Aggregators

The RBI defines payment aggregators separately from payment gateways, and compliance requirements differ:

Payment Aggregator (PA) license holders (entities that onboard merchants and settle funds):

• Subject to RBI circular on PAs/PGs (RBI/2020-21/68): minimum net worth INR 25 crore (~$3M USD) at application, scaling to INR 50 crore by end of third year
• Required to hold PA authorization from RBI (not just registration)
• Subject to full tokenization compliance: cannot store PANs at all
• Must implement token requestor registration with all card networks
• Audit requirements: annual system audit and storage audit to confirm no PAN storage

Payment Gateway (PG) model (technology only, no settlement):

• Technical compliance with tokenization is required (cannot pass or store PANs beyond the transaction moment)
• No direct RBI authorization required (the merchant’s PA or bank holds the payment authorization)
• In practice, most PGs operate under a PA’s umbrella or hold their own PA authorization

Foreign operators collecting Indian card payments via a cross-border acquiring arrangement (e.g., a foreign merchant processed via Stripe US or Adyen Netherlands):

• RBI’s tokenization mandate applies to domestic PAN storage within India
• Cross-border transactions where no PAN is stored in India are technically outside the mandate’s direct scope — but card networks have applied their own tokenization requirements globally
• Operators processing Indian-issued cards cross-border should still implement tokenization to reduce card-not-present fraud; authorization rates on tokenized transactions are measurably higher than on raw PAN transactions for Indian-issued cards

Practical Integration Steps

For operators building or auditing their India card processing stack:

Step 1: Confirm Token Requestor status If using a payment aggregator (Razorpay, PayU, Cashfree, Juspay), confirm they hold active Token Requestor IDs with Visa, Mastercard, and RuPay. Obtain confirmation in writing — TR registration can lapse if volume thresholds are not met.

Step 2: Audit existing card storage Run a scan of your database for any PAN-format strings (16-digit sequences matching Luhn algorithm). If any exist and post-date the October 2022 mandate, this is a compliance gap. Engage your PA to convert to tokens immediately.

Step 3: Implement tokenization APIs in checkout Your checkout flow should never return or log a raw PAN. Aggregator SDKs (Razorpay’s Checkout.js, PayU’s PayU.js) handle tokenization client-side before any data touches your servers. If you built a custom integration that passes card numbers to your server before forwarding to the acquirer, this architecture must change.

Step 4: Implement e-mandate registration for recurring flows If you run subscriptions or EMI products in India, map your recurring charge logic to the e-mandate framework. Test the 24-hour pre-debit notification flow explicitly — this is the most common compliance gap among subscription operators entering India.

Step 5: Build token lifecycle management Implement handling for token invalidation events. Your aggregator should expose webhook callbacks for card re-issuance or token expiry. When received, trigger a re-tokenization request at the next customer interaction.

What This Means for Operators

India’s tokenization mandate is now mature enough that compliance is table stakes — acquirers and card networks will reject authorizations from non-compliant integrations. The operational burden has shifted from “how do we comply?” to “how do we maintain compliance as the infrastructure evolves?”

The recurring payments edge case is where most operators encounter ongoing friction. The e-mandate registration flow, the pre-debit notification requirement, and the INR 15,000 AFA threshold create a more complex recurring billing architecture than most markets require. Operators who underinvest in this architecture see elevated decline rates on recurring charges and customer churn from failed payments.

RuPay-specific tokenization is the least mature part of the ecosystem. RuPay’s domestic issuance has grown to 60%+ of cards issued in India by volume — driven by Jan Dhan Yojana financial inclusion accounts and government-mandated issuance. Operators with significant lower-income or rural customer segments will encounter RuPay as frequently as Visa/Mastercard. Confirm that your PA has active RuPay TR registration, not just Visa and Mastercard.

The longer-term trajectory is toward device-level tokenization (push provisioning to mobile wallets, which India is implementing via the RBI’s token-based card issuance framework) — but for 2026, the card-on-file tokenization mandate is the compliance reality every India card operator must build around.