Antbytelabs
Start a project
SMS and OTP in Nepal: What Actually Gets Delivered
Business

SMS and OTP in Nepal: What Actually Gets Delivered

AntbytelabsBusiness Strategy
October 7, 2026
4 min read
82 views

An SMS is not a function call that returns true. Why OTP codes arrive late or not at all, what expiry window to use, and why SMS must never be the only way into an account.

Key Takeaways

  • An SMS is not a function call that returns true.
  • Why OTP codes arrive late or not at all, what expiry window to use, and why SMS must never be the only way into an account.
Share:

The short answer

An SMS in Nepal is not a function call that returns true. It is a message handed to an aggregator, which hands it to NTC or Ncell, which delivers it when it delivers it. Most of the pain in OTP login comes from teams treating that handoff as instant and guaranteed, when it is neither.

Budget for a delivery rate below 100 per cent, build the retry path on day one, and never make SMS the only way into an account.

What actually goes wrong

The code arrives after the code expires

A 60-second expiry window is common and wrong for Nepal. Delivery can take seconds or it can take minutes, and on a busy evening it skews long. If your window is shorter than your worst realistic delivery time, you have built a login that fails for the people on the weakest networks, which is to say the people you most want as customers.

Five minutes is a reasonable starting point. Measure the actual delivery spread before you tighten it.

Nobody owns the sender ID

Alphanumeric sender IDs have to be registered, and the registration sits with the aggregator. Teams discover this in the last week of a project, when the messages have been arriving from a numeric shortcode nobody recognises and the client asks why their brand name is not on it. Start the registration early. It is paperwork rather than code, and paperwork takes longer.

The number format is inconsistent

Users type 98XXXXXXXX, +97798XXXXXXXX, 0098 and the rest, with spaces or dashes. Normalise to E.164 at the boundary, once, and store that. Doing it ad hoc in three places is how you end up with duplicate accounts for the same person, which is a support problem long before it is a technical one.

Design the failure path first

  • Resend, with a cooldown. Thirty to sixty seconds. Without a cooldown you have built a way to spend your SMS balance.
  • Rate limit per number and per IP. Someone will point a script at your OTP endpoint. SMS costs money, so this is a billing vulnerability as much as a security one.
  • A second route in. Email, a password, or WhatsApp. If SMS is the only door and the message does not arrive, the user has no way to reach their own account.
  • Log delivery status, not just send status. "We called the API" and "the message arrived" are different facts, and only one of them matters.

Cost adds up faster than people expect

At a rupee or so per message, SMS looks free in a spreadsheet. It stops looking free when every login, every password reset and every order update sends one, and when a third of them are retries because the first did not land.

Decide which events genuinely need SMS and which can be an in-app notification or an email. Order confirmations usually do not need to be SMS. A one-time code does. If your app is the main channel anyway, push notifications cost nothing per message and are worth wiring up properly.

Our notes on building for a bad connection cover the related problem of what the app should do when neither arrives.

Frequently asked questions

Which SMS gateway should I use in Nepal?

Test at least two before committing, from the networks your users are actually on, at the times they will use it. Delivery rate and latency vary more between providers than price does, and the cheapest per-message rate is a poor trade if a tenth of your codes never land.

Why do some OTP messages never arrive?

Operator filtering, an unregistered sender ID, a queue backlog at the aggregator, or the handset simply being out of coverage. You usually cannot tell which from your side, which is exactly why the retry path and the alternative login route matter.

How long should an OTP code be valid?

Start at five minutes rather than sixty seconds. A short window looks more secure and mostly just locks out people on slow connections. Tighten it only after you have measured real delivery times.

Do I need a registered sender ID?

If you want your business name on the message rather than a numeric shortcode, yes, and it is an application through your aggregator. Begin it at the start of the project, not the week before launch.

Is SMS login secure enough on its own?

For most consumer apps in Nepal it is the practical choice, because everyone has a number and not everyone has email. It is not strong authentication, so do not rely on it alone to protect money movement or administrative access.

Tags:
Nepal
SMS
Authentication
Mobile
Guide

Enjoyed this article? Share it with others!

Share:

Written by

Antbytelabs

Writing about the software we build at Antbytelabs in Bhaktapur, Nepal.

BusinessAntbytelabs · antbytelabs.com

Comments (0)

Leave a Comment

Your comment will be visible after moderation. Markdown formatting is supported.