WhatsApp OTP vs SMS OTP in India: An Honest Comparison (2026)

If you send one-time passwords (OTPs) to users in India, you have two mainstream channels: SMS through a DLT-registered sender, and WhatsApp through an authentication template on Meta's Cloud API. Neither wins in every situation; the right choice depends on your users, your volume and how much setup you can take on.

• Setup: WhatsApp needs no DLT registration, only user opt-in and an approved authentication template, and PayPerWA charges no subscription or setup fee. SMS needs DLT entity, header, template and message-path registration, with a fee paid to the operator.
• Cost: at published list prices, Indian SMS aggregators charge less per OTP than WhatsApp through PayPerWA (Meta ₹0.115 + PayPerWA ₹0.20), but SMS adds a DLT registration fee.
• Experience: WhatsApp offers a Copy Code button and keyboard suggestions on iOS 26 and later; Meta's Android autofill (one-tap and zero-tap) needs app integration and is not offered by PayPerWA. SMS codes can be autofilled through Google's SMS Retriever and SMS User Consent APIs on Android and through security code AutoFill on iPhone.
• Reach: SMS reaches any phone with a working SIM; WhatsApp reaches only people who use WhatsApp on that number.
• Reliability: the two channels fail in different ways, which is the best argument for offering both.

This post is part of our WhatsApp OTP series; for build steps, start with the WhatsApp OTP API guide for India, or see how PayPerWA's WhatsApp OTP API sends and verifies codes. All prices were read from the providers' public pages on 8 November 2026 and will change, so recheck them before you commit.

Meta prices each delivered WhatsApp message by category and by the recipient's country, and OTPs must use the authentication category. On 8 November 2026, Meta's official WhatsApp Business pricing calculator listed India authentication at ₹0.115 per delivered message ($0.0014). Through PayPerWA you also pay a flat platform fee:

Meta ₹0.115 + PayPerWA ₹0.20 = ₹0.315 per authentication message in India, billed as two separate charges.

Meta bills its ₹0.115 directly to the payment method on your WhatsApp Business account. Only PayPerWA's ₹0.20 comes from your prepaid PayPerWA wallet, and it is refunded automatically if Meta rejects the message or later reports it as failed. PayPerWA's ₹0.20 already includes 18% GST. Meta's pricing pages do not state how tax applies, so treat ₹0.115 as Meta's list rate. There is no PayPerWA subscription, setup fee or minimum monthly spend, checking a code with PayPerWA's Verify API is free, and the wallet's minimum recharge is ₹750; see pricing.

• No free window for OTPs. Authentication messages are charged even inside a 24-hour customer service window, and the 1,000 free service messages per number per month do not cover them. The only free case is a free entry point window opened by a Click-to-WhatsApp ad.
• Volume discounts start late. Meta's calculator shows the first lower India authentication tier (₹0.1081) only above 750,000 charged messages a month, counted across your business portfolio.
• Businesses based abroad. An India-based business always pays the domestic rate to Indian users. A foreign business pays India's authentication-international rate (₹2.4971, or $0.0304) only once Meta makes it eligible (more than 750,000 messages outside customer service windows in a moving 30 days to users in the 18 markets with such a rate) and its start date, 30 days later, arrives.
• Recipients abroad. Meta's rate depends on the recipient's country; see our rates page. PayPerWA's fee stays flat: ₹0.20 from an INR wallet or $0.004 from a USD wallet.

For SMS, these are India-to-India list prices from each vendor's own page on the same date:

• MSG91 (OTP pricing): ₹0.25 per OTP at 5,000 OTPs, falling to ₹0.18 at 8,55,556, plus 18% GST (about ₹0.295 to ₹0.21 with GST).
• Fast2SMS: no separate OTP tariff; ₹0.25 per SMS on the smallest recharge slab down to ₹0.11 on recharges of ₹6,00,000 and above, plus 18% GST (about ₹0.295 to ₹0.13).
• Twilio: $0.0832 per SMS segment to India, a $0.001 processing fee on failed messages, and possible additional carrier fees. Twilio Verify adds $0.05 per successful verification on top of the channel fees.
• Exotel and Gupshup: we found no published India rate; Exotel says to contact sales.

SMS has costs the per-message rate hides. DLT entity registration is paid to the operator: Fast2SMS lists ₹5,900 and Exotel describes ₹5,000 to ₹10,000 as a typical one-time fee, with renewal varying, so there is no single official figure. Some providers, including Exotel and Twilio, also bill per message part: one part holds 160 standard characters but only 70 in Unicode, so an OTP template in Hindi can need two parts where the English version fits in one.

The honest read: at list prices, a DLT-registered SMS OTP from an Indian aggregator costs less than a WhatsApp OTP through PayPerWA, and the gap widens with volume. At the smallest slabs the two are close: about ₹0.295 per SMS including GST, against Meta ₹0.115 + PayPerWA ₹0.20 for WhatsApp, where PayPerWA's fee already includes GST and Meta does not state how tax applies to its rate. Run the numbers with your own volume and quotes. What WhatsApp saves is mostly fixed cost and paperwork: no DLT registration and, on PayPerWA, no subscription or monthly minimum, which matters more when your volume is low or uneven.

Both channels make you register what you send, but the gates are very different. A WhatsApp OTP needs no DLT registration at all: one approved authentication template takes the place of the entity, header, template and path registrations that SMS needs.

WhatsApp. You need a WhatsApp Business account on Meta's Cloud API with a phone number and a payment method for Meta's fee, connected to PayPerWA. Then:

1. Collect opt-in. Meta requires opt-in before you message anyone, with no exemption for authentication. Since November 2024 it can be general rather than WhatsApp-specific, as long as it names your business and complies with local law. The natural place is the screen where the user enters a number and chooses WhatsApp.
2. Create an authentication template. Meta requires this category for OTPs: marketing or utility templates used for codes are not moved to authentication, and Meta rejects them after notice. The body is fixed: {{1}} is your verification code. You cannot add a brand name, link, media or emoji, and the code can be at most 15 characters. Optional extras are the line For your security, do not share this code. and an expiry footer of 1 to 90 minutes.
3. In PayPerWA, pick the Authentication category under Templates. The security line is on by default, the expiry field takes 1 to 90 minutes (default 15), and the Copy Code button is added for you. If Meta reports your business as not verified or pending, PayPerWA stops the submission and links you to verification. Once Meta approves it, PayPerWA's Verify API sends with it automatically, or you name it with template_name. The authentication templates guide covers every option.

SMS. TRAI mandates DLT under its 2018 commercial communication regulations, tightened by an amendment notified in February 2025. As the sender (Principal Entity), you must:

1. Register your business on an operator DLT portal such as Jio TrueConnect, Airtel, Vi's ViLPower or BSNL. The 2025 amendment requires physical verification, biometric authentication of your authorised person and a link to a unique mobile number.
2. Register a header (sender ID). The amendment marks message type with a suffix: -T transactional, -S service, -P promotional, -G government.
3. Register the content template with the code as a variable ({#var#}). At least 30% must be fixed text, more than three variables needs justification, each variable is capped at 30 characters, and a template can be linked to only one header.
4. Register your message path, the chain from you through your telemarketer, on DLT. Since 11 December 2024, SMS sent through unregistered paths is rejected.
5. Whitelist any URL or call-back number the message carries.

Exotel puts entity approval at typically 3 to 7 business days and header and template approval at 1 to 3 days each. Operators must also temporarily deactivate headers and templates unused for 90 days, so a rarely used OTP template can stop working until you ask for reactivation.

The trade-off: DLT has more steps and fees, but OTPs that fit TRAI's transactional definition need no separate explicit consent. WhatsApp skips the telecom paperwork but depends on Meta's template approval, its opt-in policy and your account staying in good standing.

A code that is awkward to enter can still cost you a sign-up.

On WhatsApp, the code arrives in the chat with your business as Meta's fixed message with a button below it:

• Copy Code works on every platform. The user taps it, switches back to your app or site and pastes. It is the button PayPerWA's builder creates and the fallback for every other type.
• One-tap autofill (Android only) hands the code to your app. Your app's package name and signing-key hash must be on the template and the app must perform a handshake first; otherwise WhatsApp shows Copy Code. Meta deprecated the old PendingIntent handshake on 15 October 2026 in favour of its OTP Android SDK.
• Zero-tap (Android only) broadcasts the code straight to your app, so the user never leaves it. It needs the same app setup plus acceptance of Meta's zero-tap terms.
• iPhone users get Copy Code. On iOS 26 and later, the keyboard can suggest the code from the WhatsApp notification, but only for numeric codes of 3 to 8 digits, only when WhatsApp is not in the foreground, and only with WhatsApp notifications and Autofill Security Codes turned on.

PayPerWA creates Copy Code templates only and does not offer one-tap or zero-tap. For a website login that changes little, because both autofill types need a native Android app.

WhatsApp adds two protections. On Cloud API, authentication messages reach only the user's primary phone and are masked on WhatsApp Web, desktop and other linked devices. WhatsApp also disables forwarding of these messages to combat phishing.

On SMS, the code arrives in the messages app under your header, in wording you wrote within your DLT template, so you can name your brand. Android apps can read it with Google's SMS Retriever API, which needs an app-identifying hash in the message (so it must be part of your DLT template), or with the SMS User Consent API, which needs no hash but asks the user to allow access. iPhone apps can offer the code through security code AutoFill, and feature-phone users type it in.

Two notes apply to both. Use a six-digit numeric code: NIST asks for at least six digits, and iOS will not autofill alphanumeric codes from WhatsApp. And align expiry: by default Meta drops authentication messages not delivered within 10 minutes (for templates created since 23 October 2024), NIST treats a code unused after 10 minutes as invalid, and PayPerWA's footer defaults to 15 minutes, so set it to 10 or less and match it on your server.

Here SMS has a structural advantage. An OTP SMS reaches any phone with a working SIM and signal, including feature phones and phones with mobile data off. TRAI treats an OTP sent within 30 minutes of a transaction the customer started as a transactional message, and Do Not Disturb settings, even "fully block", do not stop transactional messages. The catch: mixing promotional content into the message makes the whole message promotional.

A WhatsApp OTP reaches only someone with WhatsApp on that exact number, on their primary phone, online before the message expires. That leaves out users without WhatsApp and users whose WhatsApp runs on a different number. How large that group is depends on your audience, so measure it on your own sign-ups.

Meta's best practices reflect this. Confirm the user's WhatsApp number and say clearly that the code is going to WhatsApp. On Android, show the WhatsApp option only if WhatsApp is installed. Offer a choice of channels, such as WhatsApp, SMS and email. For account recovery, do not treat a phone number and its WhatsApp account as the same thing, because a recycled number can still carry the previous owner's WhatsApp. Meta's zero-tap guidance also advises against making WhatsApp your default code delivery method.

Any form that sends a paid message when someone types a phone number is a target. The best-known attack is SMS pumping, also called Artificially Inflated Traffic (AIT): fraudsters use your OTP or sign-up form to trigger large numbers of SMS to number ranges on an operator they collude with, and share the termination revenue while you pay. Warning signs include spikes to blocks of sequential numbers, traffic to countries where you have no customers, and codes that are sent but never verified.

Does WhatsApp avoid this? Partly. The classic scheme depends on operators earning termination revenue on SMS, and a WhatsApp authentication message is not delivered as an SMS. But the underlying problem, which OWASP lists as API4:2023 Unrestricted Resource Consumption, remains: anyone who reaches your form can make you pay per request. Meta charges for every delivered authentication message and PayPerWA charges per send, so a bot pushing real WhatsApp numbers through your form still costs you money.

The defences are the same for both, and they belong in your code:

• A CAPTCHA or bot check before any code is sent, the mitigation MITRE lists for SMS pumping (technique T1496.003).
• Rate limits per phone number, IP address and device, with growing delays. Twilio suggests about one request per 30 seconds per number with exponential backoff.
• Blocking countries you do not serve, and alerts when your verified-to-sent ratio drops.
• Spending caps on every paid integration, as OWASP recommends.

What PayPerWA adds depends on the endpoint. With the Verify API, each number can be sent a new code only after 30 seconds and at most 5 times an hour, and none at all once 15 wrong codes have been entered for it in the past 24 hours; these limits are checked before anything is charged. They are per number: they do not stop a bot sending one code each to many different numbers. With /api/v1/messages/send, the only built-in limit is per API key: 100 requests a minute, shared with every other call on that key (Verify API checks included), with no dashboard setting to change it. Neither detects OTP fraud for you, so CAPTCHA, IP limits and a country allow-list stay in your code. One more thing helps: PayPerWA's ₹0.20 is charged from a prepaid wallet before each send, and an empty wallet returns a 402 error instead of sending, which caps how many messages a runaway script can trigger through PayPerWA. See OTP security best practices for the full checklist.

Neither channel guarantees delivery, and an accepted API call proves nothing on either.

SMS in India fails in two places. DLT scrubbing blocks a message when the text does not match the registered template, the header or template is inactive, the entity ID does not match, the path was not registered, or a URL was not whitelisted. Exotel notes that such messages are blocked by the operator and never delivered, so only delivery reports reveal them. Network failures come afterwards: absent or unknown subscriber, full memory, congestion or expired validity.

WhatsApp fails differently:

• No WhatsApp or offline. A number without WhatsApp cannot receive the message, and Meta drops messages not delivered within the 10-minute default time-to-live.
• Template mismatch. The template must be approved and the language code must match exactly. With /api/v1/messages/send, PayPerWA defaults to "en", so pass en_US or hi if that is what the template uses; the Verify API uses the template's own language unless you pass one. Otherwise you get a 404 or a Meta error.
• Your Meta account. If the account is blocked over payment (Meta error 141006), Meta can accept a message that will not be delivered, and PayPerWA's response flags it with a delivery_warning. Eligible Indian businesses must also move their WhatsApp accounts to INR billing by 31 December 2026; from 1 January 2027, Meta will not deliver messages from eligible customers' non-INR accounts.
• Status and retries. PayPerWA reports message.delivered and message.failed by webhook, tried once with no retry, and there is no status endpoint to poll. Neither send endpoint has an idempotency key: retrying a timed-out /api/v1/messages/send request can send and charge twice, while the Verify API refuses a second code to the same number within 30 seconds without charging. Let the user ask for a resend instead.

The failure modes barely overlap: a DLT mismatch never affects WhatsApp, and a phone with mobile data off can still get an SMS.

For a business based in India sending to Indian numbers, at list prices read on 8 November 2026:

Read it as a set of trade-offs, not a scorecard: one row that matters to your users can outweigh several that do not.

For many Indian products the practical answer is both: WhatsApp for users who choose it, SMS for everyone else and for every WhatsApp failure. PayPerWA sends WhatsApp only, so the SMS leg needs your own DLT-registered provider. For the codes you have two options. If WhatsApp is your only channel, PayPerWA's Verify API generates and checks them for you. If you offer SMS too, generating codes on your own server keeps one code store for both channels: whichever code arrived last works, and one attempt counter covers both. The steps below take that second route.

1. Let the user choose WhatsApp or SMS when they enter their number.
2. Generate a six-digit code with a cryptographically secure generator, store only its hash with a 10-minute expiry and an attempt limit, and never log it.
3. Send on WhatsApp and keep the returned message_id. After about 30 seconds, offer "Didn't get it? Send by SMS", or sooner if a message.failed webhook arrives.
4. On fallback, issue a new code that overwrites the old one (OWASP) without resetting the failed-attempt count (NIST), and cap total sends per number across both channels.

Here is the WhatsApp leg in Node.js 18+, using PayPerWA's send endpoint. createOtp() and sendSmsOtp() stand in for your own code store and SMS provider.

const PAYPERWA_API_KEY = process.env.PAYPERWA_API_KEY; // YOUR_API_KEY, starts with ppw_live_sk_

async function sendWhatsAppOtp(phone, code) {
  const res = await fetch("https://payperwa.com/api/v1/messages/send", {
    method: "POST",
    headers: {
      Authorization: "Bearer " + PAYPERWA_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      to: phone,                  // "919876543210": country code + number, digits only
      template_name: "login_otp", // your APPROVED Authentication template
      language: "en",             // must match the template's language code
      variables: [code],          // PayPerWA fills the body and the Copy Code button
    }),
  });
  const data = await res.json();
  if (!res.ok || !data.success) {
    throw new Error("WhatsApp OTP failed (" + res.status + "): " + data.error);
  }
  return data.data.message_id; // equals data.wamid in PayPerWA webhook events
}

export async function requestOtp(phone, channel) {
  // createOtp() replaces any earlier code for this number but keeps its failed-attempt count
  if (channel === "whatsapp") {
    try {
      const messageId = await sendWhatsAppOtp(phone, createOtp(phone));
      return { channel: "whatsapp", messageId };
    } catch (err) {
      // 402 empty wallet, 404 template not approved, 429 rate limit or a Meta error.
      // Do not resend the same request: there is no idempotency key. Fall back to SMS.
      console.warn("WhatsApp OTP not sent, using SMS:", err.message); // never log the code
    }
  }
  await sendSmsOtp(phone, createOtp(phone)); // your DLT-registered SMS provider
  return { channel: "sms" };
}

If you use the Verify API for WhatsApp and your SMS provider's own verification for SMS instead, check each code with the service that sent it, and cap total sends per number across both. There is no call to cancel a Verify code, so the WhatsApp code stays valid until it expires, is used or runs out of attempts.

Watch the fallback cost. If the WhatsApp message is delivered and the user still asks for SMS, that login costs Meta ₹0.115 + PayPerWA ₹0.20 plus your SMS rate. Track how often users fall back; it tells you whether offering WhatsApp is saving or costing money. Fuller examples, including verification, are in WhatsApp OTP login code examples.

There is no universal winner, but there are clear patterns:

• SMS as the default fits if many users are on feature phones or patchy data, if you must reach everyone with a mobile number, or if cost per code at high volume is your main constraint.
• WhatsApp as an option, with SMS fallback fits if your users are mostly on smartphones and already message you on WhatsApp, if you want WhatsApp OTPs live without DLT registration (or while it is in progress), or if you would rather pay only per OTP sent with no subscription.
• Both as equal choices fits if you also serve users outside India: the same WhatsApp template and API call can reach other countries at each country's Meta rate; check our rates page.
• Something stronger fits high-value accounts. OWASP advises against relying on SMS alone there and suggests authenticator apps, push or passkeys. RBI's September 2025 directions do not discontinue SMS OTP but encourage additional factors.

If you want to add WhatsApp, PayPerWA has no subscription and needs no DLT registration: create an account, connect your number, top up the wallet, create an authentication template, then send and verify codes with the two calls on the WhatsApp OTP API page (every field is in the OTP API reference, and the other endpoints in the API docs). In India each OTP costs Meta ₹0.115, billed by Meta to your WhatsApp Business account, + PayPerWA ₹0.20 from your wallet, verifying is free, and PayPerWA charges nothing in a month you send nothing. See features, ask through help, or read the full build in the WhatsApp OTP API guide for India. More posts are on the blog.