SMS verification looks like a small feature. Send a code, check the code. In Nepal it carries a set of local constraints that are not obvious until messages start failing, and by then you have usually built the wrong thing.
Why SMS still matters here
Nepal’s mobile market is effectively a duopoly. Nepal Telecom held 51.27 percent with 14.9 million subscribers as of January 2024, and Ncell held 48.73 percent with 14.5 million. Smart Telecom, formerly the third operator, ceased operations.
That matters for a practical reason: you must reach both networks reliably, and a gateway configured well for one is not automatically good for the other.It is also fair to note that messaging apps such as Viber and WhatsApp dominate in urban areas. But SMS remains the channel that reaches everyone, including users in rural areas with limited internet connectivity. If your service is for Nepali users generally rather than for Kathmandu professionals specifically, SMS is still the baseline.
Sender ID registration is not optional
This is the single most common cause of a Nepali SMS integration that appears to work in testing and then fails in production.
Nepal Telecommunications Authority rules require businesses to use a registered sender ID rather than an arbitrary number. Messages go out from either a shared sender ID or your own dedicated one. If your sender ID is not registered, operators may overwrite it with a generic alphanumeric string, or block the messages entirely.
There is a second layer. Providers must route commercial application-to-person traffic through authorised channels. In July 2025, corresponding to Shrawan 1, 2082 in the Nepali calendar, the NTA directed operators not to terminate unauthorised A2P SMS. In practice that means a cheap provider using unofficial routing will see traffic filtered, and you will see intermittent, unexplained delivery failures.
So when comparing providers, price per message is the wrong first question. Ask whether they route through authorised channels, whether they will register a dedicated sender ID for you, and whether they deliver to both NTC and Ncell. A cheaper provider whose messages arrive half the time costs far more than the price difference.
The NTA also sets a quality expectation of SMS delivery within 30 seconds across operators. Use that as your benchmark when testing, not as a guarantee.
Devanagari halves your message
Here is a Nepal-specific detail that surprises most developers and quietly doubles some SMS bills.
SMS messages using the standard GSM-7 alphabet split after 160 characters. Messages containing characters outside that alphabet, which includes all Devanagari, use UCS-2 encoding and split after 70 characters.
So a friendly Nepali OTP message that reads comfortably on screen may be billed as two or three messages rather than one. At OTP volumes, that is a meaningful cost difference for no functional gain.
The practical guidance is straightforward. Keep OTP messages in plain Latin characters and keep them short. A code, your business name and an expiry time is enough, and it fits comfortably within one message. Save Nepali language for messages where the wording genuinely matters to the reader, and accept the cost there deliberately.
Watch out for invisible offenders too. A single curly quotation mark or an emoji is enough to push an otherwise plain message into UCS-2 encoding and cut your limit to 70 characters. If your message template is generated by a CMS that converts straight quotes automatically, check the actual bytes being sent.
How should you actually build OTP verification?
The sending is the easy half. These are the parts that determine whether your implementation is secure.
- Generate the code server-side using a cryptographically secure random function, not a simple random number generator, and use at least six digits.
- Store a hash of the code rather than the code itself, and store the expiry time alongside it. If your database is ever exposed, plaintext codes are an immediate problem.
- Expire codes quickly. Five minutes is generous for an SMS that should arrive within thirty seconds.
- Invalidate the code the moment it is used successfully, and invalidate any previous code when a new one is issued.
- Limit verification attempts. Five wrong attempts should lock that code entirely and require a new one. Without this, a six digit code is trivially brute forced.
- Rate limit requests per phone number and per IP address, with a cooldown before a resend is allowed.
- Never log the code. Application logs, error reports and third-party monitoring tools all end up somewhere you did not intend.
One design point worth stating plainly. SMS OTP verifies possession of a phone number, not identity. It is reasonable for confirming a contact number or reducing spam registrations. It is weaker than people assume for protecting anything valuable, because SIM swap and interception attacks exist. For genuinely sensitive access, treat SMS as one factor among several rather than the whole security model.
SMS pumping is the attack nobody plans for
This deserves its own section because it costs real money and most Nepali implementations have no defence against it.
The attack is simple. An attacker finds your public OTP endpoint and requests codes repeatedly for numbers they control or numbers on networks where they earn a share of the traffic revenue. Every request costs you a message. There is no data breach and nothing looks broken. You simply receive a bill far larger than your user numbers justify.
Defences that work, roughly in order of effectiveness:
- Rate limit per phone number, per IP, and globally. A cap on total daily sends is a crude but effective backstop.
- Require something before the OTP request, such as a completed form or a challenge, rather than exposing a bare send endpoint.
- Block or throttle number ranges you do not serve. If your service is Nepal only, you have no reason to send to arbitrary international numbers.
- Alert on volume anomalies. A sudden spike in send volume should reach a human quickly, not appear on a monthly invoice.
- Enforce a resend cooldown in the backend, not only by disabling a button in the interface.
That last point matters more than it sounds. A greyed-out resend button stops an honest user and stops nobody else. Every limit must exist on the server.
Can users reply to your messages?
Generally not, and building on the assumption that they can is a costly mistake.
Standard international SMS gateways do not support two-way SMS in Nepal. Nepal Telecom does offer interactive SMS services, used for things like examination results and polling, but commercial operation requires NTA approval and passing technical tests first.
So plan around one-way communication unless you have specifically arranged otherwise. If your design depends on a user replying YES to confirm something, replace it with a link or an in-app action before you build it.
This is also worth remembering when you evaluate international SMS providers with impressive feature lists. Features that work in other markets may simply not function here.
When messages do not arrive
A diagnostic table, because the symptoms map fairly reliably to causes.
| Symptom | Most likely cause | What to check first |
| Nothing arrives at all | Sender ID not registered, or unauthorised routing | Whether your sender ID is approved with the operator |
| Sender shows as a random string | Unregistered ID overwritten by the operator | Register a dedicated sender ID |
| Arrives on one network, not the other | Routing configured for one operator only | Test on both NTC and Ncell numbers |
| Message arrives split into pieces | Devanagari content forcing UCS-2 encoding | Message length against the 70 character limit |
| Delivery slow or inconsistent | Grey routing or gateway rate limits | Whether your provider uses authorised A2P routes |
| Works in testing, fails at volume | Rate limits on your account | Your provider’s per-second send limits |
Two testing habits prevent most production surprises. Always test on both an NTC and an Ncell number, because a route that works on one is not evidence for the other. And test with a real message at real length, not with the word test, since encoding and splitting problems only appear with actual content.
Is Viber or WhatsApp a better channel?
For some audiences, yes, and it would be dishonest to push SMS where a messaging app serves better.
Messaging apps dominate in urban Nepal, cost less than SMS at volume, and support richer content. Some Nepali bulk providers now offer Viber and WhatsApp delivery alongside SMS through the same platform.
The trade-off is reach and reliability. A messaging app requires the user to have that app, an account, and a working data connection at the moment your message arrives. SMS requires none of those. For an OTP, which is time-critical and must not fail, that difference is decisive.
A reasonable pattern for a consumer service is to attempt the cheaper channel first where you know the user has it, and fall back to SMS when it fails or when speed matters. For most Nepali sites, though, starting with SMS alone and adding channels later is the simpler and more reliable choice.
What this means for your server
Little, in infrastructure terms, but two points are worth stating.
Your OTP endpoint is a public endpoint that spends money on every request. Treat it with the same care as a payment endpoint: rate limited, monitored, and logged with enough detail to investigate abuse without recording the codes themselves.
Keep your gateway credentials out of your codebase and out of version control, in environment configuration. Any reasonable web hosting in Nepal setup supports this, and it is the difference between rotating a leaked key and rebuilding an integration. The same verification discipline applies to payment callbacks, which we cover in our guide to accepting online payments in Nepal.
Frequently asked questions
Most often the sender ID is not registered, so operators either overwrite it with a generic string or filter the message. The other common cause is a provider using unauthorised A2P routing, which produces intermittent failures that are hard to diagnose. Check registration first, then routing.
Devanagari characters fall outside the GSM-7 alphabet, so the message uses UCS-2 encoding and splits after 70 characters instead of 160. A Nepali message can therefore be billed as two or three messages. Keep OTP messages in plain Latin characters.
About five minutes. The NTA quality expectation is delivery within 30 seconds, so a longer window mostly widens the attack surface. Invalidate the code as soon as it is used, and invalidate the previous code whenever a new one is issued.
On its own, no. SMS OTP verifies possession of a phone number rather than identity, and SIM swap and interception attacks are real. It is reasonable for confirming a contact number or reducing spam signups. For anything valuable, treat it as one factor among several.
Rate limit per phone number, per IP and globally, enforce a daily cap, require a completed form before the send endpoint is reachable, block number ranges you do not serve, and alert on volume spikes. Every limit must be enforced on the server, not by disabling a button.
