SMS or WhatsApp for OTPs: what a code costs by country

For most products, the highest-volume message they will ever send is a six-digit number. Login codes, signup codes, password resets, payment confirmations: all short, all urgent, all billed one at a time. It is also the one message type where the channel decision is almost pure arithmetic, because nobody is loyal to the way their verification code arrives.

The arithmetic is startling in some countries and almost irrelevant in others. Sending an SMS to an Indian number at Twilio's published rate costs 59 times what the same code costs as a WhatsApp authentication template. In Germany, it costs twice as much. Same two channels, same code, wildly different decisions.

Then there is the part that ruins naive projections: you cannot send every code over WhatsApp, so you keep paying for SMS anyway. In the worked example below, the WhatsApp traffic is $112 a month and the fallback SMS is $2,330.

The two rate cards, side by side

SMS prices are Twilio's published outbound rate per segment for each country, taken from their per-country pricing pages on 12 September 2026. WhatsApp prices are Meta's authentication rate on the card that takes effect on 1 October 2026. The US line adds AT&T's A2P 10DLC carrier surcharge, because in the US that is a real per-message cost.

One caveat matters more than any other number in that table. Twilio's India price is for international long codes. Domestic Indian routes with a registered sender ID are quoted by sales, not published, and they cost far less than $0.0832. If you are an Indian company sending to Indian customers through a local aggregator, your SMS rate is much lower and the 59x shrinks a long way. The calculator lets you type your real rate in, and you should.

What an SMS actually costs

Three things sit between the rate card and the invoice.

Segments, not messages. Twilio bills per segment, and a segment is 160 characters in GSM-7 or 70 in UCS-2. Concatenated messages drop to 153 and 67 characters per segment, because the header takes room. A plain OTP fits in one segment. An OTP with a branded prefix, a policy line and a curly apostrophe does not: the apostrophe alone can flip the whole message to UCS-2 and double the bill.

Carrier fees and registration in the US. American A2P traffic over 10-digit long codes goes through 10DLC registration. Twilio's fees are $44 for a standard brand registration, $15 per campaign to vet it, and $1.50 to $10 per campaign per month, with a $4 brand fee on the low-volume and sole proprietor routes. On top, each carrier adds a per-segment fee, which is why the US row above is $0.0118 and not $0.0083.

DLT registration in India. India's rules are stricter than anywhere else in the table. TRAI requires a sender to register as a principal entity, register a header of up to eleven characters, register the content template with its fixed and variable parts, and register a consent template for promotional traffic. TRAI's own wording is blunt: "All the above steps are necessary to become a registered sender. Failing to follow any steps will not allow you to send CC." Twilio says the same from the other side: registration in the operator DLT portal must be complete before you can register a sender ID with Twilio, and a registered sender ID has to be used for the use case it was approved for.

That is the hidden tax on SMS OTPs. Not the per-message rate, but a registration process per country, per sender ID, per message shape, and a template change that needs re-approval.

WhatsApp codes have their own rules

A WhatsApp code is not a free-form message. Meta's documentation is explicit that apps offering verification codes over WhatsApp must use authentication templates, and those templates come with fixed text: "{{code}} is your verification code", where the code is the only thing you supply. You may add an optional security line, "For your security, do not share this code", and an optional expiry line, "This code expires in N minutes". That is the whole message. No branding paragraph, no marketing.

The button is your real choice. A copy code button puts the code on the clipboard. A one-tap autofill button hands it straight back to your Android app, which Meta calls the preferred option because the user never leaves the app. Zero-tap goes further and delivers the code to the app without the user touching anything.

Two operational details are easy to miss. Authentication messages are delivered only to a user's primary WhatsApp device, with linked devices shown a prompt to look at the phone. And some countries have an authentication-international rate that applies when your business is outside the recipient's country and you send more than 750,000 messages outside customer service windows in a 30-day period. Meta lists Egypt, India, Indonesia, Malaysia, Nigeria, Pakistan, Saudi Arabia, South Africa and the UAE. For a large sender based outside India, the Indian authentication rate goes from $0.0014 to $0.0304, and the 59x becomes 2.7x. That single line has moved more OTP budgets than any rate card change.

The fallback is most of the bill

Here is the part that rate-card comparisons miss. You do not know which of your users can receive a WhatsApp message, and the ones who cannot still need their code. So a WhatsApp-first flow is really two flows, and you pay for both.

Take 100,000 codes a month to Indian numbers at the published international SMS rate. Send everything by SMS and it is $8,320. Send WhatsApp first to the 80% of users you can reach, with 10% of those attempts falling back to SMS, and the bill is $2,442: only $112 of WhatsApp, and $2,330 of SMS. You save 71%, and almost none of the remaining cost is the channel you switched to.

Push coverage to 100% and the same 10% fallback still leaves you at $972 a month, seven times the $140 of pure WhatsApp traffic. That is the number to optimise: not the WhatsApp rate, which is already tiny, but how often you give up on WhatsApp and send an SMS as well.

Work it out for your own numbers

The defaults are that Indian example: 100,000 codes a month, 80% coverage, 10% of WhatsApp attempts needing an SMS anyway. Change the country and the rates update from Twilio's and Meta's published prices, and both stay editable, because your negotiated rate is the one that matters.

Some results worth trying. Germany, where the ratio is 2x: 100,000 codes cost $11,200 by SMS and $7,536 WhatsApp-first, a 33% saving that has to pay for the integration work. Indonesia, where SMS is $0.4414: the same volume goes from $44,140 to $14,359. And India with the authentication-international box ticked, which is the honest setting for a foreign sender at scale.

Building it so you do not pay twice

The cost model above assumes a sane implementation. Three things make it come true.

One code, both channels, one expiry. Generate the code once, store it once, and let either channel deliver it. Two codes for one login attempt is the single most common way to turn a saving into a support ticket.

A fallback timer based on delivery, not on hope. Wait for Meta's delivered status, not read, because people read codes from the notification. If it has not arrived in a few seconds, send the SMS. Too eager, and you pay for both on every login: in Germany that is $0.167 against $0.112 for SMS alone, so an aggressive fallback is worse than never using WhatsApp at all. Too patient, and users start hammering the resend button, which also costs you a message each time.

Retries that cannot double-send. Every send is a job with a retry policy, and every retry needs an idempotency key so a webhook redelivery or a queue replay cannot bill you twice. This is how I run every external call in PostEngage: an explicit retry policy, a dead-letter queue, and an alert, because messaging failures are invisible until they are expensive. A silent drop in WhatsApp delivery looks exactly like nothing for a week, and then looks like a spike in SMS spend.

Worth measuring from day one: delivery rate per channel and country, time from send to delivered, fallback rate, and verification success rate. That last one is what actually matters. A cheaper channel that verifies fewer users is not cheaper. At Acefone, Interaction Hub keeps every interaction on an event log for exactly this reason: when WhatsApp, SMS and voice all touch the same customer, per-channel outcomes are the only way to tell which one is failing.

One more sanity check before switching. Neither channel comes with an uptime promise you can lean on: Meta publishes no commercial SLA for the Cloud API, and an SMS route depends on carriers you have no relationship with. If login depends on a single channel, your login availability is that channel's availability, which is a good argument for keeping the fallback working even when it is expensive.

The short version

Work out two numbers before anything else: the SMS rate you actually pay in each country, and the share of your users you can reach on WhatsApp. The published ratio between channels is dramatic in India, Nigeria and Indonesia, and unremarkable in Western Europe.

Then budget for the fallback, because it will be most of the bill. Send the WhatsApp template first, wait for a delivered status rather than a read one, fall back to SMS on a timer you have tested, and keep one code with one expiry across both channels. And if you are sending from outside the recipient's country at volume, check the authentication-international rate before promising anyone a 59x saving.