SMS providers compete on price per message, which is the least useful basis for comparison — the rates cluster closely and the differences that matter are operational.
Delivery latency, not just delivery rate
A provider quoting 98% delivery is not telling you when. For an OTP, a message arriving in ninety seconds has failed: the user has already requested another, and possibly abandoned the transaction.
Ask for typical latency on transactional routes, then measure it yourself during a trial — at peak hours, across the operators your users actually use. Aggregate dashboards hide exactly the cases that matter.
Per-message delivery reports with operator status
You need to know, for a specific message to a specific number, what happened: delivered, failed, rejected, and why. An aggregate percentage cannot answer a customer saying they did not receive their OTP.
Check that failure reasons are meaningful rather than a generic code, and that reports are available through the API rather than only in a dashboard.
How much DLT work they do
Header and template registration is the tedious part of Indian SMS. Providers differ substantially in how much they handle:
- Do they assist with entity registration, or only accept an existing one?
- Do they submit headers and templates for you?
- Do they validate a message against registered templates before sending, so you see an error rather than a silent rejection?
- How quickly are new templates typically approved through them?
That third point is worth weighting heavily. A provider that rejects a mismatched message with a clear error saves far more developer time than a small rate difference.
Retry behaviour you control
When a handset is unreachable, what happens? Is there a retry, how many, over what period, and can you configure it?
Defaults suit marketing. A time-sensitive OTP should not be retried twenty minutes later, when it is useless and potentially confusing.
Unicode handling and what it costs
Messages in Hindi or other Indian scripts use a different encoding with a substantially lower character limit per message segment. A message that fits one segment in English may take several in Devanagari — and you are billed per segment.
Ask how segments are counted and confirm the provider shows the segment count before sending. Regional language campaigns costing several times the estimate is a common and avoidable surprise.
API quality, which you will live with daily
- A sandbox that does not consume credits
- Meaningful HTTP status codes and error messages, not always-200 with an error in the body
- Webhooks for delivery status rather than polling
- Documentation with working examples
- Rate limits that will not throttle a legitimate burst — a result-day or fee-reminder send
Commercials worth checking
- Do credits expire?
- Are failed messages charged?
- Is there a minimum commitment?
- Are transactional and promotional priced separately, and routed differently?
- Can unused balance transfer if you upgrade?
Failed message billing is worth confirming explicitly. Policies vary and it is rarely prominent.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
