Shipping M-Pesa in production — what we learned building lending payouts

If you build software for African businesses long enough, you stop treating M-Pesa as “just another payment API.” It is the path money actually takes — and the place buyers, auditors, and support tickets all meet.

We learned that the hard way shipping Okolea, a digital lending platform where credit decisions and disbursements had to work in production, not in a sandbox demo.

Start from the operator’s day

Before stack debates, we sat with the people who would approve loans and chase failed payouts. Their questions were operational:

• When a borrower is approved, how fast does money move?
• If Safaricom (or the aggregator) returns a soft failure, who retries — and with what idempotency key?
• How does the admin portal show “pending,” “paid,” and “needs human eyes” without a spreadsheet sidecar?

Those answers shaped the product more than any framework choice. A beautiful borrower app that lies about payout status is worse than a slow one that tells the truth.

Design for failure, not the happy path

Sandbox M-Pesa flows are polite. Production is not. Timeouts, duplicate callbacks, partial successes, and “user cancelled” states all show up once real numbers move.

What we treat as non-negotiable on payment-adjacent work:

1. Idempotent disbursement requests — retries must not double-pay.
2. Explicit state machines — pending / success / failed / manual review, stored in your system of record, not inferred from UI.
3. Reconciliation hooks — ops needs a way to match platform records to settlement reports without DMing an engineer at 11pm.
4. Audit trails — who approved, who disbursed, what the gateway said. Fintech buyers and regulators care; so should you.

None of that is glamorous. All of it is why “we integrated M-Pesa” is not the same sentence as “we run M-Pesa in production.”

Keep founders (or senior owners) on the cutover

Payment go-lives are where agency handoffs fail. Callbacks mis-pointed, credentials rotated, monitoring missing — and the team that wrote the integration is already on another project.

Our bias: the people who designed the payout path stay available through first production weeks. On Okolea-scale work, that meant architecture and delivery owners in the same channel as ops when the first live loans moved.

If you are evaluating a vendor for M-Pesa-backed product work, ask who will be on-call for the first settlement week — not only who wrote the proposal.

Local context is a product requirement

Kenyan SME lending is not a US neobank with card rails and overnight ACH. Borrowers expect mobile money. Admins expect Swahili/English ops clarity. Networks drop. Devices are mixed.

Shipping “global standards” here means boring engineering discipline (tests, observability, secure secrets) applied to local payment reality — not importing a European checkout widget and hoping.

What we would tell a buyer scoping similar work

• Budget time for reconciliation and failure UX, not only the first successful STK or B2C call.
• Treat the admin portal as part of the payment product.
• Demand a named technical owner through go-live, not a rotating bench.
• Prefer partners who have already lived production callbacks — demos are cheap; settlement nights are not.

If you are mapping a lending, collections, or payouts build and want a plain-language feasibility read, book a scope call. We will tell you what is realistic for your timeline — including when we are not the right fit.