WhatsApp OTP vs SMS OTP in India: Cost and DLT

Ship login in India and you'll wrestle with this early: WhatsApp OTP or SMS OTP? On the surface the two channels look like twins. Send a one-time code, ask the user to type it back. Underneath, they price differently, register differently, and fail differently. So we'll walk real cost ranges, the DLT and TRAI rules behind each, deliverability, setup effort, and a hybrid fallback design so no user ever gets stranded.

NamoID puts both channels behind one OIDC issuer, which makes the choice below a config decision rather than a rebuild. The framing stays practical and vendor-neutral, so it holds whatever you end up using.

Cost per message today

There is no single "price of an OTP" in India. What you pay depends on the channel, the route, your aggregator, your volume tier, and in the case of WhatsApp, the conversation category set by Meta. So treat the ranges below as planning numbers, not quotes. Always confirm current rates with your aggregator before you budget.

For SMS OTP, the cost has two parts: the aggregator fee per message and, in some commercial arrangements, the operator/DLT charges layered on top. Transactional and service-explicit (OTP) SMS in India typically lands in the low single-digit paise to low rupee range per message depending on volume and route. High-volume senders negotiate down; low-volume senders pay more per unit. SMS is billed per message sent, whether or not the user reads it.

For WhatsApp OTP, pricing follows Meta's conversation-based model. Meta moved WhatsApp Business pricing toward per-message pricing for template messages and groups authentication messages into their own category. India has historically been one of the lower-cost markets for WhatsApp authentication templates, but the exact figure changes and is set by Meta, not your aggregator alone. Check Meta's current rate card before you model anything, because this number has been revised more than once. The authoritative source is Meta's own pricing documentation, which you should treat as the single source of truth for the WhatsApp side.

A few cost dynamics that matter more than the headline rate:

• Retries multiply cost. If your first SMS does not deliver and you fall back to a second send, you pay for both. A channel with higher first-attempt delivery is cheaper in practice even at a higher unit price.
• Failed sends can still cost. Depending on the aggregator and channel, a submitted-but-undelivered message may still bill. Read your contract.
• Volume tiers move the needle. Both channels get cheaper per unit as you scale, but the curve differs. Model your real monthly volume, not a single message.

The honest takeaway: do not pick a channel on unit price alone. Pick on delivered cost, which is unit price divided by your real delivery rate, plus the cost of retries.

DLT registration and TRAI rules

This is the part teams underestimate. In India, application-to-person (A2P) SMS is governed by TRAI's commercial communication regulation, and you cannot just send templated SMS from a random sender ID. You must register on a DLT (Distributed Ledger Technology) platform operated by the telecom operators, under TRAI's framework. See TRAI's framework on unsolicited commercial communication for the regulatory basis (trai.gov.in).

For SMS OTP, DLT registration means you register:

1. Entity (PE) registration tied to your business identity.
2. Header / Sender ID registration (the 6-character alphanumeric sender ID).
3. Content templates for every message you send, including your OTP template, with variable placeholders approved in advance.
4. Consent and category classification (transactional, service-explicit, service-implicit, or promotional). OTP usually falls under the service or transactional path.

The practical consequences:

• You cannot change the wording of an OTP message on the fly. The template is registered. If the body does not match a registered template, operators can scrub or block the message.
• Template approval takes time. Plan for days, not minutes, on your first registration.
• Header and template mismatches are a leading cause of "the OTP never arrived" in production.

For WhatsApp OTP, you do not use the TRAI DLT platform. WhatsApp is an over-the-top (OTT) channel, so it sits outside the SMS DLT regime. Instead you register with Meta: a verified WhatsApp Business Account, a message template approved by Meta (authentication category for OTP), and a connected business phone number. The control plane is Meta's, not the operators'. Different gatekeeper, similar discipline: you still pre-register templates and you still cannot freely edit message text at send time.

For the broader rail-selection logic, where OTP fits next to DigiLocker and Aadhaar, see Aadhaar vs DigiLocker vs offline KYC.

Here is the registration difference at a glance:

Deliverability and blocking

Cost is only half the story. A cheap message that does not arrive is the most expensive message you can send, because it costs you the message, the retry, and sometimes the user.

SMS OTP deliverability in India is shaped by:

• DLT scrubbing. Operators scrub messages against registered templates. A mismatch (wrong header, edited text, unregistered template) gets dropped, often silently from your side.
• Operator routing and congestion. International long-code and grey routes are unreliable and increasingly filtered. A proper domestic route via a registered aggregator delivers better.
• Handset and SIM issues. Dual-SIM phones, full inboxes, and DND settings (for promotional, less so for service/OTP) all bite.
• Latency. SMS OTP can arrive in seconds or, on a congested route, after the code has expired. Set your OTP TTL with real-world latency in mind.

WhatsApp OTP deliverability depends on a different set of things:

• The user must have WhatsApp, an internet connection, and the business number not blocked. No data connection means no WhatsApp OTP, period. This is the single biggest gap versus SMS, which works on any phone with signal.
• Quality rating. Meta assigns your number a quality rating. Spammy behavior or high block rates can throttle or restrict your throughput.
• Opt-in. WhatsApp requires the user to have opted in to receive messages from your business. SMS OTP under the service/transactional category has a different consent basis.

When WhatsApp does deliver, it tends to deliver fast and reliably, and the user gets a richer, branded message with a copy-code button. But the "user is offline" failure mode is real, and it is exactly why you should not run WhatsApp as your only channel.

A note on measuring this: track OTP delivery rates per channel and per route as a first-class metric, broken down by operator if you can. You cannot improve what you do not measure, and your aggregator's dashboard and yours will not always agree.

Setup effort: WhatsApp vs SMS

Both channels need pre-registration, but the shape of the work differs.

SMS OTP setup, roughly:

1. Pick a DLT-registered aggregator.
2. Complete entity (PE) registration on a DLT platform.
3. Register your header (sender ID).
4. Register your OTP content template with variable slots.
5. Wait for approvals.
6. Integrate the aggregator's HTTP API and send.

A bare-bones send, once you are registered, looks like an authenticated HTTP call to your aggregator. The exact endpoint and fields are aggregator-specific, so this is illustrative only:

curl -X POST "https://api.your-sms-aggregator.example/v1/send" \
  -H "Authorization: Bearer $SMS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sender": "NAMOID",
    "to": "+9198XXXXXXXX",
    "template_id": "DLT_TEMPLATE_ID",
    "variables": { "otp": "482913" }
  }'

WhatsApp OTP setup, roughly:

1. Create and verify a WhatsApp Business Account with Meta.
2. Connect a business phone number.
3. Submit an authentication-category message template for approval.
4. Capture user opt-in.
5. Integrate the WhatsApp Cloud API (or a Business Solution Provider's API) and send.

A WhatsApp template send via the Cloud API looks roughly like this (illustrative, confirm against Meta's current API docs):

{
  "messaging_product": "whatsapp",
  "to": "9198XXXXXXXX",
  "type": "template",
  "template": {
    "name": "otp_authentication",
    "language": { "code": "en" },
    "components": [
      {
        "type": "body",
        "parameters": [{ "type": "text", "text": "482913" }]
      }
    ]
  }
}

Net effort: SMS has more moving parts on the telecom side (entity, header, template, category) but uses a model your aggregator handles for you. WhatsApp has fewer registrations but a stricter business-verification and opt-in story. Neither is "plug in and go." Budget setup time for both.

NamoID is built so this provider wiring lives behind the issuer. Each channel is a configured OTP provider with its own credentials, and the same OIDC flow drives both. You do not change your app code to switch or add a channel.

Designing a hybrid fallback

Because each channel has a clean failure mode the other covers, the strongest production design is a hybrid: try the channel most likely to deliver cheaply and fast, then fall back. The two common patterns:

Pattern A: WhatsApp first, SMS fallback. Good when most of your users are online and on WhatsApp. You get the cheaper, richer message most of the time, and SMS catches the offline tail.

Pattern B: SMS first, WhatsApp as an alternative. Good when universal reach matters more than message richness, or when a large share of users may not have WhatsApp.

Whichever you pick, a few rules keep it sane:

• One identity, many channels. Treat the OTP as belonging to the user's phone number, not the channel. The same code should verify whether it arrived by WhatsApp or SMS, so a fallback send does not invalidate the first.
• Cap attempts and rate-limit sends. OTP send is a billing-amplification target. An attacker who can trigger unlimited sends runs up your bill and can flood a victim. Rate-limit per phone number and per IP, and cap verification attempts per code.
• Set a realistic TTL. Long enough to survive route latency, short enough to limit replay. Many teams land around five minutes.
• Pick a fallback trigger. Either fall back on a hard delivery failure signal, or after a timeout with no successful verification. Avoid double-sending immediately, since that just doubles cost.
• Log every step as an event. Send, deliver, verify, and fail should each be auditable.

That last point matters for India specifically. Under the DPDP Act, you want a clean record of consent and of each verification step. NamoID's append-only events table records every state change, including OTP send and verify, which gives you a DPDP-grade audit trail without bolting on extra logging. For what that trail needs to contain, see DPDP audit trail requirements for engineers. This is general information, not legal advice; confirm your obligations with qualified counsel.

A simple decision sketch:

// illustrative pseudo-flow, not a real SDK
async function sendOtp(phone: string) {
  const code = generateCode();          // 6 digits
  await store(phone, code, ttlSeconds(300));
 
  const primary = userLikelyOnline(phone) ? "whatsapp" : "sms";
  const ok = await send(primary, phone, code);
 
  if (!ok) {
    const fallback = primary === "whatsapp" ? "sms" : "whatsapp";
    await send(fallback, phone, code); // same code, different channel
  }
}

A recommendation table

There is no universal winner. Match the channel to the situation:

If you only remember one thing: decide on delivered cost and reach, not headline unit price, and run a hybrid so one channel covers the other's gap.

FAQ

Is WhatsApp OTP cheaper than SMS OTP in India?

Often, but not always, and the comparison should be on delivered cost, not unit price. WhatsApp authentication templates have historically priced low in India under Meta's per-message model, while SMS adds DLT and route costs. But SMS reaches users with no data connection, and retries on either channel change the real number. Model your own volume and delivery rates, and confirm current rates with Meta and your aggregator.

Do I need DLT registration for WhatsApp OTP?

No. DLT registration under TRAI applies to A2P SMS sent over telecom operator networks. WhatsApp is an over-the-top channel governed by Meta's WhatsApp Business rules, so you register a business account, a verified number, and an approved authentication template with Meta instead. You still pre-register templates; it is just a different gatekeeper.

What causes OTP delivery failures in India?

For SMS, the top causes are DLT template or header mismatches that get scrubbed, unreliable international or grey routes, and handset or congestion issues. For WhatsApp, the main cause is the user being offline or not having WhatsApp, plus quality-rating throttling and missing opt-in. Tracking OTP delivery rates per channel and route is the only way to see which is hitting you.

Should I use WhatsApp or SMS for OTP?

Run both with a fallback. Use WhatsApp first if your users are mostly online for a cheaper, richer message, and fall back to SMS for the offline tail. If universal reach is the priority, lead with SMS. The same one-time code should verify regardless of channel so the fallback never strands a user.

Where NamoID fits

NamoID is built to put WhatsApp OTP, SMS OTP (on a DLT-compliant template path), email OTP, and India verification rails like DigiLocker and Aadhaar offline e-KYC behind a single OIDC issuer, with PKCE-enforced OAuth 2.1, rotating refresh tokens, and an append-only audit trail for DPDP. The channel choice above becomes configuration, and every send and verify is logged for you.

If you are weighing channels for a launch in India, book a 30-minute walkthrough at calendly.com/polymindslabs/30min or reach us at hello@namoid.in. We are happy to talk through your specific volume and reach before you commit to a vendor.