The gap Daraja leaves open
M-Pesa integration guides all assume the same starting point: a registered paybill or till, enrolled for the C2B API, with credentials from Safaricom. When that is in place, payments arrive as clean, structured callbacks and reconciliation is straightforward.
The trouble is how many real businesses do not start there. A hardware shop takes buy-goods payments on a till that was never registered for the API. A consultant or landlord collects on a personal line, which can never be integrated at all. A trader uses an aggregator's shared code and only gets a summary. For every one of these, the structured feed does not exist - and yet they all need to know, quickly and accurately, who has paid.
The one signal that always arrives
Whatever line the money lands on, one thing is constant: M-Pesa sends a confirmation SMS. Personal line, unregistered till, aggregator code - the SMS still arrives, and it still carries the amount, the transaction code, the payer's name and the reference.
That makes the SMS the lowest common denominator of M-Pesa reconciliation. It is not as clean as a Daraja callback, but it is universal. If you can reliably capture and parse that message, you can reconcile payments on lines that Daraja will never reach.
Turning the inbox into a feed
The manual version of this is what most businesses already do: someone reads the M-Pesa messages and ticks off payments by hand, or exports a statement and matches at month end. It is slow, it is late, and it is where errors and missed payments hide.
- A dedicated Android phone holds the paying SIM and stays on.
- A gateway app forwards every incoming M-Pesa SMS to your server in real time.
- Your backend parses each message and matches it against open invoices.
- Reconciliation happens continuously, not in a stressful month-end scramble.
Doing it safely with an open-source gateway
Because this touches money, the forwarding has to be trustworthy. Upeosoft's SMS Gateway is open source (github.com/Upeosoft-Limited/upeo-sms-gateway) specifically so you can see how it protects your payment data. It keeps an encrypted queue on the device so no message is lost when the network drops, and it retries with backoff until delivery succeeds. It signs each message with a shared secret so your server can reject anything not genuinely from your phone. It delivers each payment exactly once, so a duplicated SMS never becomes a duplicated ledger entry. And it runs as a persistent service that survives reboots and battery optimisation.
Those properties are what separate a dependable reconciliation feed from a script that silently drops payments the first time the WiFi hiccups.
The reference scheme is the real work
The technology gets the message to your server; the business logic decides what it means. The single most important thing you can do is make customers pay with a reference your system understands. When the reference is a recognisable invoice or account number, matching is fully automatic and your books stay current with no human effort.
When the reference is missing or messy - customers typing a nickname, or nothing - you drop back to manual matching for those payments. So part of setting this up is practical: deciding what reference to ask for, printing it on invoices, and training staff to guide customers to enter it. Get that right and the whole system runs itself.
A bridge you can build on
SMS-based reconciliation is not a compromise you are stuck with - it is a bridge you can grow from. It gives an unregistered or personal-line business automatic reconciliation today, and it can run alongside or ahead of a future move to a registered paybill and full Daraja integration.
At Upeosoft we help businesses close this exact gap: deploy the gateway, tune the parsing to your M-Pesa message format, design the reference scheme, and connect it into your accounting or ERP so payments post themselves. If you are reconciling M-Pesa by hand because Daraja is not an option, talk to us - there is a better way, and it does not require waiting for a paybill.
