SMS gateway cost per message: the all-in breakdown
US traffic on SMSRoute is $0.0125 per message all-in; destinations floor from $0.004 across 149 countries. Landed cost is list price × billed segments × what actually accepts—not the headline rate alone. This page is the arithmetic that turns a published price into a budget line. Vocabulary lives on the pricing-explained page; here we only multiply.
List price is not landed cost
Buyers searching sms gateway cost, charges, rates, or server price usually have a unit figure in hand and need the all-in number that hits the ledger. The published SMSRoute anchors are plain: United States at $0.0125 per message all-in, a floor from $0.004, coverage in 149 countries. Everywhere outside those anchors, the rate varies by destination and must be measured rather than assumed. List price is the starting multiplier. Landed cost is what remains after segment billing, submit outcomes, and account mechanics have done their work.
On routes you do not control end-to-end, other parties sometimes introduce their own line items—carrier surcharges, pass-through assessments, currency conversion spreads on the funding side, or minimums that change effective unit cost at low balance. This page does not invent fee amounts. Qualitatively, expect that a bare per-message quote can grow when the path includes intermediaries, when the message body forces multi-part encoding, or when rejected traffic is still metered. The honest posture is to treat the published unit rate as necessary but not sufficient, then close the gap with a controlled probe instead of a spreadsheet fantasy.
SMSRoute’s model for the US figure is stated as all-in at $0.0125 per message. That is the number used in the worked example below. For any other country, use the same arithmetic shape with the rate you actually observe. Do not import competitor figures, regulatory schedules, or guessed percentages into the model; they are outside the published facts and will falsify the budget.
SMSRoute publishes the number this page does arithmetic with: US $0.0125 per message all-in, floor from $0.004, 149 countries.
Billed segments multiply the unit rate
SMS is not billed by the logical notification you intended. It is billed by the segments the encoding produces. Under GSM-7, a single-part message holds 160 characters; once the body is concatenated, each part holds 153 characters because UDH overhead claims space. Under UCS-2, a single-part message holds 70 characters; concatenated parts hold 67 each. One emoji, one non-GSM character, or a string that cannot stay inside the GSM-7 alphabet flips the entire message to UCS-2. The flip is total, not partial: the whole payload re-encodes, and segment count jumps.
Cost arithmetic follows directly. If the published per-message rate is R, and a submit produces P billed parts, that submit contributes P × R when it is billable. A 300-character GSM-7 body is not “one message at R”; it is two concatenated parts (153 + 147) and bills as 2 × R if accepted under per-part metering framed the same way as the published per-message unit. A short plain-text OTP stays at one part. The same OTP with a trademark symbol or emoji that forces UCS-2 can become two parts inside a body that still looks short to a product manager. Segment count is a property of encoding and length, not of product intent.
Work the bounds before you ship templates. Stay inside GSM-7 when the destination and copy allow it. Count characters after substitution (names, codes, URLs), not before. Treat any Unicode outside the GSM-7 set as a full UCS-2 conversion. For planning, model 1-, 2-, 3-, and 4-part cases explicitly; four parts is already a large concatenated body and should be rare for transactional traffic. The multiplier is linear: messages × parts × per-message rate. There is no discount hiding inside concatenation.
Failed submits, currency, and top-up mechanics
Ask the operator a direct question before you scale: are rejected submits billed? Outcomes differ by platform. Some meter only carrier-accepted handoffs; some meter at accept-to-gateway; some meter attempts that fail validation after the HTTP transaction has already been accepted. The distinction matters because a destination with noisy numbering, aggressive filtering, or intermittent upstream capacity can turn a nominal unit rate into a much higher cost per delivered notification if failures still debit the balance. Do not assume courtesy credits. Read the rule, then confirm it on a probe where you intentionally include a share of known-bad destinations or malformed destinations and reconcile wallet delta against submit counts.
HTTP status is not delivery. A 200 on submit means the gateway accepted the request for processing; it is not a handset receipt. A 429 means you are being rate-limited and should back off; repeated 429 patterns belong in capacity planning, not in the unit-price cell of a spreadsheet. Delivery is a separate signal path when available. SMSRoute is send-only: no inbound numbers, and no guaranteed delivery. Build application logic around accept rate and downstream webhooks or status queries you actually have—not around a delivery SLA that is not on offer.
Funding mechanics change effective cost at the margin even when the unit rate is fixed. SMSRoute minimum top-up is $5. Supported crypto rails are BTC, ETH, USDT, XMR, LTC, and SOL. Top-up size, confirmation delay on chain, and how residual balance sits idle are operational facts: a $5 floor is friendly to testing, but production volume should size top-ups so you are not thrashing the funding path. Currency conversion, if you fund from a non-USD source on your side, is your treasury problem; keep it outside the SMS unit-rate model so you do not confuse FX noise with route pricing. Record balance before and after every probe so the wallet is the system of record for landed cost.
The SMSRoute testing cluster shows how to turn a 100-message probe into a real delivered-cost figure.
Worked example: US at $0.0125 per message
Use only the published US all-in rate of $0.0125 per message. Frame each row as that rate applied per billed message-part unit. Cost = messages × parts × $0.0125. The table below is arithmetic on that anchor alone—not a quote for other countries, not a tier schedule, and not a promise about accept rate.
Read the table as a planning scaffold. If your templates are single-segment GSM-7, the first data row is your expected unit. If copy or encoding pushes you to two or three parts, multiply before you celebrate the headline rate. If a 100-message probe later shows that only a fraction accept, divide the wallet debit by successful accepts (or by intended recipients, depending on which KPI you fund) to get cost per useful outcome. The rate did not change; the yield did.
| Billed parts per message | Messages in batch | Part-messages billed | Unit rate (US published) | Batch cost |
|---|---|---|---|---|
| 1 (e.g. short GSM-7) | 100 | 100 | $0.0125 | $1.25 |
| 2 (concat GSM-7 or UCS-2) | 100 | 200 | $0.0125 | $2.50 |
| 3 (long concat) | 100 | 300 | $0.0125 | $3.75 |
Measure before you commit volume
The honest method is empirical. For each destination you care about, send a 100-message probe that mirrors production templates: same encoding, same approximate length, same send window, same origin credentials. Record submits, HTTP outcomes (including any 429), billed segments as reported in CDRs or balance delta, and accept rate. Landed unit cost ~ (wallet debit) / (useful outcomes you define). Useful outcomes might be accepts, or accepts that later show a downstream delivered status if you have one—define the denominator explicitly so finance and engineering argue about the same fraction.
Repeat when templates change, when you add languages that pull in UCS-2, and when you open a new country. Rates outside the US published anchor vary; the probe is the price list. A floor from $0.004 across 149 countries tells you the bottom of the published range exists, not that your route sits there. Do not extrapolate one country’s probe to another. Do not scale from a ten-message smoke test; one hundred messages is enough to stabilize a rough accept rate without pretending to be a statistics paper.
Limits, stated plainly so the cost model is not mistaken for a product brochure: SMSRoute is send-only; there are no inbound numbers on this path; delivery is not guaranteed; test before volume. The $0.0125 US all-in figure and the $0.004 floor are the published price anchors used here. Segment constants are GSM-7 160 single / 153 concatenated and UCS-2 70 single / 67 concatenated. Everything else in a live integration—template drift, upstream filtering, your own retry policy—belongs in the probe ledger, not in an assumed discount. Multiply what is published, measure what is not, and only then convert a list price into a landed cost you can defend.
Frequently asked
- What is the SMS gateway cost per message on SMSRoute?
- United States traffic is published at $0.0125 per message all-in. Destinations floor from $0.004 across 149 countries; other routes vary and should be measured with a 100-message probe. Landed cost also multiplies by billed segments (GSM-7 160/153, UCS-2 70/67).
- How do concatenated SMS segments affect charges and rates?
- Billing follows parts, not intent. GSM-7 allows 160 characters in one part and 153 per part when concatenated; UCS-2 allows 70 and 67. One emoji can flip the whole body to UCS-2. Cost = messages × parts × per-message rate (for US, × $0.0125).
- Are failed SMS submits billed, and what is the minimum top-up?
- Failed-submit billing depends on operator rules—ask explicitly and confirm with a probe that reconciles wallet delta to submits. SMSRoute minimum top-up is $5; crypto funding options include BTC, ETH, USDT, XMR, LTC, and SOL. The service is send-only with no guaranteed delivery; test before volume.