Why the account type decision matters so much
People treat 'accept M-Pesa' as a single decision. It is not. Safaricom offers several products, and the one you register shapes how your money arrives, how you identify who paid, and how much manual work your team does forever after.
Get it right and payments reconcile themselves. Get it wrong and you spend every evening matching amounts to customers by guesswork, because the payments arrived with no reference at all. This choice is cheap to make well up front and expensive to change later, once thousands of customers know your number.
Paybill: when you need to know who paid
A paybill (a business number plus an account number) is built for identified payments. The customer enters your business number and an account reference - an invoice number, a member ID, a meter number, a phone number - and that reference travels with the money.
That single field is the foundation of automatic reconciliation. If your account numbers are meaningful and consistent, your system can match each payment to the right invoice or customer with no human involved. Paybills suit anyone who bills, runs accounts, or serves the same customers repeatedly: schools, SACCOs, landlords, utilities, wholesalers, subscription services.
Buy Goods till: speed at the counter
A Buy Goods till is the simplest option. The customer enters your till number and the amount, and pays. There is no account field, which is exactly why it is fast for a shop, kiosk or restaurant where the customer is standing in front of you and the sale is settled on the spot.
The trade-off is reconciliation. Without a reference, your system cannot tell which sale a payment belongs to - only the amount and the payer's number. For pure point-of-sale that is often fine, because the till payment happens at the moment of sale and your POS records it there. It becomes a problem the moment you try to use a till for invoices or remote payments.
STK Push vs C2B: who starts the payment
This is the axis people confuse most. It is about who initiates.
STK Push (Lipa na M-Pesa Online) is a payment your software starts. Your system sends the amount and the customer's number to Safaricom, and a PIN prompt pops up on their phone. The customer never types your number or the amount, so there is nothing to mistype - ideal for online checkout and in-app payments.
C2B is a payment the customer starts, by going into their own M-Pesa menu and paying your paybill or till. You capture it through validation and confirmation callbacks. You need C2B because plenty of customers will pay you directly whether or not your app prompted them, and those payments must still be recorded.
- STK Push: your system initiates, customer just enters their PIN - best for checkout flows.
- C2B: customer initiates from their phone, your callbacks capture it - best for walk-in and remote payers.
- Most businesses need both, so no payment slips through whichever way it began.
- STK Push can time out or be cancelled, so never treat a sent prompt as a completed payment.
The combination most businesses actually need
For the majority of Kenyan businesses that both sell and invoice, the right answer is a paybill (or till, if you are purely counter-based) with STK Push and C2B both integrated.
STK Push gives customers a clean, error-free checkout. C2B makes sure that a customer who pays you the old way - from their own menu, at midnight, from another town - is still captured. And a paybill's account number ties both back to the right invoice. This combination is what turns M-Pesa from a stream of unlabelled deposits into a reconciled, auditable payment channel.
Limits, settlement and the details people miss
Beyond the account type, a few practical details decide whether your setup holds up at volume. Transaction and daily limits vary by product and KYC tier, and hitting a ceiling mid-day stops payments cold. Settlement timing - when money moves from your M-Pesa account to your bank - affects your cash flow. Tariffs differ by product and change periodically. And going live requires Safaricom's approval process, not just working sandbox code.
None of these show up in a quick test. They show up on your busiest day, which is exactly why they belong in the decision, not the post-mortem.
How Upeosoft helps you choose and build it
We start by looking at how your customers actually pay - counter, invoice, online, or all three - and recommend the account type and integration that will reconcile cleanly rather than the one that is quickest to switch on. Then we build it: STK Push, C2B callbacks, an account-number scheme that maps to your invoices, and reconciliation into your accounting or ERP system.
If you already have an M-Pesa setup that never reconciles properly, we can often fix it without changing your number. Talk to Upeosoft and we will get your M-Pesa foundation right.
