SMPP accounts for clients: binds, TPS, DLRs and billing

The moment a technical client asks “can I bind over SMPP?”, your platform stops being a web panel and becomes a carrier in their eyes. SMPP accounts for clients are the feature that wins banks, OTP vendors, other aggregators and any developer who already has an SMPP client library, and they are also where a sloppy setup hurts most: a client with no throughput cap, a receiver bind nobody configured, receipts that go nowhere, a ledger the bind bypasses. This guide is the checklist for doing it properly, from the bind you issue to the test you run before you tell the client to go live.

What SMPP accounts for clients actually are

Over the HTTP API a client sends one request per message and gets a response. Over SMPP the client opens a long-lived TCP session to your SMPP server, authenticates once with a system_id and password, and streams messages down that session as binary packets called PDUs. Your platform has to run an SMPP server (Smppcube’s listens on port 2775 and is drawn on the platform page), accept the bind, validate every submit_sm against the client’s account, queue it into the same pipeline the HTTP API feeds, and later push the delivery receipt back down the session as a deliver_sm.

So an SMPP account is not a separate product with its own billing. It is a credential on an existing client account plus a set of limits: which bind modes, from which IPs, how many sessions, how fast. The credential is the small part. The limits are the account.

Bind types and what to allow

SMPP defines three bind modes, and your account setup should say which the client may use:

• Transmitter: send only. The client submits messages and receives submit responses (the message ID) but nothing else. Simple, and the reason receipts get lost, because a transmitter has no channel for a deliver_sm.
• Receiver: receive only. The client gets delivery receipts and inbound messages (mobile-originated replies, if you route any to them) and cannot send.
• Transceiver: both on one session. This is what most modern client libraries open by default and what you should recommend, because one session carries sends and receipts together and there is nothing to mismatch.

The traditional pattern of one transmitter plus one receiver bind still exists, usually because an older client stack was written that way. Allow it, but count it as two sessions against the account’s limit, and make sure the receiver bind is actually open before you assume receipts are being delivered.

Session limits matter more than people expect. A client who opens ten transceiver binds “for redundancy” is holding ten slots of your server’s connection table and can push ten times the throughput you intended. Two to four sessions per account is a sensible default; a client who needs more is a client who should be on a higher package.

Throughput, windows and throttling

Throughput on SMPP is a function of two things: how many PDUs the client may have in flight before waiting for acknowledgements (the window), and the rate you allow. The SMPP versus HTTP guide explains why a single well-managed bind can push hundreds of messages per second; the point here is that on your platform, you are the one being pushed.

Give every SMPP account a messages-per-second cap that comes from the contract, not from what your server could do. A client paying for 10 msg/s gets 10 msg/s; when they exceed it, answer with the throttling error the protocol defines (ESME_RTHROTTLED) rather than quietly queueing the excess. A well-written client library treats that error as “slow down” and backs off. A badly written one keeps hammering, and your server should drop the bind after repeated violations and log why, because the alternative is that one client’s misconfigured retry loop becomes everyone’s latency.

Two more numbers belong on the account. A window size (10 to 20 unacknowledged PDUs is typical for a client-facing bind; carriers upstream may allow more) and an enquire_link interval, the heartbeat that keeps an idle session alive. Tell the client all three when you issue the credentials. The most common “SMPP is not working” ticket is a client library configured for a window your server does not grant, timing out on every tenth message and reporting it as a platform fault.

Where delivery receipts go

A delivery receipt (DLR) over SMPP is not a response to the client’s submit. It arrives later, unsolicited, as a deliver_sm on the client’s receiver or transceiver bind, and the client matches it to the original message by the message ID your server returned at submit time. Three things follow from that.

First, the receipt has to have somewhere to go. If the client is bound as transmitter only and has no receiver bind open, the receipt has no path. Decide the policy in advance: require transceiver binds, hold receipts for a short time until a receiver bind appears, or offer a webhook as the receipt channel for clients who cannot run a receiver. Silently discarding receipts is the one option that will come back as a dispute.

Second, the receipt is yours before it is theirs. Your platform needs the carrier’s receipt to settle the message on the ledger, to show the status in the client’s console and to feed your own delivery-quality reporting per route. Store it, update the message, and then forward it. A design that only relays receipts to the bind and keeps nothing is a design with no answer when the client says “you charged me for 4,000 messages that never arrived”.

Third, receipts arrive at roughly the rate the sends did, and a campaign’s receipts arrive after the campaign. A client who blasts 50,000 messages in five minutes will receive 50,000 deliver_sm packets over the next ten. If their receiver bind is slow to acknowledge, your outbound receipt queue grows; make it a queue with a visible depth rather than an unbounded buffer, and alert on age, so a stalled client bind shows up on your dashboard before the client opens a ticket.

Sender IDs, coding and the things clients get wrong

An SMPP account also needs a rulebook. Which source addresses (sender IDs) may the client use, alphanumeric or numeric, and does your server rewrite or reject an unknown one? Which data codings (GSM 7-bit versus UCS-2 for non-Latin scripts) and how are long messages split (UDH concatenation, which the client’s library usually handles but sometimes does not)? What validity period and what registered-delivery flag do you require so that receipts are requested at all?

These rules should live on the account and be enforced at submit time, returning a clear error code, rather than accepted and then failed silently at the carrier. In the same way that a good HTTP API returns a 400 with a reason, a good SMPP server rejects the submit_sm with the right status and lets the client fix their side. Every rule enforced at your edge is a dispute you do not have later.

Billing per bind: the account owns the ledger

This is the part that goes wrong when the SMPP server is bolted on beside the platform instead of built into it. A message that enters over SMPP must be priced and debited exactly like a message that enters through the console or the HTTP API: same rate plan, same balance, same margin recorded against the same route. The three billing modes from the billing guide (CreditRoute, WalletRoute and AutoRoute) apply to the account, and the bind inherits them. When the balance reaches zero, the SMPP server must reject the submit with an appropriate error rather than accept traffic into a queue that will never be paid for.

An SMPP bind is a door into the client’s account, not a separate account. If the ledger cannot see the door, the door is a leak.

Where SMPP does earn its own commercial line is the package around the bind: a minimum monthly commitment in exchange for a higher throughput cap, a fee per additional session, a premium for a dedicated route or a short code. Price those as account terms, so the ledger records the fee and the traffic on the same statement, and so a client who moves from HTTP to SMPP sees one invoice with one extra line, not a new relationship.

Onboarding a client: the credential pack

When a client is approved for SMPP, send one document, and make it the same document every time:

1. Host, port, and the TLS expectation if you terminate TLS in front of the SMPP server.
2. system_id and password (delivered through a channel other than the email that carries the rest).
3. Allowed bind modes and the maximum number of sessions.
4. The IP addresses you will accept binds from, and how to change them.
5. Throughput cap in msg/s, window size, enquire_link interval.
6. Allowed sender IDs, coding rules, long-message handling, required registered-delivery flag.
7. Where receipts go, and the error codes they should expect and handle.
8. The test route and the test numbers to use before go-live.

Half of these are numbers the client’s engineer will type into a config file in the next hour. Giving them all at once is the difference between a one-day integration and a two-week email thread.

Testing before go-live

Never turn a client’s SMPP account on against live routes. Provide a test route that accepts messages, generates a plausible receipt after a short delay and charges nothing, and walk the client through six checks on it: a bind in each allowed mode, a single message and its receipt matched by ID, a long message in a non-Latin script arriving as one message on a real handset, a burst above the throughput cap producing throttling errors and a correct back-off, a deliberately wrong sender ID producing the expected rejection, and a dropped connection followed by a clean reconnect. Only then switch the account to its live routes, and switch it with the cap still in place.

The same test route is what you use to reproduce a client’s problem later. A client who says “receipts stopped” can bind to the test route, send one message and watch the receipt come back in the console, which turns a vague ticket into a ten-minute check of their receiver bind.

When a client should not have SMPP

Not every client who asks for SMPP should get it. A marketing team sending from a browser has no use for a bind; a developer sending 300 OTPs a day is better served by the HTTP API, which needs no persistent session and returns errors they can read. SMPP is for clients with volume, with an existing SMPP stack, or with a compliance reason to keep a direct protocol relationship. Everyone else gets the API, and your support queue is lighter for it.

What makes the offer credible is that it is the same platform underneath, and on a self-hosted licence the SMPP server is included rather than sold as a separate tier. A client who starts on the HTTP API and grows into an SMPP bind keeps their account, their balance, their rate plan and their reporting; the bind is one more channel into an omnichannel account that can also carry their WhatsApp and RCS traffic on the same ledger. That continuity is what a reseller who rents a panel usually cannot offer, and it is the quiet reason technical clients stay.