How to choose an SMS gateway provider: a buyer's checklist
Choose an SMS gateway provider by scoring five measurable criteria—route quality and DLR honesty, sender-ID handling per market, all-in pricing transparency, signup and payment friction, and support depth—then validating each with handset tests before you commit volume. A gateway is a routing layer, not a guarantee; the checklist below turns marketing claims into observable outcomes.
What an SMS gateway actually does
An SMS gateway accepts your API call, normalizes the destination to E.164 (max 15 digits), selects a downstream route toward the handset’s home network, and returns a delivery report (DLR) when the network or an intermediate hop supplies one. That is the entire job: ingress, route selection, egress, and status feedback. It does not own the radio path, does not control handset firmware, and cannot force a foreign operator to accept a message or a particular sender identity.
Payload limits still follow the usual encoding rules: 160 characters for a single GSM-7 segment, 153 per segment when concatenated; 70 for a single UCS-2 segment, 67 when concatenated. The gateway may split, reassemble identifiers, and map your status webhooks—but delivery ultimately depends on the quality and honesty of the routes it buys. Understanding this boundary keeps evaluation focused on routing behavior and reporting, not on slogans about reach.
SMSRoute's own answers to this checklist are published: rates from $0.004, United States $0.0125 all-in, 149 countries, email-only signup, prepaid settlement, send-only.
The five criteria that decide outcomes
Route quality and DLR honesty. Quality means messages reach the intended handset on routes that preserve content and identity; honesty means the DLR you receive reflects a real network event rather than an early “accepted” forged at an intermediate hop. Ask how failure codes are passed through and whether “delivered” is ever emitted without a terminating-network ack. Vague answers here are a signal.
Sender-ID handling per market. Some countries allow alphanumeric sender IDs with pre-registration; others overwrite them with short codes or numeric trunks; still others require local entity paperwork before any commercial traffic moves. A usable provider documents per-destination behavior instead of implying one global rule. If your brand name must appear unchanged in a given market, treat preservation as a testable property, not a brochure line.
Pricing transparency (all-in vs floor). A floor rate that excludes failed attempts, off-net surcharges, or sender-ID fees is not comparable to an all-in rate. Prefer published price lists that state what is included per destination. SMSRoute publishes rates from $0.004, with US at $0.0125 all-in, across 149 countries—use any published list the same way: read the inclusions, then reconcile invoices against your own attempt logs.
Signup and payment requirements. KYC depth, card-only billing, minimum monthly commits, and contract length change time-to-first-message and lock-in. SMSRoute’s model is email-only signup, prepaid crypto settlement, and send-only traffic (no receiving numbers). Other vendors will differ; map requirements to your compliance posture and cash-flow preferences rather than assuming one pattern fits every product stage.
Support and documentation depth. You need API reference that matches production behavior, status-code dictionaries, and a path to a human who can read a message-ID when a route degrades. Thin docs and ticket-only support with multi-day lag are acceptable for low-stakes bulk; they are not acceptable for OTPs or time-critical alerts. Judge depth by whether you can debug a single failed send from public materials alone.
| Criterion | What “good” looks like | Red flag |
|---|---|---|
| Route quality & DLR honesty | DLRs map to terminating events; failures retain useful codes | All submits become “delivered” within milliseconds |
| Sender-ID per market | Written per-country rules; registration paths named | “Supported worldwide” with no country notes |
| Pricing transparency | All-in destination rates; invoice matches attempts | Floor rate plus unexplained monthly deltas |
| Signup & payment | Requirements stated before traffic | Hidden KYC mid-onboarding or surprise commits |
| Support & docs | Accurate API docs; reachable escalation on message-IDs | Generic FAQ only; no way to trace one SMS |
How to test each criterion before committing volume
Do not trust a dashboard demo. Build a small testing cluster of real handsets (or SIMs you control) across the operators you care about, send from your candidate gateway with fixed payloads, and record outcomes yourself. Handset-confirmed delivery is the ground truth: compare the phone’s inbox timestamps and content against the gateway’s DLR. If the API says delivered and the handset never shows the message, the route or the report is wrong—stop scaling that destination.
Sender-ID preservation is a separate check. Submit the same alphanumeric or numeric identity to each target country and photograph or log what the handset displays. Encoding and concatenation matter here too: exercise GSM-7 at 160 and 153 boundaries and UCS-2 at 70 and 67 so you see whether segments arrive in order with content intact.
Latency belongs in percentiles, not averages. Capture submit-to-handset time for each test set and report p50 and p95. Averages hide long tails that break OTP UX. Measure at the hours your users actually receive messages; route behavior varies by destination and time of day, so treat any single number from a sales call as unverified. Repeat the same battery after every route or account change the vendor announces.
The SMSRoute testing cluster documents how to verify each deliverability criterion yourself.
Questions to ask any vendor (phrased so vagueness shows)
Ask questions that require operational detail. If the reply could apply to any provider, you do not yet have an answer. Useful prompts include: “For destination X, is ‘delivered’ gated on a terminating-network ack, and can I see a sample raw DLR payload?” “Which sender-ID forms survive unchanged on operators A/B/C, and what registration IDs must already exist before you accept traffic?” “Is the listed rate all-in per successful submit, per attempt, or per delivered DLR—and which surcharge classes appear on invoices?”
Continue with process and limits: “What identity documents and business proofs are required before the first live send, and which payment instruments settle prepaid balance?” “Walk me through tracing one message-ID from my submit to the last hop you see—what will support ask me for?” “Do you provide inbound numbers or MO routing, or is the product send-only?” SMSRoute, for example, is send-only with no receiving numbers; knowing that up front avoids redesign later.
Write the answers down next to your handset test results. A precise verbal claim that fails on device is still a fail. A refusal to describe DLR provenance or sender-ID registration is itself data: it means you will discover behavior only in production.
When a big-brand CPaaS is right—and when it is not
A large CPaaS is often the right answer when you need bundled voice, verify SDKs, inbound numbers, multi-channel orchestration, enterprise contracting, and a single vendor security review. If your roadmap depends on receiving SMS, managing two-way sessions, or tying SMS to other products under one MSA, the broader platform can reduce integration surface even when per-SMS rates are higher than a specialist gateway.
It is not automatically right for send-only traffic where you already own UX, retry logic, and compliance paperwork. In that shape, a thinner gateway with published rates, clear DLR behavior, and low signup friction can be enough. SMSRoute’s honest position fits that niche: published rates from $0.004, US $0.0125 all-in, 149 countries, email-only signup, prepaid crypto settlement, send-only—no receiving numbers. It is not a full CPaaS and does not claim guaranteed delivery or best-in-market routes; you still run the handset tests.
Regulated domestic programs need registration whoever you use. US 10DLC brand and campaign registration, India DLT principal/entity/template registration, and similar regimes in other markets attach to the traffic and the sender—not to the logo on the API. A big brand may host the filing workflow; a specialist gateway may require you to complete the same filings before routes open. Neither removes the obligation. Budget time for registration outside the gateway decision, then pick the egress path that passes your tests in the countries you actually send to.
SMSRoute's comparison methodology page states plainly what we refuse to compare.
Frequently asked
- What does an SMS gateway provider do?
- It accepts your API submit, routes the message toward the destination network using E.164 addressing, and returns a DLR when upstream hops provide one. It does not control the handset radio path and cannot honestly promise delivery on every attempt.
- How should I test an SMS gateway before sending production volume?
- Use handsets you control on the target operators. Confirm inbox delivery and content against DLRs, check that sender IDs appear as submitted, exercise GSM-7 (160/153) and UCS-2 (70/67) segment boundaries, and record submit-to-handset latency as p50 and p95. Trust device outcomes over dashboard labels.
- Do I still need 10DLC or DLT registration if I use a third-party gateway?
- Yes. Programs such as US 10DLC and India DLT apply to the traffic and sender identity regardless of whether you use a large CPaaS or a specialist send-only gateway. The provider may assist with filing, but registration remains required before compliant routes will carry the traffic.