STK Push, PayBill or Till: choosing the right M-Pesa flow for your system

Most Kenyan business systems will take M-Pesa. The harder question is how. The Daraja API offers several ways to receive money, and the choice shapes everything downstream: what the customer does, what staff see, and how much reconciliation the finance team inherits.

The three collection flows

STK Push sends a payment prompt to the customer's phone for a specific amount. The system initiates it, so it already knows who is paying and for what. PayBill (C2B) has the customer pay a business number with an account reference they type themselves. Till ("Buy Goods") is a business number without an account reference — simplest for the customer, least information for the system.

What each flow means for reconciliation

With STK Push, the system created the request, so a confirmation callback can be matched automatically to an invoice or order. With PayBill, matching depends on the customer typing the right account reference — a source of endless "unallocated payments". With Till, there is no reference at all; matching relies on amount, time and a staff member confirming who paid.

A useful rule: the less the system knows before the money moves, the more work a human does after it.

Choosing for the process, not the API

• Invoices, subscriptions, checkout: STK Push. The system knows the amount and the payer.
• Walk-in customers who pay first: PayBill with a short, validated account reference, or Till plus a verification step at the counter.
• Field agents and deliveries: STK Push from a staff app so the agent never handles cash or a phone number.

Handle the failure paths first

Callbacks arrive late, twice, or not at all. Customers cancel prompts. Networks drop mid-transaction. A production integration needs idempotent callback handling, a status query for anything left pending, and a reconciliation job that compares the ledger to the Daraja statement — before the first customer pays, not after the first dispute.