An OTP SMS is the one message a business cannot afford to lose. It has seconds to arrive, it has to match a pre-approved template byte for byte, and it reaches a user who is already stuck at a login screen. This guide covers how OTP delivery actually works in India, the rules that apply specifically to one-time passwords, why codes go missing, and what to weigh before you pick a provider.
What an OTP SMS actually is
A one-time password is a short numeric code, valid for a single use inside a narrow time window, that proves the person completing an action controls a particular phone number. The SMS itself is ordinary — what makes it an OTP is everything around it: how the code is generated, how long it lives, and how quickly it is invalidated.
- Single use. Once redeemed, the code must be dead. Reusable codes defeat the entire purpose.
- Time-boxed. A short expiry limits how long an intercepted code is worth anything.
- Transactional category. OTPs are service-explicit messages, which is why they reach numbers on DND when marketing SMS cannot.
- Network-independent. SMS rides the carrier signalling layer, so the code arrives on a phone with no data connection at all.
How an OTP send works, end to end
The round trip has more moving parts than most teams expect, and each one is a place delivery can quietly fail.
- 1. Your server generates the code. Store a hash of it against the session with an expiry, never the plain value.
- 2. Your server calls the SMS API. The request carries the recipient, your registered sender ID, the approved template ID, and the code as a template variable.
- 3. The platform validates and routes. Template match is checked first, then the message is handed to the fastest available route for that operator.
- 4. The carrier delivers.The operator's SMSC pushes the message to the handset, holding it if the device is unreachable.
- 5. A delivery receipt comes back. A webhook confirms delivered or failed per message — this is the only honest signal that the code arrived.
The DLT rules that apply to OTP
India treats OTP traffic like all other business SMS: it must come from a registered entity, use a registered sender ID, and match a registered template. The template is where OTP senders trip up, because the approved text is matched exactly and only the declared variable slots may change between sends.
| What breaks | What the sender sees | What the user sees |
|---|---|---|
| Template text edited after approval | API returns success | Nothing arrives |
| Extra variable added to the message | API returns success | Nothing arrives |
| Sender ID not mapped to the template | API returns success | Nothing arrives |
| Filed under promotional category | Delivered, slowly | Code arrives late |
If you have not been through entity, header, and template approval yet, our DLT registration guide walks through each document, the realistic timelines, and the rejection reasons that catch most first-time senders.
Why OTPs go missing
When a user says the code never came, the cause is almost always upstream of their phone. Working through these in order resolves the majority of reports.
- Template drift. Someone changed the wording in code without re-filing the template. The commonest cause by a wide margin.
- Wrong category. An OTP filed as promotional gets batched behind marketing traffic and arrives minutes late, or during a blackout window, not at all.
- Carrier rate limiting. Repeated sends to one number in a short span get throttled at the operator.
- Handset-side filtering. Spam filters and blocked-sender lists on the device can swallow a legitimate code.
- Stale number. The number was ported, recycled, or simply mistyped at signup.
Working through that list depends entirely on the platform handing back a per-message delivery receipt rather than a single “accepted” response at send time. Real receipts are what the SMSLocal OTP SMS product reports back per code, which is the difference between knowing a message failed and guessing at it.
What SMS OTP does and does not protect
SMS OTP is a genuine improvement over passwords alone: it stops credential stuffing and reuse attacks outright, because a leaked password is no longer sufficient. What it does not stop is an attacker who controls the phone number or who relays the code in real time. SIM-swap fraud and convincing phishing pages both defeat it, which is why NIST's digital identity guidelines classify SMS as a restricted authenticator and push higher-risk flows toward app-based or hardware factors.
For most Indian consumer products SMS remains the right default, because reach beats theoretical strength when the alternative is no second factor at all. Tighten it where it is weakest:
- Keep expiry short and invalidate immediately on successful use.
- Rate-limit both requests per number and verification attempts per code.
- Bind the code to the originating session so it cannot be replayed elsewhere.
- Never read a code back to a user, and say so in the message itself.
Build versus buy
The API call is the easy part. What you actually take on by building is carrier relationships, DLT paperwork, route failover when one operator degrades, retry logic, delivery-receipt plumbing, and someone reachable at 2am when codes stop landing on one network.
| Concern | Build it yourself | Use a provider |
|---|---|---|
| DLT onboarding | Your team files everything | Onboarding support |
| Route failover | You negotiate and monitor | Handled upstream |
| Delivery receipts | You build the pipeline | Webhook out of the box |
| Time to first OTP | Weeks | Days |
For teams that want the second column, an established provider absorbs the DLT paperwork, the route monitoring, and the receipt plumbing — which leaves your codebase responsible for only two things: generating the code and verifying it.
