The requirement that matters for a voice OTP isn’t delivery. It’s that one specific person hears six digits clearly, once, while the login screen is still open on their other device.
Voice OTP fallback is a second verification path: when a one-time passcode sent by SMS hasn’t been entered within a set window, the platform places an automated call that reads the same code aloud. It exists because SMS fails in ways you can’t see from the sending side, and a verification flow with one channel has one failure mode too many.
Most teams treat the voice leg as an afterthought. They bolt a text-to-speech call onto the end of the flow, test it on their own phones, and move on. Then it breaks in production for reasons nobody designed for: the call shows an unfamiliar international number and gets declined, the audio clips the first digit, or someone discovers the endpoint can be pointed at premium-rate ranges. This post is about building the voice leg as if it were the primary path, because for the users who reach it, it is.
Why voice still belongs in a verification stack
Voice verification survives because it fails differently from SMS. That’s the whole argument for keeping it.
SMS depends on the recipient’s messaging path: carrier filtering, sender ID rules that differ by country, handsets with full inboxes, and aggregators that may route through paths you never approved. Voice depends on a different set of things: a terminating route, a ringing handset, and a person willing to pick up. When one path degrades, the other usually hasn’t, which is exactly the property you want in a fallback.
There’s also a population that voice serves better outright. Landline-only users in some enterprise and older-demographic segments can’t receive SMS at all. Users with accessibility needs sometimes prefer a spoken code. Travelers roaming on a network that delays SMS will often still take a call.
If your messaging stack already offers WhatsApp or FlashCall as alternatives (our messaging hub covers those channels), voice still earns its place. It’s the channel of last resort that works on every phone number that can ring.
The trigger: deciding when to place the call
The fallback call should fire on the absence of a successful verification, not on the absence of a delivery receipt.
This is the design mistake I see most often. Teams wire the voice call to the SMS delivery report: if the DLR comes back failed or doesn’t arrive, call. The trouble is that DLRs lie in both directions. A “delivered” status can come back for a message that sat in a handset’s queue, landed in a filtered folder, or was delivered by a route that faked the receipt. A missing DLR can mean nothing more than a slow receipt path while the message arrived fine.
The only signal that matters is whether the user submitted the right code. So the trigger is a timer that starts when the SMS is sent and is cancelled when the code is verified.
How long should the timer be? Tune it from your own funnel data, not a blog post. Plot the distribution of time-to-submit for successful SMS verifications and look for the point where the curve flattens. Most of your successes will land early; the long tail after that is where users are waiting on a message that isn’t coming. Set the timer just past the knee of that curve.
Two refinements help:
- Let the user pull the call. Show a “Call me instead” option after a shorter delay, and fire the automatic call only at the full timer. Users who know SMS is unreliable for them will self-select.
- Skip SMS for known-bad destinations. If your data shows a country or number range where SMS verification rarely completes, go to voice first. The fallback becomes the primary path for that segment.
What the termination route has to do for a twenty-second call
A verification call is short, time-critical, and useless if the recipient declines it. Those three properties decide what you need from the route.
The caller ID has to be one the user expects
A voice OTP lives or dies on whether the phone gets answered, and the caller ID is most of that decision. If the route strips your CLI or replaces it with a random number from a different country, a cautious user declines the call. Their caution is correct, and your fallback fails anyway.
You need routes that deliver the number you send, unchanged, to the handset. That’s what CLI routes are for, and it’s the single largest reason not to put verification traffic on the cheapest route in the deck. We break down the difference in detail in our post on CLI and non-CLI routes.
Then use the CLI deliberately. Present one consistent number per region. Tell the user on screen which number will call (“We’ll call you from +44 20 …”), so the ring doesn’t feel like a surprise. If you operate in the US, the number’s STIR/SHAKEN attestation and its reputation with call-analytics engines also affect whether it shows up labeled as spam.
Post-dial delay eats your timer
Post-dial delay is the gap between sending the call setup and the handset ringing. On a verification call, every second of it comes out of the window in which the user is still staring at the input field. A route with long or erratic PDD, often a sign of extra transit hops, makes a fallback feel broken even when it technically completes.
When you evaluate routes for OTP traffic, look at PDD per destination, not just answer rates. Our guide to reading ASR, ACD and PDD explains how to spot the patterns.
Billing increments change the economics
A voice OTP call often runs well under a minute. On a route billed in 60-second increments, you pay for a full minute every time. On a per-second route, you pay for what you use. For short-call traffic the gap is large enough to change the business case for voice fallback entirely, and the billing increments breakdown works through the arithmetic.
The audio has to survive the codec
Text-to-speech digits are more fragile than they sound. A code read cleanly over G.711 can smear on a compressed codec, and “five” and “nine” are easy to confuse on a degraded path. Test your prompts over the codecs your routes actually negotiate, on real handsets in the destination country, not over Wi-Fi calling on a developer’s phone.
Designing the call itself
The call script is part of the reliability design, because a code the user can’t parse is a failed verification.
A few rules hold up well in practice:
Don’t start talking on answer. There’s a short delay between the call being answered and the user putting the phone to their ear. Open with a brief greeting or a one-second pause before the first digit, or the user will miss it.
Read digits slowly and individually. “Four. Seven. Two.” beats “four seventy-two.” Group them the way they’re displayed on screen.
Read the code twice, then offer a repeat. A “press 1 to hear the code again” option costs you a few seconds of airtime and saves a support ticket.
Match the language to the user, not the number. A user’s account language is a better guide than the country code of their phone, particularly for expatriates and travelers.
Make a policy decision about voicemail. If the call reaches voicemail, do you leave the code? Leaving it helps a user who missed the call. It also stores a valid credential in a mailbox that may be protected by a default PIN. For account-security flows, the more defensible choice is to leave no code, just a short message saying a verification call was attempted. Answering-machine detection makes this possible, but it adds latency at the start of the call, so test how it interacts with the pause rule above.
Voice has its own pumping problem
Any endpoint that places a call to a user-supplied number will eventually be used to place calls to numbers an attacker controls. That’s the voice cousin of SMS pumping, and it’s a form of international revenue share fraud.
The pattern is simple. An attacker scripts your sign-up or login form, enters numbers in high-cost ranges where they share in the termination revenue, and lets your fallback logic do the rest. Every “failed” SMS triggers a call. You pay termination on each one; someone else collects part of it.
Defenses stack, and you want several of them:
- Allowlist destinations you actually serve. If your users are in twelve countries, there’s no reason your verification endpoint should be able to call a hundred.
- Rate-limit by prefix, not just by account. Pumping attacks rotate through many numbers in the same range. A per-number limit won’t catch that; a per-prefix velocity check will.
- Cap spend per destination per hour and alert on breaches. The alert matters more than the cap, because it tells you an attack has started.
- Block known high-risk ranges and review them as your carrier updates its fraud intelligence.
- Require the SMS attempt first for new or unverified accounts, so an attacker can’t go straight to the expensive channel.
The broader toll-fraud picture, including SIP-level attacks, is covered in our SIP trunking security guide. For verification flows, the key insight is that your fraud controls belong in the application, before the call is placed. By the time the call hits the network, you’ve already spent the money.
A fallback architecture that degrades gracefully
A good verification flow is a small state machine with explicit limits, and writing it down that way prevents most of the failures above.
Here’s the shape that holds up:
- Create a verification session with an idempotency key. Every retry from the client references the same session, so a double-tap on “resend” doesn’t place two calls.
- Generate one code per session with a fixed time-to-live. Keep the same code valid across channels. If the SMS arrives late, after the call has already read the code, the user can still use either. Issuing a new code for the voice leg invalidates the SMS and creates a confusing race.
- Send SMS and start the timer.
- On timer expiry, place one voice call if the session is still unverified, the destination is allowed, and fraud checks pass.
- Allow at most one user-initiated voice retry. After that, route the user to support or a different verification method. An unlimited retry loop is both a cost leak and a fraud surface.
- Log every step with the session ID, including the call’s SIP response codes and duration. When a user says “I never got a call,” you want to know whether it rang, was declined, or never left your platform.
The reliability principle underneath all of this is that each channel should fail closed and independently. A dead SMS aggregator shouldn’t stop voice calls. A voice route outage should trigger an alert, not an infinite retry.
Choosing routes for verification traffic
The route decision for OTP traffic comes down to a few questions: does the route deliver your CLI unchanged, how quickly does it ring, how is it billed, and how many destinations can you cover without stitching together several carriers?
That last point matters more than it first appears. Every additional carrier in your verification path is another integration to monitor and another place where CLI handling can differ. A carrier like IDT Express, which terminates voice in 160+ countries on 1,000+ CLI-certified routes across three quality tiers, lets you put verification traffic on CLI routes across most of your footprint while keeping cheaper tiers for traffic where caller ID matters less. Whatever carrier you choose, separate OTP traffic from bulk traffic at the trunk or tag level so you can measure it on its own.
If you only take one thing from this post: measure your voice fallback by verified sessions, not by calls completed. A call that connects and reads a code the user can’t hear hasn’t done its job.
Frequently asked questions
What is voice OTP fallback?
Voice OTP fallback is an automated phone call that reads a one-time passcode aloud when an SMS passcode hasn’t been used within a set time. It gives users a second, independent path to verify when SMS delivery fails or is delayed.
How long should I wait before triggering the voice call?
Set the wait from your own data: find the point where successful SMS verifications stop arriving and trigger the call just after it. Offering a user-initiated “call me instead” button earlier lets users who know SMS is unreliable skip the wait.
Should the voice call use the same code as the SMS?
Yes, in most designs. Keeping one code valid across channels for the session’s lifetime means a late SMS and the voice call both work, and it avoids a race where the voice leg invalidates a code the user is about to type.
Should a verification call leave the code on voicemail?
For account-security flows, it’s safer not to. Voicemail boxes are often protected by weak or default PINs, so leaving a valid code there creates a credential exposure. A short message saying a call was attempted is the more defensible default.
How do I stop fraudsters from abusing voice OTP?
Put the controls in your application before the call is placed: allowlist the destinations you serve, rate-limit by number prefix, cap hourly spend per destination, and require an SMS attempt first for new accounts. Network-level fraud tools help, but application checks stop the cost before it’s incurred.
Talk to our voice team
Not sure which routes suit your verification traffic, or how to split OTP calls from bulk traffic? Talk to our voice team about CLI route coverage for your destinations.
