Kenya has more active M-Pesa users than it has bank account holders. Monthly M-Pesa transaction values have exceeded 60% of GDP. For most Kenyans under 40, a phone number is a bank account — and M-Pesa is the ledger. Yet many of the enterprise systems we review in Kenya still treat mobile money as an edge case.
The symptoms are familiar: a billing system where M-Pesa is listed as "Other" in the payment method dropdown. An ERP that requires manual journal entries to post M-Pesa receipts. A collections team that emails a bank account number to customers and then wonders why 40% of invoices are overdue. A customer portal that lists acceptable payment methods as "bank transfer, cheque, card" — and then, at the bottom, "mobile money (enquire at front desk)."
This is not primarily a technology problem. It is a design philosophy problem. Systems get built around the assumptions of their designers — and many enterprise systems in Kenya were built by teams whose mental model of a payment was a bank transfer. That model has not kept up with where the money actually moves.
What M-Pesa-first actually means
Designing for an M-Pesa-first economy means treating mobile money as the primary payment interface and designing everything else around it — not as an afterthought, not as an integration, but as the default. Practically, this means four things.
Paybill and till numbers are first-class identifiers. When you send a customer a payment instruction, the paybill number and account reference appear at the top, in large type, with an SMS shortcode pre-populated. The bank account number, if it appears at all, is secondary. Most Kenyan customers will pay the top instruction they see. Design accordingly.
Reconciliation is automated, not manual. Daraja API (Safaricom's M-Pesa integration layer) provides real-time callbacks on every successful payment. Your system should match that callback against an open invoice automatically, post the receipt, and notify the customer — without a human touching it. Every business that is still printing M-Pesa statements and manually matching them is burning staff time that should not need to be spent.
STK push is available for B2C collections. For businesses collecting from individual customers — utilities, insurance premiums, school fees, subscription services — STK push lets you initiate the payment request from your system directly to the customer's phone. They receive an M-Pesa prompt; they enter their PIN; the money moves. This eliminates the "customer forgets to pay" problem for a large share of your receivables.
B2B disbursement is native, not a cheque run. M-Pesa Business Pay allows bulk disbursement to suppliers, agents, and staff directly to their M-Pesa wallets. For businesses with large agent or casual-labour networks — agribusinesses, field-force organisations, gig platforms — this is a step change in operational efficiency. The alternative (cheques, cash, bank transfers to individuals who may not have accounts) is expensive and slow.
The reconciliation problem at scale
The most common pain point we see in M-Pesa-heavy businesses is not the payment itself — it is the reconciliation. A distributor receiving 3,000 M-Pesa payments a day from retail customers has a matching problem. Which payment corresponds to which invoice? Customers don't always use the correct account reference. They sometimes split invoices across two payments. They sometimes pay the wrong amount and let the credit sit until the next order.
The solution is not better spreadsheets. It is a matching engine — either within the ERP or as a middleware layer — that applies deterministic rules first (exact amount + exact reference = automatic match) and routes exceptions to a human queue with the probable match pre-populated. In the distributor case, this typically reduces the manual matching workload by 80–90%. The remaining exceptions are genuinely ambiguous and do require human judgement. That's the right use of a human.
Safaricom's Daraja API is well-documented and reliable. The main complexity is in the sandbox-to-production transition and in handling edge cases: duplicate callbacks, timeout retries, and the occasional silent failure on C2B payments during high-volume periods. If your developer is encountering these for the first time, budget more time than the documentation suggests. If they've done it before, it's straightforward.
Designing the customer experience around it
Beyond the back-office mechanics, M-Pesa-first design changes the customer experience. Invoices should be deliverable by SMS — a PDF invoice is inaccessible to a customer with a feature phone who wants to pay you KES 12,000 for goods delivered. The payment confirmation should arrive by SMS within seconds of the transaction, not in a next-day statement. The customer support agent, when a customer calls to query a payment, should be able to look up the M-Pesa transaction reference directly in the system — not ask the customer to forward a screenshot.
None of this is technically difficult. It requires that the people designing and procuring systems start from the question "how does our customer actually pay?" rather than "how do we accept payments?" The answers to those two questions, in Kenya, are often different things.
Drawn from systems design and operations work across financial services, distribution, healthcare, and public sector in Kenya, 2019–2026.