The layer between your application and Maxis, CelcomDigi, U Mobile, YES and Unifi. What it does, what can go wrong in it, and how to tell a serious one from a reskinned dashboard.
You cannot hand a message to Maxis yourself. A gateway holds the commercial and technical connections to the operators and does four jobs on your behalf: takes your submission, picks a route to the recipient's network, hands the message over, and collects the delivery receipt that comes back.
Every problem you will have with bulk SMS lives in one of those four steps. Knowing which one is failing is most of the work of fixing it.
Malaysian numbers are portable, so the prefix no longer reliably tells you which network a number is on. The gateway resolves that and routes accordingly. Where routes differ is in quality:
This is the single biggest quality difference between providers, and it is invisible on a pricing page. A price far below the local market usually means the route is not local. The symptom is familiar: a dashboard that shows near-100% delivery while your customers say nothing arrived.
A delivery receipt (DLR) travels back from the handset's network through the operator to the gateway to you. Each hop can report early. That produces the three-stage confusion at the centre of most billing disputes:
| Stage | Who reports it | What it proves |
|---|---|---|
| Submitted | The gateway | It accepted your message and billed you |
| Accepted | The operator | The network took it — not that a phone did |
| Delivered (DLR) | The handset's network | It reached the device |
A gateway that reports stage 1 as "delivered" will show you a perfect dashboard regardless of reality. The diagnostic is blunt: ask for a campaign report where submitted and delivered are different numbers. If a provider cannot produce one, they are not passing through real receipts.
Also ask what happens when no receipt ever arrives. Some operators simply never return one for a portion of traffic — an honest gateway tells you the receipt is missing rather than assuming an outcome in whichever direction flatters the statistics.
Throughput is capped by the operator route, not by the gateway's marketing copy. What matters more than peak speed is how the queue behaves when something goes wrong: a gateway that drops the remainder of a batch when a route hiccups is a different product from one that retries the unsent portion without re-sending what already went out. Ask specifically what happens to a 5,000-number batch if the route fails halfway.
| Method | Good for | Trade-off |
|---|---|---|
| Web console | Occasional campaigns, non-technical users | Manual, not repeatable |
| REST API | Application-triggered sending | Needs a developer once |
| SMPP | Very high sustained volume | Persistent connections, heavier to operate |
For almost everyone below carrier-scale volume, REST over HTTPS is the right answer — no persistent connection to babysit, and it works from any stack. Ours is documented at the API reference, with the selection-level summary on the SMS API page.
The last one is the cheapest and most revealing. Any provider confident in their route will let you send to your own handset before you spend money.
A service that connects your system to mobile operators so you can send SMS programmatically or from a web interface. It handles routing to the right network, submission to the operator, and returning the delivery receipt. You cannot connect to Maxis or CelcomDigi directly as an ordinary business, which is what the gateway is for.
In practice the terms are used interchangeably in Malaysia. "Gateway" emphasises the technical connection, "aggregator" the commercial relationship with multiple operators. What matters is not the label but whether the routes are direct local routes and whether the delivery receipts they pass to you are genuine.
Usually the route. Traffic entering Malaysia through international or grey routes costs less and delivers worse — sender ID can be rewritten, filtering is heavier, and delivery receipts may be generated at an intermediate hop rather than by the handset network. A dashboard showing near-perfect delivery while customers report nothing arriving is the classic symptom.
Almost certainly not. SMPP makes sense at sustained carrier-scale volume where the overhead of persistent connections pays for itself. For everything below that, a REST API over HTTPS is simpler to build against, easier to debug and works from any stack.
Send real messages to handsets on at least two different Malaysian networks, then read the per-number delivery report and check the submitted and delivered numbers are not identical. Any provider that will not let you send a real test before payment has told you something useful.
Trial credit and a real delivery report per number — the only test that tells you anything.