Planning for M-Pesa payments in your product
Accepting M-Pesa in an app is more than one API call. Here is what to plan for so payments, records and support all line up.
For most products built for Kenya, M-Pesa is not optional. The good news is that Safaricom’s Daraja API makes it possible to take payments inside your own app or website. The part teams underestimate is everything around the payment itself.
The prompt on the phone
The most common flow is the STK push, also called Lipa Na M-Pesa Online. Your system asks Safaricom to send a payment prompt to the customer’s phone, and the customer approves it by entering their M-Pesa PIN. You need a Paybill or Till number for your business, and your integration has to be approved before it can go live.
Payments finish later, not instantly
The result does not come back in the same request. Safaricom sends it to a callback address on your server once the customer has acted. Your product needs a clear pending state, and it needs to handle customers who cancel, enter the wrong PIN, or simply put the phone down.
- Show the customer what is happening while the payment is pending.
- Treat the callback as the source of truth, and make it safe to receive more than once.
- Have a way to check a transaction’s status if a callback never arrives.
- Record the M-Pesa receipt number against every order or booking.
Reconciliation and refunds
Someone in your business will need to match payments to orders, answer customers who say they paid, and give money back when needed. Plan reports and an admin view for this from the start. Sending money to customers, for refunds or payouts, uses a separate API and setup, so decide early whether you need it.
The payment prompt is one API call. The trust customers place in your product depends on everything around it.
Build and test against the Daraja sandbox first, then go live with a small group of real transactions before opening payments to everyone.