You reduce OTP delivery failures in Kenya by fixing the avoidable causes first, such as bad number formats and reliance on a single channel, then adding a fallback channel and measuring delivery so you see problems before your users report them. Most failed OTPs trace back to a short list of causes, and most of them can be designed around.
This guide covers why codes go missing, which fixes give the biggest return, how to measure delivery honestly, and how to keep a fallback safe. It uses general engineering practice and public information rather than made-up delivery figures, because the right numbers are the ones you measure on your own users.
What failure actually means
"The OTP failed" can describe several different problems, and each needs a different fix.
- Not accepted: the provider or carrier refused the message, so it never left
- Accepted but not delivered: the carrier took it, but the phone never got it
- Delivered late: the code arrived after the user gave up or after it expired
- Delivered but not used: the user saw it but did not finish sign-up
- Used wrongly: the user typed it wrong, or typed an old code after a resend
Treat these separately in your logs. A late code and a missing code feel the same to a user but have different causes.
Common causes of missing or late codes
- A number that is not in +254 format, or contains a stray space or leading zero
- A sender ID that a network filters or rejects
- A congested or slow route at peak times
- A phone that is off, out of coverage, roaming, or has a full inbox
- Do not disturb or message filtering on the handset
- Dual-SIM phones where the SIM that receives messages is not the one the user expects
- Users pressing resend repeatedly, which creates several codes and confusion
- Short code expiry combined with slow delivery
Fix 1: validate numbers before you send
Normalise every number to one format and reject anything that does not parse. This costs nothing and removes a whole class of failures. It also saves money, because you stop paying to attempt numbers that cannot receive a message.
Fix 2: use a tested route and sender setup
Different routes behave differently on different networks. Ask your provider how the route is set up for Kenya, what sender name users will see, and whether it has been tested across the main networks. Then verify it yourself with a delivery test across the networks your users have. Rules for sender names can change, so check them with your provider and the regulator.
Fix 3: design resend carefully
A resend button is useful, but a careless one makes problems worse.
- Wait a short cooldown before allowing a resend, and show a countdown
- Do not reset the wrong-attempt count when a new code is issued
- Consider reusing the same code for a short window instead of issuing a new one each time, so users who finally see an earlier message still succeed
- Limit how many resends one number can trigger in a period
Fix 4: add a fallback channel
A second channel is the biggest single improvement for most products. A typical order is SMS first, then WhatsApp, then a voice call that reads the code aloud.
- SMS reaches almost any phone
- WhatsApp suits users who rely on the app and have data
- Voice helps users who cannot receive or read a text
Send the same code on every channel so the user only has to enter one. Trigger the next channel when a send fails or when the code has not been confirmed after a timer.
Fix 5: use M-PESA verification where it fits
For payout number changes and other high-risk steps in Kenya, an M-PESA verification confirms the number with a PIN prompt instead of a typed code. It removes the typing step and the wait for a message, though it only works for Kenyan numbers and users who can respond in time, so keep a fallback.
Fix 6: protect the endpoint
Fraud can look like delivery failure. Bots that trigger paid messages to number ranges you do not serve inflate your bill and can crowd out real traffic.
- Allow only the countries you serve
- Rate limit per number and per IP
- Set a daily spend cap with alerts
- Add a challenge before the first send if you see bots
- Watch verification rate by country: many sends with few verifications is a warning sign
Measure it
You cannot improve what you do not log. For every attempt, record the channel, provider, status, time sent, time delivered and whether the code was verified.
- Delivery rate per channel and per network
- Time from send to delivery
- Verification rate: verified codes divided by sent codes
- Resend rate: the share of users who ask for another code
- Fallback rate: how often the second or third channel is needed
- Cost per verified user
A sudden drop on one route is easy to see when every attempt is logged. Webhooks that report delivery and fallback events make this simpler than polling carriers.
Keep fallback safe
A fallback channel does not weaken the code if you apply the same rules on every channel: single use, short life, and one shared attempt counter. Limit how many channels and resends a number can use. NIST guidance treats SMS and voice as restricted authenticators, so for high-value actions also offer a stronger option such as an authenticator app.
A simple improvement plan
- Week one: normalise numbers, add logging, and measure your current delivery and verification rates
- Week two: add rate limits, a country allowlist and a spend cap
- Week three: add a fallback channel and a resend cooldown
- Week four: review the numbers, remove what did not help, and set alerts for sudden drops
Where Tambua fits
Tambua runs an ordered fallback of up to three channels per app, on failure or after a timer, using one code across attempts. Channels are SMS, WhatsApp, voice, email and M-PESA. Every attempt is logged, webhooks are signed, and failed attempts are not billed, so you only pay for carrier-accepted attempts. SMS OTP in Kenya is KES 0.50. See the Tambua docs for the delivery journey settings.
Frequently asked questions
What is a good OTP delivery rate? There is no universal figure. Measure your own delivery and verification rates by network and channel, and watch the trend.
Should I extend the code expiry to cope with slow delivery? A little, within sensible limits. NIST allows up to 10 minutes. Fixing delivery is better than leaving codes valid for longer.
Is it safe to send the same code on a second channel? Yes, if the code stays single use, short lived and attempt limited across all channels.
Why do some users never receive SMS but get WhatsApp? Handset filtering, coverage or network issues can block SMS while data still works. That is why a second channel helps.