hen a one-time passcode does not arrive, a user is stuck at a login or a checkout screen and is one short interval away from abandoning. The frustrating part for the engineering team is that the message often went out cleanly — the API returned 202, the SMPP submit was accepted, the platform shows a queued message. The failure happened somewhere downstream on a wire the application team cannot see directly. This piece walks through the finite list of reasons OTPs fail in production, how to tell them apart from the receipts you do have, and the remediation pattern for each.
The failure surface is smaller than it looks
OTP traffic fails for one of seven reasons, in roughly this order of frequency: sender-ID rejection at the destination operator, a grey-route hop that drops or delays the message, throttling at the SMSC or the firewall, content filters tripping on a template, encoding mismatch between UCS-2 content and a GSM-7 template, network congestion at the destination operator, and the handset itself unreachable (off, out of coverage, ported with stale routing). Everything else — corrupt MSISDN, expired credentials, route-down events — is a small minority. Diagnose the common cases first.
Read the delivery receipts, not the submission response
The single biggest mistake teams make is treating a successful submission (202 from HTTP, ESME_ROK on submit_sm) as evidence the message was delivered. It is not. Submission means the platform accepted the message; delivery means the handset received it. Every OTP system needs to be wired against the delivery receipt (DLR), which arrives later as a webhook or a deliver_sm PDU and carries one of a small set of status codes: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. The first signal for any OTP investigation is the distribution of DLR status by route, sender ID, destination operator, and time window — not the submission success rate.
Diagnose by separating where the failure happened
A clean OTP investigation slices the failure into one of four segments and works backwards from the most downstream signal. Segment 1: failed at submission — the platform rejected the call before it ever left, almost always a malformed sender ID, an unregistered template category, an unsupported country, or a missing required field. Segment 2: accepted at submission but never delivered to the destination SMSC — usually a route-quality issue or a firewall block. Segment 3: delivered to the SMSC and returned a negative DLR — content filtered, sender ID blacklisted at the operator, recipient blocked. Segment 4: positive DLR but the user reports no message — handset off, ported to a different operator with stale routing, OS-level spam filter, or notification suppressed. The remediation differs in each segment; conflating them sends teams down the wrong rabbit hole.
The seven common causes, and what to do about each
1. Sender-ID rejection
Many regulated markets — UAE under TDRA, Saudi Arabia under CST, Egypt under NTRA, India under TRAI's DLT — require every alphanumeric sender ID to be pre-registered against a verified legal entity. Traffic sent under an unregistered ID is rejected at the operator boundary and produces a negative DLR with no message delivered, but the submission response was 202. The fix is registration, and the diagnostic is to correlate UNDELIV/REJECTD against the sender ID and the destination country: if every failure shares one sender ID in one country, registration is your problem. See the sender-ID registration guide for GCC markets for the specific paperwork.
2. Grey-route hops
Cheap international routes often involve one or more re-injection hops through partner aggregators or SIM-farm terminations. Each hop adds latency, raises the probability of silent drop, and increases the chance the destination operator firewall categorises the traffic as unauthorised A2P and blocks it. The signature is high UNDELIV rate, high latency variance, and a delivery rate that drops sharply when the destination operator deploys or upgrades a SMS firewall. The fix is to move OTP onto a direct operator route; the trade-off is discussed in direct routes versus grey routes.
3. Throttling at the SMSC or firewall
Every operator and every firewall imposes a per-sender-ID and per-route TPS ceiling. Burst beyond it and messages are either rejected immediately (best case — you see the failure) or queued and delivered late (worst case — they arrive after the OTP has expired and the user has already given up). The diagnostic is to look at submission spikes against latency p95: a stable latency curve under steady load that spikes during bursts indicates throttling. The fix is rate-limiting at the application layer to smooth bursts, and negotiating a higher TPS ceiling for OTP-class traffic specifically.
4. Content filters
Operator and firewall content classifiers can flag OTP templates that contain trigger words, URLs (most operators are aggressive about unverified shortlinks in transactional content), unusual sender names, or layouts that resemble known phishing patterns. The signature is a single template suddenly seeing elevated REJECTD rates while everything else routes fine. The fix is template hygiene: short, conventional OTP copy, no shortlinks, no urgency-tinged language. If the template is regulated (in some markets transactional templates must be pre-registered), make sure the registered version matches the version being sent — small variations get caught.
5. Encoding mismatch
OTP templates with a non-ASCII character (an accented vowel, a special quotation mark pasted from a design doc, an Arabic digit) silently upgrade the message from GSM-7 to UCS-2, shrinking the per-segment character budget from 160 to 70 and causing concatenated messages that some older handsets reassemble incorrectly. The diagnostic is to inspect the actual rendered template byte-by-byte, not the template as the developer thinks it looks. The fix is encoding-aware template review and a build-time check that flags any non-GSM-7 characters in a transactional template.
6. Network congestion
Destination operator SMSCs occasionally back up during major events (Eid, Black Friday, national holidays, large outage incidents) — submissions are accepted but delivery latencies climb from sub-second to many minutes. There is no clean remediation from the sender side; the mitigation is to detect the condition (a sharp climb in latency p95 across all routes to one operator) and fall through to an alternate channel before the OTP window closes.
7. Handset unreachable
A small but persistent fraction of OTP failures are not infrastructure at all — the handset is off, out of coverage, in airplane mode, has the operator's spam filter blocking unknown senders, or was ported to a new operator and the routing tables have not converged. The signature is EXPIRED or UNKNOWN DLRs scattered across all routes and sender IDs with no operator concentration. The fix is the fallback chain discussed below.
Build the diagnostic dashboard once, use it forever
Most OTP investigations stall because the team is reading raw logs under pressure. The teams that recover quickly have a standing dashboard with five widgets: DLR-status distribution by destination operator (the single most useful chart), end-to-end latency p50/p95/p99 per route, sender-ID-level delivery rate, content-template-level delivery rate, and a real-time submission-to-delivery time-series for the last hour. Build these once. They make the difference between a forty-minute diagnosis and a four-hour one.
Remediation patterns that actually work
Direct binds for OTP only
Bulk marketing traffic and OTP traffic must not share a bind or a route. Marketing is cost-sensitive, latency-tolerant, and can ride wholesale routes; OTP is latency-critical, deliverability-critical, and needs the direct bind. Sharing them means a marketing burst congests the OTP path and a marketing template trip-filter taints the route reputation for OTP.
Fallback chain, automatic and time-boxed
Architect for the assumption that any single channel will sometimes fail and design the fallback chain accordingly: WhatsApp Authentication template or RCS first when the user is reachable on either, SMS as the universal fallback, voice OTP as the last resort. The fallback must be automatic (no manual retry by the user), time-boxed (the wait before failover is shorter than the patience window of the user — typically 8 to 15 seconds), and conditional (do not fall over on a positive DLR; do fall over on a timeout or a negative DLR). And the OTP code itself must be generated once and reused across channels so the user is not presented with two valid codes.
De-duplicate every retry
When the user taps 'resend' or the application auto-retries, check before you send again. The BroadNet API does not take an idempotency key, so de-duplication lives in your code: record each send before you make it, keep the message ID the API returns, and check that message's status before any resend (see idempotency & safe retries). Without that check, a slow but successful first send and an automatic resend produce two OTPs in the user's inbox, the user uses the older one, verification fails, and the team blames the OTP service when the bug was in the retry logic.
Voice fallback for the long tail
Roughly one percent of users on any given day will not receive an SMS for any of the reasons above, and that one percent is the long tail that calls support. A voice OTP — a call that reads the code aloud — clears almost all of them. It is the difference between an annoyed user who tries another browser and a lost user who gives up.
BroadNet's OTP service handles the direct-bind, fallback chain, and voice escalation behind a single API call, returns a message ID you can check before any resend — and exposes the per-channel, per-operator DLR breakdown the diagnostic guide above depends on.
What good looks like, in numbers
A well-instrumented OTP system, sending into a regulated GCC market on direct operator routes, with a working fallback chain, should deliver: 99.0%+ end-to-end completion rate (the user successfully verified, not just that the message was delivered), sub-five-second p95 latency on the primary channel, and a measurable but small (1-3%) fallback-rate to the secondary channel. If your numbers are materially worse, the problem is almost certainly one of the seven causes above — diagnose, do not guess.
Related reading
- SMS API versus SMPP — which is better for enterprises?
- How banks should monitor OTP delivery and fraud
- How flash-call verification affects operator A2P revenue
- Glossary — what is OTP, what is a DLR, what is flash-call verification
- Product pages — OTP service and MyOTP voice OTP
- Coverage — UAE A2P SMS and OTP routing