WhatsApp OTP vs SMS OTP: Cost, Delivery and Fallback

How do I send the code on each channel?

On WhatsApp, send the approved template with the code as the body variable. For a copy-code button, pass the same code in buttonsTemplateVariable.

curl -X POST https://api.broadnet.me/whatsapp/message/sendbulk \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -F batchId=0 \
  -F destinationNo=971500000000 \
  -F messageType=TEMPLATE \
  -F templateName=login_code \
  -F templateLanguage=en_US \
  -F bodyTemplateVariables=482913 \
  -F buttonsTemplateVariable=482913

Here login_code is a placeholder for your own approved authentication template. On SMS, call POST /sms/sendSms with JSON:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

Note the differences: WhatsApp is multipart form data and returns a batchId; SMS is JSON and returns the message ID as plain text. Full examples are in our guides to sending WhatsApp via API and sending SMS via API.

How do I build WhatsApp-first delivery with SMS fallback?

Send on WhatsApp, wait for a status, then send once on SMS if needed. Our statuses are normalised across channels, so the same handler can drive both.

1. Generate the code on your server, store only a hash with an expiry, and limit attempts.
2. Send the WhatsApp template and record the batchId and your operation ID.
3. Wait for DELIVERED on the webhook for a window you choose, based on user patience.
4. If FAILED, REJECTED or no delivery in time, invalidate the first code, generate a new one and send the SMS.
5. Cap fallbacks per number and per session.
6. Record which channel succeeded, to tune the order by country.

Avoid blind retries after timeouts, because the API has no idempotency key; check status before resending, as described in Errors and limits. The order of channels is configured per use case in OmniChannels.ai, and the general design is in our channel fallback strategy. For webhook handling, see the webhooks guide. Voice OTP is another fallback step; see the voice OTP guide and contact sales for voice pricing.

How do fraud and abuse differ?

Both channels attract abuse, so build controls before you launch. SMS has a well-known problem: attackers trigger codes to numbers they profit from, inflating your traffic. WhatsApp is not immune, because any endpoint that sends a message on request can be abused to generate cost or harass a number.

Controls that apply to both:

• Rate limit code requests per phone number, per IP address, per device and per account.
• Validate numbers before sending; see HLR lookup.
• Cap fallback so an attacker cannot trigger two messages per request.
• Watch conversion: many requests with few completed verifications is a warning sign.
• Block destinations you do not serve.
• Short expiry and limited attempts, with no code reuse.

Read SMS pumping fraud prevention and use the fraud calculator to estimate exposure. Under NIST SP 800-63B-4, out-of-band codes are one authenticator type with known limits, so use stronger methods for high-risk actions such as payments or account recovery.

Which should I choose?

Decide by audience and risk, then test.

Worked example: a ride-hailing style app in the GCC

"Rafiq Rides" (synthetic) verifies new driver and rider accounts in the UAE, Saudi Arabia and Egypt.

• Design: WhatsApp authentication template with copy-code first; SMS fallback after a short wait with no DELIVERED status.
• Controls: three code requests per number per hour, a per-IP limit, number validation before the first send, and one fallback per session.
• Measurement: verification completed within a short period, split by channel and country; failed and fallback share.
• Tuning: in one country where WhatsApp delivery is weaker, the team flips the order to SMS first.
• Costs: modelled per country with the pricing tools, reviewed monthly against actual sends.

What are the common mistakes?

• Comparing one global price, instead of per country and per verified user.
• Sending both channels at once, which doubles cost and abuse surface.
• Unlimited resend buttons.
• Reusing the old code after fallback.
• Logging codes or sending them in URLs.
• No consent record for the WhatsApp channel.
• Promising zero-tap everywhere. Check current device support.
• Limits: this guide describes the mechanism. Delivery, cost and device support vary by country, route and Meta's rules, and should be tested in your markets.

How OmniChannels.ai helps

OmniChannels.ai covers both channels in one API: WhatsApp authentication templates (one-tap, zero-tap and copy-code) as an official Meta Business Solution Provider, and A2P SMS over BroadNet's direct operator connectivity, with channel fallback configured per use case and statuses normalised into one webhook format. Our team prepares sender ID and WhatsApp registrations with you; approvals stay with Meta and regulators. See the OTP solution, the OTP SMS API and the developer docs. A call is another fallback option; see voice OTP and voice API. Apps can also use a push notification service for sign-in prompts.