The OTP Is Where Your Orders Die
The customer chose the food, filled the cart and tapped pay. Then you asked them to leave your screen and prove they exist. Here is what that step costs.
Watch somebody order food on their phone and pay attention to the exact moment their face changes.
It is not the price. It is not the delivery estimate. It is the screen that says: enter the six digit code sent to your number.
Because now they have to leave. Out of your ordering page, into the SMS app, wait, find the message, memorize six digits, switch back, and hope the page has not reloaded. Somewhere in that thirty seconds a WhatsApp notification arrives, or the code does not, or the signal drops, or they simply put the phone down.
They had already decided. They had already chosen the biryani. The order was yours.
Then you asked them to prove they exist.
Every step between wanting and paying leaks
The Indian checkout data on this is not subtle.
Razorpay's analysis of mobile checkouts in India puts forced account creation behind roughly 26 percent of all drop offs, and other estimates run as high as 35 percent when shoppers are made to register before buying. Every additional form field cuts completion by another 4 to 6 percent. Between the start of checkout and the payment screen, Indian stores lose somewhere between 25 and 40 percent of the people who got that far.
And the OTP has its own failure mode on top of the ordinary friction. Message Central's 2026 analysis of Indian e-commerce found that around 1 to 2 percent of users abandon at the OTP step through reluctance alone, but that checkout abandonment caused by OTP delivery failure costs 8 to 15 percent of conversions for higher value merchants.
Read that second number properly. That is not people changing their minds. That is a customer who wanted to pay you, being blocked by an SMS that did not arrive, because of a carrier delay, a DND filter, or patchy signal in a tier two city.
You lost the order to infrastructure sitting between you and somebody who had already said yes.
Why the OTP exists, honestly
It would be easy to write this as though OTPs are a stupid idea somebody imposed on Indian commerce for no reason. They are not, and pretending otherwise makes the argument weaker.
An OTP answers one specific question: does the person placing this order actually control this phone number?
That question matters enormously when you do not know who is ordering. The same Message Central work found OTP verification cuts cash on delivery return fraud by 25 to 40 percent and fake account signups by 50 to 70 percent. For a business taking COD orders from strangers, that is not bureaucracy, it is the difference between a channel that works and one that gets abused.
So the OTP is not the villain. It is a reasonable answer to a real question.
The interesting part is what happens when that question has already been answered.
On WhatsApp, the verification already happened
A WhatsApp account is bound to a phone number at the moment it is created. Meta verifies control of that number before the account exists at all, and the number is the account.
Which means when a customer messages your restaurant on WhatsApp, the thing an OTP is designed to prove has already been proven. Not by you, and not just now, but proven all the same, by the platform, at registration, and reconfirmed every time that person sets up a new device.
Asking them for an OTP at checkout is asking them to verify a verification.
That is the whole argument, and once you see it, most Indian ordering flows start to look strange. The message came from a verified number. The order came from a verified number. The status updates go back to a verified number. And somewhere in the middle, the flow stops and demands a six digit code to establish something the channel established months ago.
The other thing an OTP costs you: a context switch
There is a second cost that has nothing to do with verification and it may be larger.
Every OTP forces the customer out of the surface they were buying on and into a different app.
Razorpay's payment data makes the point better than any argument could. UPI Intent Flow, where the customer is passed directly into their payment app, reaches roughly 98 percent success. Collect Flow, which requires the customer to switch context and go find the request themselves, performs considerably worse. Same customer, same intent, same money. The only variable is whether they had to leave.
Context switching is where Indian mobile checkouts lose people. It is why one page checkouts reduce abandonment by around 20 percent, and why the standard advice is to strip fields rather than reorganise them.
An OTP is a mandatory context switch inserted at the single worst moment in the entire flow, which is after the customer has committed and before you have their money.
Count the steps
Line the three routes up by what a person has to do before they can eat.
Your own app: find it in the store, download it, wait, open it, register, receive an OTP, enter it, browse, add to cart, enter an address, choose payment, possibly a second OTP.
Your website: find or remember the URL, load it, browse, add to cart, enter a phone number, wait for an OTP, enter it, add an address, pay.
WhatsApp: send Hi, tap the link, choose the food, pay.
No download. No signup. No password to have forgotten. No OTP. Nothing to leave and come back from.
The difference between those flows is not features. It is the number of moments at which a hungry person can be interrupted, and each one of those moments has a measurable failure rate attached.
What you give up, and how to cover it
Removing the OTP does mean giving something up, and any vendor who tells you otherwise is not being straight.
You lose a verification checkpoint that was doing real work on cash on delivery fraud. That risk is genuine, particularly for first time customers ordering COD to an address you have never delivered to.
Three things cover most of it.
The number is still verified, just upstream. You know the WhatsApp number is real and controlled by the person messaging you. What you cannot verify is their intent, which an OTP never checked either.
Repeat customers self verify through history. Somebody on their fourth order from the same number, to the same address, is not a fraud risk in any meaningful sense, and the conversation itself is the record.
And you can still require prepayment where the risk sits. Prepaid for first time COD orders above a threshold, or for new numbers ordering to unfamiliar addresses. That targets the actual exposure instead of taxing every customer to cover a small minority.
The mistake is applying a blanket verification step to a hundred percent of orders to manage a risk that lives in maybe two percent of them.
The bottom line
The industry's response to checkout friction has been to make the friction faster. Auto read SMS permissions. Autofill. Shorter codes. Multi channel fallback so that when the SMS fails, WhatsApp or a voice call tries next.
All of that is optimisation of a step that, on a channel where identity is already established, does not need to happen.
The best version of a form field is no form field. The best version of a verification step is a channel where verification already occurred.
Your customer chose the food. They filled the cart. They reached for their money.
Do not stop them there to ask who they are. WhatsApp already knows.
Take orders where the number is already verified. Menuthere turns your WhatsApp number into an ordering channel. The customer sends Hi, gets your menu instantly, and orders in a few taps. No app download, no signup, no OTP, and the order lands straight in your POS.
Sources: Razorpay 2026 (Indian mobile checkout drop off, forced account creation, form field impact, UPI Intent Flow success rates), Message Central 2026 (OTP abandonment, OTP delivery failure cost, COD fraud reduction), Cashfree (checkout conversion benchmarks and guest checkout), Digital Applied 2026 (one page checkout impact).