The Death of OTP: How Passkeys Will Redefine Payments in India

You get a call. The person on the other end already knows your name, the last four digits of your card, maybe even your last transaction amount. They just need one thing — "the six-digit OTP we just sent you, sir, for verification." Forty seconds later, ₹68,000 is gone.

The OTP didn't fail you. The idea of a one-time code is actually fine. What failed is everything around it — the phone network it travels on, the human on the other end who reads it out, the assumption that a six-digit number sent over SMS is somehow a robust gate between a fraudster and your life savings.

Here's the thing nobody says loudly enough: OTP was always a patch job. It plugged a gap fast enough, at a scale that worked, and India's payments revolution rode on it. But that bill is now coming due — in fraud losses, in regulatory urgency, and in a technology that's finally ready to replace it properly.

That technology is called passkeys. And the RBI just made it mandatory.

When Did OTP Become the Bad Guy?

SMS OTP was born out of a sensible instinct. When Indian banks started moving online, adding a second layer — something beyond your password — was the right call. Your phone number became that second factor. It was universal, required no new hardware, and worked across every phone from a ₹800 Nokia to a Samsung flagship.

The problem isn't that OTP is wrong. The problem is that it's shareable. A six-digit code is just information. You can speak it, type it into a fake website, have it lifted off a network it was never designed to be secure on. There's nothing physical about it, nothing tied to you as a person — which means there's nothing stopping someone else from using it if they get their hands on it.

India's digital fraud numbers tell that story plainly. Fraud cases on the National Cyber Crime Reporting Portal went from 2.6 lakh in 2021 to 28 lakh by 2025. The money lost jumped from ₹551 crore to nearly ₹22,931 crore in the same window. That's not a few bad actors — that's a systematic failure of the authentication layer that most of the country relies on to move money.

The RBI noticed. And in September 2025, it acted.

Two Different Problems — Don't Mix Them Up

Before getting into the fix, it's worth being precise about the problem — because OTP isn't actually a single problem. It shows up differently depending on whether you're talking about an online card payment or a UPI transfer. And conflating the two leads to half-measures.

The eCOM problem: OTP as the transaction lock

When you pay for something online with your debit or credit card — booking flights, buying on Meesho, paying an insurance premium — your bank sends an OTP to your phone via SMS. That OTP is the last door between the transaction going through and it being blocked. Enter it correctly on the payment page, and the money moves.

This is where OTP is genuinely exposed. The OTP is a shareable, timed code sitting in your SMS inbox. A fake payment page can capture it just as easily as the real one. A call from someone pretending to be your bank can get you to read it out. The code has no idea which website it's being entered on — it just exists, and whoever enters it first wins.

The UPI problem: PIN as the transaction key

UPI is built differently. When you send money via PhonePe, Google Pay, or BHIM, you're not being asked for an OTP — you're entering your UPI PIN, a 4 or 6-digit code you set yourself when linking your bank account. That PIN is the authentication factor for every transaction you make.

OTP does show up in UPI — but earlier in the journey, at the device registration stage, when you're linking a new phone to your account. For day-to-day payments though, the PIN is the thing standing between your money and anyone who gets hold of your unlocked phone.

The PIN is a different kind of problem to the eCOM OTP. It's not a code being intercepted on a network — it's a remembered secret that can be extracted through manipulation or shoulder-surfing, without the attacker needing your device at all. But it's still just a string of digits someone else could use without you.

Why this distinction matters

These are two separate authentication flows with two separate weaknesses. eCOM OTP fails because the code travels over infrastructure that was never meant to carry banking-grade secrets. UPI PIN fails because it's a remembered secret with no physical binding to you — someone can call you, manufacture urgency, and walk away with your PIN without ever touching your device.

Passkeys solve both. But they do it in meaningfully different ways — and understanding that is the key to understanding why this shift is more than a UI refresh.

So What Actually Is a Passkey?

A passkey isn't a new kind of password. It's closer to a digital signature that only your device can produce — and only when you, specifically, authorise it.

When you register a passkey with your bank or payment app, your phone generates two mathematically linked keys. One lives inside the secure chip on your device — never exported, never transmitted, not even accessible to the app sitting on top of it. The other goes to the service you're registering with. Your bank holds it.

When you want to make a payment, the bank sends your device a unique challenge — specific to that transaction, valid only right then. Your device asks you to prove it's you: a fingerprint, a face scan, your device PIN. Once you do that, the secure chip signs the challenge with your private key and sends back the signature. The bank checks it against your public key. If it matches, the payment goes through.

Nothing shareable crosses the network. No code. No secret string anyone could read out on a call or capture on a fake website. The authentication is physically tied to your body and your specific device — which is a fundamentally different security model than anything OTP or PIN can offer.

This is the FIDO2 standard, developed by the FIDO Alliance — whose members include Google, Apple, Microsoft, Visa, Mastercard, and about 250 others. It's not a startup's experimental protocol. It's been deployed at scale globally since 2023.

How Passkeys Fix Both Problems — Differently

Going back to the two-problem framing: passkeys address eCOM and UPI auth in distinct ways, and it's worth walking through both.

Fixing eCOM: replacing the SMS OTP in checkout

For card payments online, the change happens at the 3DS authentication step — that moment when your bank intervenes to confirm it's really you. Today, that looks like an OTP in your inbox. Under passkeys, it looks like a biometric prompt on your banking app. You get a notification, you look at your phone or press your thumb, and the payment is confirmed.

There's no code to intercept because no code is generated. There's no fake page that can capture anything useful — the passkey is cryptographically bound to your bank's actual domain, so a spoofed site gets nothing. For eCOM specifically, this closes a gap that's been costing Indian consumers hundreds of crores a year.

Fixing UPI: replacing the PIN at point of payment

For UPI, passkeys — or rather, device-bound biometric authentication — replace the PIN entry at the moment you approve a transaction. This is exactly what PhonePe launched in February 2026 and what NPCI confirmed would roll out across Google Pay and Paytm. Instead of typing your 4-digit PIN, you touch the fingerprint sensor or let the camera see your face.

The PIN was never the ideal solution for UPI — it was just the most practical one available when UPI launched in 2016. A remembered secret shared across every transaction is fragile by design. Biometric auth tied to your device eliminates that fragility. And because the biometric never leaves your phone, there's nothing to extract, nothing to social-engineer out of you on a call.

Both flows — eCOM and UPI — end up at the same place: a transaction that only you can authorise, from your device, in the moment. But they get there through different layers of the stack, and fintech teams building on either need to think about them separately.

What RBI Actually Said in September 2025

The Authentication Mechanisms for Digital Payment Transactions Directions, 2025 — issued September 25, 2025, effective April 1, 2026 — is the regulatory backbone of all this.

The RBI didn't mandate passkeys by name. It was deliberately technology-neutral. What it said is that one factor of authentication must be dynamically created (generated after the payment is initiated, specific to that transaction, non-reusable) and bound to the device in a way that can't travel over the network and be intercepted. Read that description back and it's a precise technical definition of FIDO2.

SMS OTP isn't banned. But it can no longer stand alone as a sufficient factor — especially for higher-risk transactions. The directions also bring in a risk-based model: lighter auth for small, low-risk payments; stronger verification for anything high-value or flagged as unusual. Sensible design.

For regulated entities — banks, payment aggregators, card networks, UPI apps — the message is clear enough. Build for device-bound authentication or explain why you haven't. The compliance window has passed.

If You're Building a Payment Product

The RBI mandate is a compliance requirement. But it's also, honestly, a better product.

The old eCOM checkout flow: enter card details → wait for OTP → open SMS → switch back to browser → type the code → hope it hasn't expired. Somewhere between 15 and 40 seconds of friction on a good day, longer if the SMS is delayed. Cart abandonment at this step is measurable and painful.

The new flow: card details → biometric prompt → done. Under two seconds.

For UPI, the difference is less dramatic — PIN entry is already fast — but the security gain is significant. A 4-digit PIN that someone can watch you enter once is a different risk profile to a fingerprint.

Technically, the work involves integrating with the WebAuthn API (the web standard that FIDO2 runs on), working with your bank or aggregator on transaction-signing flows, and thinking hard about account recovery. That last one is genuinely the hard part. If a user registers a passkey and then loses their phone, what happens? Banks and apps are still working out the standard answer, and the implementations that get it wrong will create real user trust problems. Don't underscope it.

What's Still Unresolved

Passkeys won't replace OTP everywhere, immediately. There are real constraints.

Feature phone coverage is the biggest. Around 250 million Indians still use devices without biometric sensors or secure hardware chips. OTP will serve that segment for years yet — the RBI's mandate is appropriately scoped to digital payment apps, not a push to cut off anyone who doesn't own a smartphone. But as device penetration grows, the addressable base for passkeys grows with it.

Device recovery needs to be standardised. Passkeys live in hardware. Lose the hardware, and recovery becomes an account management problem. Right now, different banks handle this differently, and a user who's never thought about it — which is most users — will be blindsided when it happens.

Merchant infrastructure on the eCOM side still has gaps. The 3DS/ACS layer that sits between your bank and the merchant's payment gateway is being updated, but the rollout is uneven. A passkey flow is only as smooth as the least-updated link in the chain.

And then there's the hardest one: habit. Indian users have been conditioned for a decade to expect an OTP. "Where's my OTP?" is almost a reflex. Switching that mental model — getting users to trust biometric approval, understand what it means, not panic when no SMS arrives — is a design and communication challenge, not just a technical one.