A reliable OTP flow sends the code on the channel each user is most likely to see first, such as WhatsApp or Viber, and falls back to SMS automatically if nothing is delivered within a short window. Email and authenticator apps (TOTP) sit beside that chain for recovery and high-risk actions, not inside it.
This guide covers the architecture: how the channels compare, what order to use, how fallback timing works, and how each attempt is billed. It is written for teams using a multichannel Verify API or planning to replace an SMS-only one-time password setup. Code length, expiry and retry limits are a separate topic; here we focus on channel design.
What is a multichannel Verify API, and why use one?
A Verify API handles the whole verification job for you: it generates or accepts a code, delivers it, applies expiry and attempt limits, and tells you whether the user entered the right code. A multichannel Verify API adds the part that matters most in production: it can deliver on several channels and switch between them automatically.
Teams move from SMS-only to multichannel for five practical reasons:
- More codes arrive. Delivery problems cluster by country, operator and time of day. If one channel stalls, the next one takes over without the user doing anything.
- Better reach per region. No single channel is best everywhere. A per-market channel order lets you meet users on the app they already use.
- Fewer drop-offs. Verification is a gate in signup, login and payment. Every code that never lands is a user stuck at that gate.
- More control over cost. OTT channels (WhatsApp, Viber, Telegram) can be cheaper than SMS in some markets, and you choose where SMS is used.
- No single point of failure. A sender ID block, a filtering change or an operator outage no longer takes your whole login flow down.
How do SMS, WhatsApp, Viber, Telegram, email and TOTP compare?
Each channel has a clear job. The table summarises where it helps and where it breaks.
| Channel | Needs data or an app? | Strengths | Watch out for | Best role |
|---|---|---|---|---|
| SMS | No | Works on any mobile phone, including basic handsets and users with no data | Operator filtering, sender ID rules, SIM swap and interception risk, charged on send | Universal last step in the chain |
| Yes, app and data | Branded business profile, end-to-end encryption, copy-code and autofill buttons | User must have WhatsApp on that number; template approval needed | First channel where your users live on WhatsApp | |
| Viber | Yes, app and data | Branded sender, encrypted delivery, strong in specific regions | Low install base in many markets | First channel in Viber-heavy markets |
| Telegram | Yes, app and data | Reliable where it is widely used | Niche in most consumer audiences | Optional middle step for audiences that use it |
| Internet access | Almost every user has an address; no per-message operator fee | Slower, spam folders, account can be accessed with a password alone | Recovery and low-risk checks, chosen by the user | |
| TOTP app | App, works offline | No delivery step, nothing to intercept in transit | User must enrol; codes can still be phished | Step-up for high-risk actions and power users |
Two points are often missed. First, WhatsApp authentication templates support a copy-code button and one-tap autofill on Android, which removes typing errors (Meta authentication template documentation). Second, email is weaker than it looks for authentication: NIST SP 800-63B-4 states that email shall not be used for out-of-band authentication because the mailbox may be accessible with a password alone and messages can be intercepted in transit (NIST SP 800-63B-4, section 3.1.3.1).
Which channel should go first?
Pick the first channel per market, based on your own data rather than global averages. A simple way to decide:
- Look at where your users are. Split verification traffic by country. Most products find that a handful of countries carry most of the volume.
- Check what your users already use. Signup surveys, support conversations and past campaign results tell you whether WhatsApp, Viber or plain SMS is the everyday channel.
- Lead with the OTT channel only where it is common. If a large share of users do not have the app, leading with it just adds delay before SMS.
- End with SMS almost everywhere. It is the only channel that works without data and without an app installed.
Typical orders look like WhatsApp then SMS in WhatsApp-first markets, Viber then SMS where Viber is the default messenger, and SMS only where OTT apps are uncommon or where your users skew towards basic phones. For how the apps differ in practice, see our guide to WhatsApp and SMS channel choices.
How does smart fallback work?
Good fallback is one verification with several delivery attempts, not several separate verifications. The sequence looks like this:
- Your app creates one verification with an ordered list of channels.
- The platform tries the highest-priority channel and tracks its delivery status.
- If that channel fails or its window expires without delivery, the platform moves to the next channel.
- Once a channel delivers, no further channels are tried.
- The user enters the code, and your app confirms it against the same verification ID, whichever channel delivered.
Two design rules keep this clean. Do not create a new verification each time a channel fails, because the user may end up with several live codes. And when the user taps “resend”, cancel the old verification before creating a new one so only one code is valid at a time.
With the SMS.to Verify API, the channel order goes in the create call. Each channel has a priority and its own expiry_time, which is the window before the next channel is tried:
curl -X POST https://verifyapi.sms.to/api/v1/verifications/create \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"guid": "3-1748345-bcef-0342-6bef5c26-04f64e7",
"recipient": "+447700900123",
"reference": "signup-7f3a9c",
"callback_url": "https://example.com/webhooks/verify",
"channels": [
{ "channel": "whatsapp", "priority": 1, "expiry_time": 30 },
{ "channel": "sms", "priority": 2, "expiry_time": 30 }
]
}'The guid identifies your Verify App, where you keep default settings such as code format, template and language. When the user types the code, confirm it:
curl -X POST https://verifyapi.sms.to/api/v1/verifications/confirm \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "id": "3-1749636-f945-113c-a0499efc-4f9372d", "password": "326372" }'A valid, unexpired code returns success: true. An invalid, expired or already used code returns success: false. The full field list is in the SMS.to API documentation.
How long should each channel get before fallback?
The window per channel is a trade-off. Too short, and you pay for an SMS that races a WhatsApp message that was about to arrive. Too long, and the user stares at an empty screen and gives up.
- Start short on OTT channels. Messages over data usually land within seconds when the app is installed and the phone is online. A starting point of around 20 to 30 seconds is our usual recommendation, then tune it from your logs.
- Keep the overall code lifetime longer than the sum of the windows. A code that expires before the SMS step arrives is useless. NIST caps out-of-band codes at 10 minutes, so stay well inside that.
- Tell the user where to look. “We sent a code to WhatsApp. If it does not arrive, we will text you.” This removes most “I never got it” tickets.
- Tune by market. Use per-request overrides to test a shorter or longer window in one country without changing the global default.
Where do email and TOTP fit?
Email and TOTP are not automatic fallback steps. They are options the user picks.
Email works well for confirming an email address, for account recovery when the phone is lost, and for low-risk actions. Because NIST excludes email from out-of-band authentication, do not treat an emailed code as equal to a code sent to the phone for high-risk actions.
TOTP (time-based one-time passwords, defined in RFC 6238) runs in an authenticator app. The app and your server share a secret and derive the same short code from the current time, so there is no message to deliver or intercept, and it works offline. It suits payouts, security setting changes and staff accounts. Offer it as an upgrade in account settings and keep phone-based codes for everyone else.
For a wider look at the security trade-offs, see our guide to how secure SMS two-factor authentication is.
What does fallback cost?
Fallback changes what you pay per verification, so model it before launch. SMS.to publishes these Verify billing rules:
| Situation | What you pay |
|---|---|
| WhatsApp, Viber or Telegram delivers | That channel’s fee, plus the Verify fee if the user verifies |
| OTT channel attempted but not delivered | No channel fee for that attempt |
| SMS sent | The SMS fee, charged when sent, even if it is not delivered |
| Channel skipped (never attempted) | Nothing |
| Code delivered but never entered | The channel fee, with no Verify fee |
The practical consequence: leading with an OTT channel costs nothing extra when that channel fails, but every SMS step you reach is billed whether or not it lands. That matters for fraud, too. Fallback does not remove SMS pumping exposure, because an attacker who triggers verifications to expensive destinations still causes SMS sends. You still need the controls below.
How do you stop fallback being abused?
- Rate-limit by user, IP address, device and destination. Cap how many verifications one number or session can start per hour.
- Add a human check on repeat attempts. A CAPTCHA after a second or third request stops most scripted abuse.
- Restrict destinations you do not serve. If you have no users in a country, do not allow verifications to it.
- Validate numbers first. An HLR or MNP lookup flags invalid and unreachable numbers before you pay to send. Our guide to MNP lookups and list cleaning explains how.
- Use shorter expiry for risky actions. Payout changes and new-device logins deserve tighter windows than a newsletter signup.
- Watch completion by country. A spike in sends with no matching rise in successful verifications is the classic pumping signature.
How SMS.to handles multichannel OTP
The SMS.to Verify API delivers codes over SMS, WhatsApp, Viber and Telegram. You set defaults once in a Verify App (channel order, expiry, code length or format, templates and language) and override any of them per request for tests, new regions or high-risk flows. If you prefer to generate codes yourself, you can pass your own code and let Verify handle delivery, limits and confirmation.
Delivery and verification events stream to your webhooks, and the logs show the exact path each verification took, so support can answer “what happened to this user’s code?” in one search. Dashboards track completion, drop-off and fees per channel, and let you compare an OTT-first order with SMS-only for your regions. SMS.to is operated by Intergo Telecom, a licensed telecom and CPaaS operator that has been building messaging infrastructure since 2014.
FAQs
What is OTP fallback?
OTP fallback means that if the first channel does not deliver a one-time code within a set window, the system automatically tries the next channel in your order, for example WhatsApp first and SMS second. The user still completes one verification.
Which channel should go first in a multichannel OTP flow?
Lead with the channel most of your users in that market actually have and open, which is often WhatsApp or Viber in app-heavy markets and SMS elsewhere. Keep SMS as the last step because it works on any phone without data or an app.
Does fallback to SMS cost extra?
With SMS.to, an OTT channel is only charged if it delivers, and skipped channels are not charged. An SMS is charged when it is sent, even if it is not delivered, and the Verify fee applies only when the user verifies.
Should email or TOTP be part of the fallback chain?
Not as an automatic step. Email is better for account recovery and low-risk checks, and TOTP is something the user enrols in once. Offer both as options the user chooses rather than channels your system falls back to.
Ready to test a WhatsApp-then-SMS flow on your own numbers? Create a free account, no credit card needed, and send your first verification in minutes.
