How SMS billing actually works: credit, wallet, auto-route

Every SMS billing system, no matter how it dresses itself up, is answering one question: when this client sends a message, whose money moves, and how much. Get that wiring right and the business runs itself, invoices reconcile, and you can see your margin at a glance. Get it wrong and you are sending on credit you never granted, arguing over a spreadsheet at month end, and slowly leaking the spread that is your entire profit. This guide walks the three billing models every messaging operator ends up needing, where the margin actually lives, and the point at which a spreadsheet quietly stops being enough.

The three billing models, in plain terms

Almost every serious platform lands on the same three shapes, because they map to three different kinds of client. Smppcube names them CreditRoute, WalletRoute, and AutoRoute, and the names describe exactly what they do.

Credit billing gives a client a pool of prepaid messages tied to a specific route. You assign, say, 10,000 credits on Route A and 5,000 on Route B, and each route has its own independent balance. When they send on Route A, credits come out of the Route A pool. This is the model resellers reach for most, because it is concrete: the client bought a block of messages on a known route at a known price, and both of you can count what is left. It shines when a client cares which route their traffic takes (a premium route for OTPs, a cheaper one for marketing) and when you want to sell messages in blocks rather than currency.

Wallet billing holds real money instead of message counts. The account carries a balance, say 50.00 USD, and a single price plan defines the cost per destination. Send a message to a country priced at 0.0090 and 0.0090 leaves the wallet. This suits clients who send to many destinations at different prices and would rather think in money than juggle per-route credit pools. One balance, one plan, priced by where the message lands.

Auto-route billing looks like the wallet from the client’s side (a currency balance, priced per destination) but changes who decides the route. The platform picks it, applying your routing rules to send each message down the best valid path for its destination. The client never sees or chooses a route. This is how you run least-cost or quality-tiered routing without asking clients to understand your carrier map, and it is where a mature operation with many routes usually ends up for its hands-off clients.

One hard operational note that catches people out: the billing type is set when the account is created and locked from then on. The credit pools, the wallet, and the price plans are structured differently underneath, so there is no in-place switch. Moving a client between models means exporting their data, creating a fresh account under the right type, and retiring the old one. Decide the model at onboarding, not after.

Prepaid versus postpaid: the axis that cuts across all three

Underneath those three models runs a second choice that matters more to your cash flow than any of them: does the client pay before they send, or after.

Prepaid is the default and it should be. The client loads a balance, the platform enforces it, and when the balance hits zero, sending stops. You have already been paid for every message that leaves, which means you are never funding a client’s traffic out of your own pocket while you wait for a check. Credit and wallet models are both naturally prepaid: the pool or the wallet is the limit.

Postpaid flips it. The client sends first and you invoice them later, usually monthly. This is what large institutions expect (a bank is not going to top up a wallet before every campaign) and it can be the difference between winning a marquee client and losing them. But postpaid is a loan. You are paying your upstream provider for termination in real time and collecting from the client weeks later, so every postpaid client is working capital you have tied up and a small credit risk you are carrying. The discipline is simple: keep postpaid to clients you have a contract and a history with, set a hard monthly ceiling even for them, and watch the aging on those invoices like a hawk. Most healthy operations run almost everyone prepaid and keep a short, deliberate postpaid list.

Where the margin actually lives: per route and per client

Your profit is the spread, and the trap is measuring it in only one direction. You need to see margin two ways at once.

Per route is the supply-side view. You buy Route A at 0.0060 and sell it at 0.0090, a 0.0030 spread. If that route silently degrades and your provider bumps you to 0.0072 to keep delivery up, your spread just fell by 40 percent and you will not feel it until the month closes, unless your billing shows you cost against sell price per route. This is the number that tells you which supplier relationships are actually earning.

Per client is the demand-side view, and it is a blend. A client sending 80 percent marketing on a cheap route and 20 percent OTP on a premium one has a blended margin that neither route’s number tells you on its own. The client who negotiated your best rate and sends only on your thinnest-margin route can be near break-even while looking like a big account by volume. Per-client margin is what tells you who to protect, who to reprice, and who is quietly costing you money at scale.

A worked example makes the stakes obvious. Ten clients averaging 300,000 messages a month is 3,000,000 messages. At a healthy 0.0030 blended spread that is 9,000 USD of gross margin a month. Let one route drift by 0.0010 across half your volume and you have lost 1,500 USD without changing a single price the clients see. The revenue and billing features exist to surface exactly this, cost versus sell, per route and per client, so the drift shows up on a dashboard instead of in a bad quarter. The broader picture of where a reseller’s money comes from is in the reselling playbook.

Invoicing realities: prepaid, postpaid, recurring, multi-currency

Billing is not just deducting balances; it is producing documents a client and a tax authority both accept. Four realities show up the moment you have real clients.

Numbered invoices with line items. A wallet top-up or a credit purchase should produce a properly numbered invoice (for example INV-2026-000142) built from line items (what was bought, the quantity, the unit price), not a lump total. When a client queries a charge, you point at a line, not a mystery. Corrections and refunds go through credit notes against the original invoice, so the paper trail stays honest and a past bill never silently changes after the fact.

Tax done once, correctly. Different markets want VAT, GST, service tax, or nothing, and the rate belongs to the client, not typed fresh each time. Billing profiles solve this: a profile bundles a currency, an allowed payment mode, and a default tax rate, and you assign it in one click. “US Standard” in USD with no tax, “EU Clients” in EUR with 20 percent VAT, applied by picking a profile at account creation.

Multi-currency that you can actually collect. The moment you serve more than one country you need to bill in more than one currency, and the guardrail that matters is that a profile’s currency is limited to what your enabled payment gateways can collect. Connect Stripe, PayPal, Paystack, Razorpay, a crypto option, or offline bank transfer, and the currencies those gateways support become the currencies you can safely invoice in. You never bill in money you have no way to receive.

Recurring and postpaid cycles. Prepaid clients top up on their own schedule, but postpaid clients and any client on a fixed monthly plan need invoices generated on a cycle, automatically, whether or not anyone remembers. A recurring billing worker runs those cycles so the monthly invoice for your postpaid bank client appears on the first without a human touching it. Automating this is not a luxury; it is the only way postpaid stays safe as you grow, because a forgotten invoice is a month of free traffic.

Why spreadsheets die at twenty clients

Every operator starts in a spreadsheet, and for the first handful of clients it genuinely works. The failure is not dramatic; it is slow, and it always arrives around the same place: roughly twenty clients.

Here is the arithmetic of the pain. Twenty clients, each with their own rate, on two or three routes each, some prepaid and some postpaid, a few in a second currency, all generating traffic every day that has to be reconciled against delivery reports. That is not twenty rows; it is hundreds of moving numbers that change hourly, and every one of them is a place where a fat finger or a stale copy-paste becomes real money lost. You cannot enforce a prepaid limit in a spreadsheet, so a client oversends and you eat it. You cannot see per-route margin drift, so a degraded route bleeds you quietly. You cannot produce a numbered, tax-correct invoice on demand, so month end becomes two days of manual assembly and one embarrassing correction.

The deeper problem is that a spreadsheet is a record of what you think happened, while a billing engine is the thing that makes it happen. When balances live in the same system that meters the sending, the limit is enforced in real time, the invoice is generated from the actual traffic, and the margin report is a query, not an evening of reconciliation. That is the line a growing operation crosses: not “the spreadsheet is annoying” but “the spreadsheet can no longer be trusted.” Cross it before a costly mistake forces you to, not after.

Choosing your setup, honestly

If you are two clients into a test, none of this is urgent, and reaching for a full billing engine on day one is over-engineering. A prepaid wallet, a clear rate, and a hand-written invoice will carry you through proving that you can sell at all. The moment to build properly is when you can feel the models diverging: a client who wants per-route credits, another who wants a currency wallet, a bank that insists on monthly postpaid, and a second currency creeping in. That is the platform’s whole reason to exist, and getting the billing model right for each client at onboarding, prepaid by default, postpaid by exception, is the single decision that keeps the spread you worked to earn from leaking away one untracked message at a time.