Sending every OTP over SMS is the most expensive, least reliable way to verify an Indian phone number in 2026. Sending every OTP over WhatsApp is cheaper and converts better — until you hit the user who simply doesn't have WhatsApp, and your login flow dead-ends. The right answer is neither channel alone. It is WhatsApp-first with an automatic SMS fallback: try the cheap, high-converting channel first, and the moment it doesn't deliver, drop to a DLT-registered SMS without the user noticing. Here is how that actually works, and the honest edges.
Why WhatsApp first
For an Indian consumer app, WhatsApp is the better default channel for three concrete reasons, not vibes:
- It is cheaper. A delivered WhatsApp authentication template costs roughly ₹0.115 in India (Meta's January 2026 rate, before 18% GST). The cheapest mainstream SMS routes start around ₹0.13–0.18 per delivered SMS and climb from there. On the traffic that lands on WhatsApp, you simply pay less per verification.
- It converts better. WhatsApp authentication templates carry a one-tap copy-code button and pair with the platform's autofill, so the user taps once instead of switching apps and retyping six digits. Fewer steps means fewer drop-offs at the exact moment you are trying to log someone in.
- No DLT on the WhatsApp side. WhatsApp Business API messages run on Meta's platform and sit outside TRAI's DLT regime. No Principal Entity registration, no header approval, no template scrubbing on the TRAI side — just Meta's own (faster) template approval. You can ship WhatsApp OTP this week.
The honest catch, stated up front: WhatsApp only reaches users who have WhatsApp. That is near-universal on Indian smartphones, but it is not 100%, and it is zero on feature phones, some dual-SIM secondary numbers, and freshly ported numbers. That gap is precisely what the fallback exists to cover.
What "doesn't deliver" actually means
"Fall back when WhatsApp fails" sounds simple until you ask what counts as a failure. There are really two distinct cases, and a good router treats them differently:
- Not on WhatsApp at all. The number has no WhatsApp account, or the account can't receive your template. This is a fast, deterministic signal — there is no point waiting, you should route to SMS almost immediately.
- On WhatsApp, but undelivered within a window. The message was accepted by Meta but hasn't produced a delivered receipt — phone is off, no data, app not opened, transient platform delay. Here you genuinely don't know yet. You wait a short, bounded window (typically 20–45 seconds) for the delivered receipt, and if it never arrives, you fall back.
The reason the distinction matters is OTP is time-sensitive. A user staring at a verification screen will wait maybe 30–60 seconds before they bounce. So the fallback has to be delivery-aware: react instantly to a hard "not on WhatsApp" signal, but give the soft "pending delivery" case a brief grace window so you don't pay for two messages on every single login.
How a delivery-aware fallback ladder works
A fallback ladder is just an ordered list of channels plus the rules for when to step down each rung. For a typical Indian consumer flow it looks like this:
OTP requested
│
├─▶ Rung 1: WhatsApp authentication template
│ ├─ hard fail (no WhatsApp / template undeliverable)
│ │ └─▶ step down immediately
│ ├─ no "delivered" receipt within ~30s window
│ │ └─▶ step down
│ └─ delivered ✓ → done (user verifies on WhatsApp)
│
├─▶ Rung 2: SMS via DLT-registered template + header
│ ├─ submission rejected / no delivery in window
│ │ └─▶ step down
│ └─ delivered ✓ → done
│
└─▶ Rung 3 (optional): Voice OTP
└─ last-resort coverage for the long tailThe key word is per cohort. You don't want one ladder for everyone. The router can remember, per number, what worked last time:
- Known-on-WhatsApp users stay on the WhatsApp-first ladder — that is the majority of your traffic and your cheapest cohort.
- Known-not-on-WhatsApp users can skip Rung 1 entirely and go straight to SMS. There is no point paying the latency of a WhatsApp attempt that you already know will fail.
- New / unknown numbers run the full ladder once and the result gets cached for next time.
This is the difference between a naive "always try WhatsApp, then SMS" rule and a real router: the naive version wastes a WhatsApp attempt and ~30 seconds on every feature-phone user, every time. The cohort-aware version pays that cost only once.
The cost and conversion math
The intuition people get wrong: they assume fallback means "paying for two messages," so it must be more expensive than SMS-only. It is the opposite, because the fallback fires on a small minority of traffic. Take a realistic split of one lakh (100,000) OTPs/month where ~90% of numbers are reachable on WhatsApp:
Scenario Per-OTP avg 100k OTPs/month (ex-GST)
──────────────────────────────────────────────────────────────────
SMS only (~₹0.16) ₹0.16 ₹16,000
WhatsApp only ₹0.115 ₹11,500 (but ~10% never
get verified — lost logins)
WhatsApp-first + 0.90 × ₹0.115
SMS fallback + 0.10 × ₹0.16 ₹10,350 + ₹1,600
+ small overlap* ≈ ₹12,500 incl. overlap
──────────────────────────────────────────────────────────────────
* "overlap" = the few WhatsApp sends that don't deliver in-window
and still trigger a paid SMS. Tuning the window keeps this small.So the fallback ladder lands close to WhatsApp-only economics while still verifying the 10% who aren't on WhatsApp. Those numbers are illustrative — your real WhatsApp-reachable percentage and the size of the overlap depend on your user base and how aggressive your delivery window is — but the shape holds: you capture WhatsApp pricing on the bulk of traffic and pay the SMS premium only on the genuine long tail.
And the conversion side is the part that doesn't show on the rate card. WhatsApp-only quietly loses the ~10% who can't receive it — those are abandoned signups and failed logins, which cost far more than ₹0.16. The fallback turns those into completed verifications.
SMS still needs DLT — that does not change
One thing the fallback design does not let you escape: the moment a message drops to the SMS rung, it is a real Indian SMS and it is fully inside TRAI's DLT regime. That means, on the SMS side, you still need:
- A registered Principal Entity on a DLT portal.
- An approved sender header (the 6-character transactional ID) — required to reach DND numbers at all.
- A registered content template whose variable structure matches what you actually send, or the message gets scrubbed and silently dropped.
This is the asymmetry of the whole pattern: WhatsApp is DLT-free, SMS is not. So a WhatsApp-first design lets DLT cover only the fallback slice of traffic, but it does not remove the DLT requirement. If you skip DLT registration thinking "WhatsApp handles everything," your fallback rung will fail exactly when you need it most — for the users who aren't on WhatsApp. (Our DLT registration guide walks through entity, header and template setup.)
Where QuickAuth fits
Building this yourself means a WhatsApp Business API integration, a DLT-registered SMS route, a delivery-receipt listener, a per-number cohort cache, and a bounded fallback timer — then keeping all of it tuned. QuickAuth ships it as one thing:
- WhatsApp-first OTP on an authentication template, with one-tap copy-code and auto-read OTP support on the client.
- Automatic SMS fallback on a DLT-registered template and header — DLT handled on our side — triggered by real delivery signals, not a blind timer.
- Delivery-aware routing per cohort, so known not-on-WhatsApp numbers skip straight to SMS and you don't pay for wasted attempts.
- One API, one dashboard, one INR invoice across both channels.
You don't pick a channel per request. You set the fallback order once, and each OTP routes to the cheapest channel that will actually deliver to that specific number. See the authentication API, or read the deeper WhatsApp OTP vs SMS OTP comparison.
Bottom line
Default to WhatsApp for OTP — it is cheaper, converts better and needs no DLT — but never run it alone. A delivery-aware SMS fallback turns WhatsApp's one real weakness (users who aren't on the app) into a non-issue, captures WhatsApp economics on the bulk of your traffic, and recovers the long-tail logins that a WhatsApp-only setup quietly loses. Just remember the SMS rung is still DLT-bound — set that up once, and the ladder does the rest.