Key takeaways
- A bot or a bored teenager can place a COD order with a fake 10-digit number in two seconds. OTP kills that instantly.
- Every OTP screen adds friction. On genuine prepaid traffic it can shave 2-4% off conversion, so do not blanket-apply it.
- WhatsApp-first OTP from your own number lands faster and cheaper than SMS, with SMS as the fallback for people not on WhatsApp.
- Best setup: OTP only on high-risk COD orders (new number, RTO-prone pincode, high cart value), not on trusted repeat prepaid buyers.
- Under DPDP, before you reveal a saved address on a returning customer's phone, an OTP is your consent + verification step. It is a privacy feature, not just anti-fraud.
A brand I was helping last Diwali had a weird spike: 40 COD orders overnight from one Shopify store, all going to different pincodes, all with phone numbers that looked fine on paper. Every single one bounced at the RTO stage because the numbers were junk. Someone had pointed a script at their checkout. One toggle would have stopped all of it: OTP on the phone field.
OTP verification at checkout is boring, unglamorous, and one of the highest-ROI things you can do to a COD-heavy Indian store. But it is also the toggle most people either ignore or abuse. Let me walk through when it earns its keep and when it just costs you sales.
What an OTP actually stops
When a buyer types their mobile number, you send a one-time code to that number and make them enter it back before the order goes through. Simple. Three specific problems it solves, and they are not the same problem.
- Bots and scripts. Automated junk orders cannot receive an OTP on a number they made up. This is the big one for anyone running ads at scale.
- Wrong numbers, honest mistakes. A real customer fat-fingers 98765 43210 into 98765 43201. No OTP means your delivery partner calls a stranger and the parcel comes back RTO. OTP catches the typo at the door.
- Casual fake COD orders. The 'let me order and decide later' crowd who put in half-real details. If they will not verify a phone, they were never going to accept the parcel.
That middle one is underrated. A big chunk of RTO in India is not fraud at all, it is unreachable customers because the number was wrong. Fixing the number at checkout is cheaper than any courier-side NDR chase. We go deep on this in reducing RTO on COD orders.
The conversion trade-off nobody admits
Here is the part the OTP vendors skip. Every extra step in checkout leaks buyers. An OTP screen is a real step. On genuine, warm, prepaid traffic I have seen it cost 2-4% of conversions, because a paying customer sitting on a slow 3G connection in Nagpur waits 20 seconds for a code, gets impatient, and bails.
So the honest framing is: OTP has a cost. You are trading a bit of top-line conversion for a lot less RTO and fraud downstream. On a COD order that trade is almost always worth it. On a prepaid order from a repeat customer, it usually is not, because the payment already proved the phone is theirs in spirit and money is already collected.
WhatsApp-first OTP, SMS as backup
The delivery channel matters more than people think. Classic SMS OTP in India is slow, sometimes stuck in operator queues for 30-60 seconds, and DLT template approvals are a headache. WhatsApp changed the math.
Sending the OTP over WhatsApp from your own approved business number has three advantages: it lands in a second or two, the customer already trusts that green tick, and it costs a fraction of transactional SMS. Because the code arrives from the brand they just bought from, open rates are near total. If you are not already sending from your own number, read setting up WhatsApp automation on Shopify.
But not everyone is on WhatsApp, and not every number the buyer typed is a WhatsApp number. So the smart pattern is a fallback chain.
- Try WhatsApp OTP first from your business number. Most buyers get it instantly.
- If WhatsApp delivery fails or times out after ~15-20 seconds, auto-fall back to SMS OTP on the same number.
- Give a 'resend' option and a 'call me the code' option for the stubborn 1% on a bad network.
- Cap attempts at 3-4 so a bot cannot brute-force the code, then soft-lock for a few minutes.
This way genuine buyers on WhatsApp fly through, buyers on a basic phone still get verified over SMS, and you are not paying SMS rates for 90% of your traffic.
When to turn it on: risk-based, not blanket
This is where most stores get it wrong. They flip OTP on for the entire checkout, watch conversion dip, panic, and turn it off completely, keeping the fraud. The right answer is in between: show OTP only when the order looks risky.
If your checkout has an order-level risk score, you gate on it. A first-time buyer, brand-new phone number, high cart value, going COD to a pincode with a bad RTO history? Show the OTP. A repeat customer, known-good number, prepaid, low value? Wave them through. We break down the scoring logic in RTO risk scoring for orders.
| Order profile | Payment | OTP decision |
|---|---|---|
| New number, high-RTO pincode, high value | COD | Yes, always |
| First-time buyer, average value | COD | Yes |
| Repeat customer, known-good number | COD | Optional / skip |
| Any customer | Prepaid (paid) | Skip |
| Bulk / suspicious pattern (many orders, one IP) | COD | Yes, mandatory |
The point is proportionality. You accept a small conversion cost exactly where the fraud and RTO risk lives, and you leave your best customers alone. This is the same philosophy behind COD fraud detection in general: filter the risky, do not tax the loyal.
The privacy and DPDP angle for saved addresses
There is a second, quieter reason OTP matters now, and it is about privacy, not fraud. If your checkout speeds things up by recognising a returning customer's phone and pre-filling their saved address (the address autofill pattern), you are about to reveal someone's home address on the say-so of a typed phone number.
Under India's DPDP Act, personal data like a home address deserves protection. Anyone could type a stranger's mobile number and see where they live. That is a real leak. The clean fix is: before you reveal a saved address tied to a number, verify with an OTP that the person holding the phone is the person you are showing data to.
So OTP does double duty here. It confirms the number is reachable and real (anti-fraud), and it confirms the person is entitled to see the saved profile (consent and privacy). One code, two problems solved. For a cross-store identity network especially, this verification step is non-negotiable.
Common mistakes I see
- OTP on the last step instead of the phone field. Verify the phone right after they type it, so the rest of the form only fills for a verified number. Verifying at 'Place Order' means they did all the work and then hit a wall.
- Only SMS, no WhatsApp. Slow codes are abandoned codes. WhatsApp-first fixes most timeout drop-off.
- OTP on everything forever. You will bleed conversion on good traffic and eventually turn it off. Go risk-based instead.
- No fallback. If WhatsApp fails and there is no SMS backup, a genuine non-WhatsApp buyer is simply blocked. Always have the chain.
Add smart OTP to your checkout in one toggle
Kwikfy's one-page checkout does risk-based OTP over your own WhatsApp number with SMS fallback, so you stop fake COD orders without taxing real buyers.
Start Free →OTP is not a growth hack and it is not a silver bullet. It is a filter with a known cost. Used bluntly it hurts. Used with a bit of judgment, on the orders that actually carry risk, delivered over the channel your customer already trusts, it quietly removes a whole category of RTO and fraud from your day. That is worth a toggle.