How to Test a Wholesale SMS Route

A rate sheet tells you what a route costs. It tells you nothing about whether the message arrives, whether the sender ID survives, or whether the delivery receipt you get back is describing reality. The only way to know those things is to send traffic and measure what comes out the other end.

Most wholesale suppliers will fund a small test. What separates a useful test from a wasted one is deciding, before you send anything, what you are going to measure and what result would make you walk away.

Agree the terms of the test first

Before any credit is issued, get four things in writing:

• Which route. Suppliers often carry more than one route per destination at different price points. A test on the premium route followed by delivery on a cheaper one is the oldest trick in wholesale messaging. Ask for the route ID or the rate-sheet line the test corresponds to.
• Which sender IDs. Alphanumeric, numeric, or short code. Whether registration is required and who does it.
• How the test is delivered. An SMPP bind or an HTTP API. If you will run production over SMPP, test over SMPP: the two paths inside a supplier’s platform are not always the same.
• What counts as a pass. Write down your thresholds before you see the numbers. Deciding afterwards is how a mediocre route gets approved.

The eight things worth measuring

1. Actual delivery, not reported delivery

A delivery receipt saying DELIVRD is a claim, not proof. Test to handsets you or a testing service physically control, and compare what the DLR says against what actually landed. The gap between the two is the single most useful number your test will produce.

2. Sender ID preservation

Send with the exact sender ID you intend to use in production and check what displays on the handset. Overwritten sender IDs, a numeric long code replacing your brand name, or an inserted prefix all change how your traffic performs commercially, even when delivery looks fine.

3. Content integrity

Send at least four message shapes: plain GSM-7 within 160 characters, a concatenated GSM-7 message over two or three parts, a Unicode message in the local script of the destination, and a message containing a URL. Check that concatenation reassembles correctly on the handset, that Unicode is not transliterated into Latin characters, and that the URL is not rewritten.

4. Latency, measured end to end

Record the time from submit to the handset actually receiving the message, not from submit to the DLR. Note the spread as well as the average. A route with a good average and a long tail is worse for one-time passwords than a slightly slower route that is consistent.

5. Whether the DLRs are honest

Watch for receipts that arrive suspiciously fast, receipts that arrive in a uniform block, and a delivery percentage that never moves regardless of what you send. Send a handful of messages to numbers you know are switched off or invalid and confirm you get a realistic failure back. A route that reports success for a number that cannot receive anything is reporting fiction.

6. Throughput under load

A route that behaves at five messages per second may queue badly at fifty. If you have a peak, test at your peak. Ask what submit rate the bind is provisioned for and confirm the platform enforces it cleanly rather than silently dropping.

7. The route type behind the price

Ask directly whether the route is a direct operator connection or transits an intermediary, and compare that answer against what the test shows. Sender ID rewriting, Unicode being stripped, and inconsistent latency are all consistent with traffic taking a longer path than the rate sheet implies.

8. How the supplier responds when something breaks

Deliberately raise a ticket during the test window, a genuine question about a failed message is enough. The response time and the quality of the answer during a trial is the best behaviour you will ever see from that supplier. Production will not be better.

Building a test that means something

Three design choices decide whether your numbers are trustworthy:

Spread across operators. A destination is not one route. Delivery on one operator tells you nothing about a competitor’s network in the same country. Split your volume across every operator you actually send to.

Spread across the day. Send in the local morning, afternoon and late evening. Congestion, filtering behaviour and operator maintenance windows are not constant.

Use enough messages. Ten messages per operator cannot distinguish a 95% route from an 80% route with any confidence. A few hundred per operator, spread over several days, produces a number worth acting on.

Keep the raw log. Message ID, submit timestamp, DLR timestamp, DLR status, sender ID sent, sender ID received, and handset confirmation. When you go back to the supplier with a problem, a log is an argument and an impression is not.

What should end the conversation

Some findings are worth a discussion. Others are not:

• Delivery receipts that report success for numbers that provably received nothing.
• Sender ID replaced without that being disclosed in advance.
• Unicode silently converted to Latin script, which makes local-language traffic unusable.
• A refusal to say whether the route is direct, or an answer that changes between conversations.
• Test performance that cannot be reproduced a week later on the same route.

The last one is worth taking seriously. Ask to repeat a short version of the test after a few days on the production route, before you commit volume. A route that only performs while it is being watched is a route you will be diagnosing for months.

After the test

Whatever you agree, get the route type, the sender ID handling and the throughput written into your commercial terms rather than left in an email thread. Then keep measuring. Wholesale routes change, capacity is re-sold, intermediaries are added, operators change filtering rules, and the route you tested in March is not automatically the route you are on in September.

When you are ready to run one, we issue funded test routes on the route you would actually buy, over SMPP or the HTTP API. See what is live per destination on the coverage list.