RBI Tokenisation 2026: What It Means for Flight Bookings

RBI tokenisation explained: saved card rules since July 2022, what tokens mean for OTA flight bookings, security implications.

Fares and prices quoted in this guide are indicative estimates only — illustrative, not live quotes, and may be out of date. Search FlightGPT for current fares before booking.

RBI tokenisation 2026 — what the saved-card framework actually does to your flight bookings on MakeMyTrip, IndiGo and others

By Kabir Malhotra (Kabir Malhotra writes about how Indian travel buyers actually pay — UPI vs credit card vs forex card surcharges, reward-point math on the top travel credit cards, RBI tokenisation, EMI-on-flights and the small fees that compound across a year of bookings.) · Published · Last updated · 10 min read

The RBI's card tokenisation framework, mandatory from July 2022 and continuously expanded since, has quietly transformed how Indian flight booking payments work. Merchants like MakeMyTrip, IndiGo and Air India no longer store your full card number — they store a network-issued token. This is the structured 2026 explainer of what tokenisation is, why it exists, what it changes for the consumer and the failure modes to watch for.

What card tokenisation actually is in plain English

Before October 2022, when you saved a card on MakeMyTrip or any other Indian merchant, the merchant stored the full 16-digit Primary Account Number (PAN), expiry date and a reference to the CVV. This created a single point of compromise — a breach of the merchant's database exposed millions of full card details. The RBI's card storage framework, finalised in 2021 and made mandatory from October 2022, prohibits merchants from storing full PAN. Instead, the card networks (Visa, Mastercard, RuPay, Amex, Diners) issue a token — a network-specific reference number that maps back to the underlying card but is useless if compromised in isolation.

The token is issued by the card network and shared with the merchant. The token typically begins with the same first six digits as the underlying card (the BIN, which identifies the issuer) but the remaining digits are network-generated and meaningless outside the network's mapping system. The token can be used for repeat transactions, recurring payments and saved-card flows just like the original card. The merchant never sees or stores the actual PAN.

For a flight booker, this means that when you save your HDFC Diners card on MakeMyTrip in 2026, MakeMyTrip stores something like 5240810000123456 (the token, with the HDFC Diners BIN at the front and the rest network-generated) rather than your actual card number. The next time you book, you see "Card ending in 7890" but MakeMyTrip is actually sending the token to the network, which decrypts it back to your actual card details and processes the transaction. For payment-side context see UPI for flight bookings.

The phased rollout — what changed from 2021 to 2026

The tokenisation timeline matters because it shapes the present state. RBI first issued the directive in March 2021, with an initial deadline of January 2022. After industry feedback that integration was incomplete, the deadline was extended to July 2022 and then to October 2022 for full enforcement. Through Q4 2022 and 2023, merchants progressively re-tokenised their saved-card vaults, and by 2024 the framework was fully operational across the major OTAs and airlines.

The 2024-2026 expansions extended tokenisation to several adjacent areas. Network-issued tokens were extended to card-on-file scenarios for subscription services. The Card-on-File (CoF) tokenisation rules were tightened to cover all merchant types including travel. The RBI also rolled out the Card-on-File Token (CoFT) service through issuing banks, which allows users to manage their tokens across merchants from a single bank app. By 2026, a power user can see and manage all their cards-saved-with-merchants from the HDFC mobile app or the Axis app, and revoke a token if a particular merchant is no longer trusted.

The latest 2025-2026 development is the extension of tokenisation to wallet-issued cards and to international merchants serving Indian customers. Indian flight bookings on foreign-incorporated merchants (Booking.com, Agoda, Expedia) now follow tokenisation when paid via Indian-issued cards. The framework continues to evolve, but the core principle — merchants don't store full PAN — is now universal across Indian flight booking payments.

What changes for the consumer at booking time

The consumer-facing experience for flight bookings post-tokenisation is mostly the same as before, with a few specific differences. When you save a card on MakeMyTrip, Yatra, IndiGo or any major Indian airline website in 2026, the merchant displays a one-time consent screen explaining that the network token will be saved. You agree, complete a 3D-Secure step to validate card ownership, and the token is created. From that point onward, the saved-card display shows the masked card number ("Card ending in 7890") and you enter only the CVV at each subsequent transaction.

The 3D-Secure flow still happens for each transaction on top of the saved-token convenience. Tokenisation does not remove the Additional Factor of Authentication requirement — RBI still requires AFA (typically OTP) for online card transactions over ₹2,000 or for recurring transactions. So a saved card on MakeMyTrip in 2026 still requires CVV plus OTP for each booking, but you don't need to type the 16-digit card number again.

For repeat transactions on the same merchant, the saved-token flow is genuinely faster — typically 15-30 seconds of total payment time versus 45-90 seconds for a fresh-card-entry transaction. For one-time bookings on a new merchant where you don't want to save the card, the option to "don't save card" exists at each merchant, and the transaction completes normally with the card details processed but not stored.

Security implications — what tokenisation does and does not protect against

Tokenisation materially reduces the impact of merchant-side data breaches. If MakeMyTrip's customer database is compromised in some future incident, the saved-card vault contains tokens only — useless to an attacker without access to the network's token-to-PAN mapping, which is held by the card network and is heavily protected. This was a real concern pre-2022 because Indian e-commerce platforms had repeatedly suffered card data leaks. Post-tokenisation, the same breach would expose tokens but not card details.

What tokenisation does not protect against: phishing attacks where users are tricked into entering their actual card details on a fake site, card-skimming attacks during physical use, account takeover attacks where the attacker gains access to the user's merchant account (not the card data) and uses the saved token to make purchases. The token is bound to the merchant — an attacker who steals one merchant's token cannot use it elsewhere. But within the compromised merchant's environment, the token works like the card.

For flight bookings specifically, the risk-reduction value of tokenisation is real but the user-side discipline still matters. Don't save cards on merchants you don't trust, use strong unique passwords on OTA accounts, enable two-factor authentication where offered, and review your card statement regularly for unauthorised transactions. The tokenisation framework is a structural safety net but is not a substitute for basic security hygiene.

Re-tokenisation when your card is renewed or replaced

One of the operational quirks of tokenisation is re-tokenisation when your underlying card changes. When your HDFC Diners card expires and HDFC issues a new card with the same number but updated expiry, the existing tokens at MakeMyTrip, IndiGo etc. typically update automatically via the network's token-lifecycle-management service. The user does not need to do anything.

When your card is replaced with a new number — for example, a lost-card replacement that comes with a new PAN — the existing tokens become invalid. The next time you try to use the saved card on a merchant, the transaction fails and you need to re-save the new card. The merchants handle this gracefully in 2026 with a "this card needs to be re-saved" prompt during checkout, but it interrupts the flow. The same happens when you upgrade your card to a new product (HDFC Regalia to HDFC Diners Black, for example).

The CoFT (Card-on-File Token) service via issuer banks helps here. Through your HDFC or Axis mobile app you can see which merchants have your card tokens, and during card replacement the issuer can proactively re-tokenise across all merchants. This is still emerging functionality — not all issuers support it for all merchants — but it is the direction the framework is heading. For most users in 2026 the practical experience is that card renewal is invisible, card replacement requires re-saving on each merchant.

Tokenisation and recurring travel subscriptions

The tokenisation framework intersects with the RBI's e-mandate framework for recurring payments. For one-time flight bookings, tokenisation works as described above — the card token is saved, you enter CVV plus OTP per transaction. For recurring travel subscriptions (MMT Black auto-renewal, IndiGo's 6E Prime annual subscription, the various airline lounge-pass memberships), the e-mandate framework applies — the user provides a one-time consent for the merchant to charge up to a specified amount on a recurring schedule, without explicit OTP per transaction.

The e-mandate framework was tightened in 2022 with the per-transaction AFA exemption threshold capped at ₹15,000 (raised to ₹1,00,000 in late 2024 for specific high-trust merchants). For typical travel subscriptions, which are usually ₹500-3,999 per year, the e-mandate flow is smooth — provide consent once at signup, the merchant charges your tokenised card automatically each year, you receive a notification ahead of each charge.

The user can cancel an e-mandate at any time via the merchant's app or via the bank's e-mandate-management portal. The bank-side cancellation works as a fail-safe if the merchant's cancellation flow is broken. RBI mandates 24-hour advance notification before each recurring charge, so you have visibility into what's being charged and can cancel before the next cycle if desired. For MMT Black specifically, see MakeMyTrip 2026 review.

Edge cases — international cards, virtual cards, and corporate cards

International-issued cards (foreign-bank-issued cards used by Indian customers, typically for international students, NRIs or travellers with foreign-bank cards) follow a different framework. The RBI tokenisation requirement applies to Indian-issued cards regardless of where used, but does not apply to foreign-issued cards used at Indian merchants. So an HSBC UK card used on MakeMyTrip is not tokenised under the Indian framework, though it may be tokenised under the issuer's own framework or under EMVCo standards.

Virtual cards — single-use card numbers generated by services like HDFC NetSafe or by neo-banking apps — are a different case. Virtual cards by their nature are short-lived (sometimes single-use) and tokenisation provides limited additional benefit. Most virtual card services do not integrate with the saved-card tokenisation flow; instead they expect to be used as one-time card numbers. For flight bookings where you specifically want privacy or want to control merchant access, a virtual card is a complementary tool to tokenisation rather than a replacement.

Corporate cards (HDFC Corporate, ICICI Business, SBI Corporate) follow tokenisation the same way as personal cards when used on consumer merchants. The corporate-card holder can save the card on a corporate-travel platform (Yatra for Business, MMT for Business) and the token is created normally. The corporate-card management portal usually allows the cardholder-administrator to revoke saved cards across merchants if the cardholder leaves the company, which is a useful security control.

What to expect from tokenisation in 2027 and beyond

The tokenisation framework is mature in 2026 but continues to evolve. The expected 2026-2028 developments include: full extension of CoFT management to all major issuer banks, with a unified consumer interface for managing tokens across merchants; tokenisation of international card payments on Indian merchants for inbound foreign tourists; tighter integration with the e-mandate framework so subscription cancellation is one-click via the issuer app; and progressive elimination of the legacy "card on file at merchant" model for the remaining smaller merchants who have not fully migrated.

The longer-term direction is toward a state where the consumer never sees or types a card number outside of the initial card-issuance moment. The card lives in the issuer's vault, is tokenised per merchant on demand, and is managed via the issuer's app. The merchant deals only in tokens, the network handles the mapping, and the user authenticates each transaction via 3D-Secure or via a biometric authentication on the issuer app. This model is operational for some sophisticated users in 2026 and will likely become the norm by 2028.

For Indian flight booking specifically, the result is that the payment experience continues to get safer, faster and more transparent. The 5-10 second time saved per booking by saved-card-via-token flow compounds across the dozens of flight bookings a frequent flyer makes per year. The security improvement from removing full-PAN-at-merchant is structural and protects against breach scenarios that have hit other markets. The Indian payment infrastructure post-tokenisation is genuinely a global benchmark — many international markets are now adopting similar frameworks.

Frequently asked questions

When did RBI's card tokenisation become mandatory for Indian merchants?

The RBI's card-on-file tokenisation framework was first directed in March 2021, with an initial deadline of January 2022. After industry feedback, the deadline was extended to July 2022 and then to October 2022 for full enforcement. Through Q4 2022 and 2023, merchants like MakeMyTrip, IndiGo, Air India and the major Indian OTAs progressively re-tokenised their saved-card vaults. By early 2024 the framework was fully operational across the major Indian payment ecosystem and merchants could no longer store full Primary Account Numbers (PAN).

Does tokenisation mean my saved cards on MakeMyTrip are safer in 2026?

Yes, materially. Pre-tokenisation, MakeMyTrip and similar merchants stored your full 16-digit card number, which created a single point of compromise. If their database was breached, full card details would leak. Post-tokenisation, MakeMyTrip stores only a network-issued token that is useless outside the card network's mapping system. A future breach of MakeMyTrip's customer database would expose tokens but not actual card details. This is a structural security improvement that protects against the kind of breach scenarios that have affected Indian e-commerce in earlier years.

What happens to my saved cards on flight booking sites when my card is renewed?

When your card is renewed with the same number but updated expiry (typical at end of card validity period), the saved-card tokens at MakeMyTrip, IndiGo and other merchants typically update automatically via the network's token-lifecycle-management service. You don't need to do anything. When your card is replaced with a new number (lost card, upgrade to new product), the existing tokens become invalid and you'll need to re-save the new card on each merchant the next time you book. The merchants handle this gracefully with a re-save prompt during checkout.

Do I still need to enter OTP for saved-card flight bookings on IndiGo or Air India?

Yes. Tokenisation removes the need to re-enter the full 16-digit card number but does not remove the Additional Factor of Authentication (AFA) requirement. RBI rules require OTP (or other AFA mechanism like biometric authentication via issuer app) for online card transactions over ₹2,000. So a saved card on goindigo.in or airindia.com in 2026 still requires CVV plus OTP for each booking. The saved-card-via-token flow is faster because you don't need to type the 16-digit number, but the authentication step is preserved for security.

Can I see and manage which Indian flight booking sites have saved my card?

Yes, increasingly. The RBI's CoFT (Card-on-File Token) service rolled out through issuer banks in 2024-2026 allows you to see which merchants have your card tokens, via your bank's mobile app. HDFC, Axis and ICICI have full CoFT management interfaces in 2026 where you can view tokens at MakeMyTrip, Yatra, IndiGo, Air India and other merchants, and revoke any token you no longer want. This is still emerging functionality — not all issuers support it for all merchants — but it is the direction the framework is heading.

Does tokenisation apply to my international card used on Indian flight booking sites?

No, the RBI tokenisation framework applies to Indian-issued cards regardless of where used. Foreign-issued cards (HSBC UK, Chase USA, etc.) used at Indian merchants are not tokenised under the Indian framework. They may be tokenised under the card issuer's own framework or under EMVCo standards, but this is the issuer's choice rather than an Indian regulatory requirement. For NRIs using foreign-bank cards on MakeMyTrip or IndiGo, the saved-card experience may differ from the Indian-card tokenised experience.

What is the difference between RBI tokenisation and 3D-Secure?

They solve different problems. Tokenisation protects the card data at rest at the merchant — what the merchant stores in their database. 3D-Secure protects the card during a transaction by adding an authentication step (typically OTP) before the transaction completes. Tokenisation reduces the impact of merchant-side breach. 3D-Secure reduces the risk of unauthorised transactions even if the card details are known. Both apply to Indian flight booking payments in 2026 — tokenisation for saved cards, 3D-Secure for transaction authentication. They are complementary safety mechanisms.

Can I opt out of saving my card as a token on Indian flight booking sites?

Yes. Every Indian merchant supporting saved-card functionality in 2026 also offers a 'do not save card' option at the payment page. If you select this, the merchant processes the transaction with your card details but does not save the token for future use. For one-time bookings on merchants you don't expect to use again, this is a reasonable choice. For frequent-use merchants, the saved-token flow is meaningfully faster and the security risk is materially lower than pre-tokenisation, so saving the card is generally a good trade-off in 2026.