STK Push vs Paybill vs Till for your online store
The short answer
For an online store, STK Push through the Daraja API gives the best checkout experience because the customer confirms a prompt rather than copying numbers. Paybill and Till still matter for reconciliation and for customers who prefer to pay manually, so most stores end up supporting both.
Three ways to take M-Pesa, and they are not interchangeable
Every Kenyan online store has to answer this question before it can take a payment. The three methods differ in how the customer pays, how the money reaches you, and how much manual work reconciliation takes afterwards.
STK Push
Built for checkout- How the customer pays
- A prompt appears on their phone; they enter their M-Pesa PIN.
- How you match the payment
- Your system receives a callback confirming the result.
- Best for
- Website and app checkout.
- Watch out for
- Needs a Paybill or Till, Daraja API credentials, and handling for delayed or lost callbacks.
Paybill
Invoices and manual payers- How the customer pays
- Opens M-Pesa, enters your business number and an account reference.
- How you match the payment
- By the account reference.
- Best for
- Invoices, deposits, customers who prefer to pay manually.
- Watch out for
- The customer has to type the reference correctly.
Till (Buy Goods)
Quick, but hard to match- How the customer pays
- Enters the till number and amount.
- How you match the payment
- No account reference, only amount and time.
- Best for
- Very low online order volume.
- Watch out for
- Breaks as soon as two customers pay the same amount within a few minutes.
STK Push
STK Push (branded by Safaricom as Lipa na M-Pesa Online) is the method built for websites and apps. Your checkout calls the Safaricom Daraja API, the customer gets a prompt on their phone, they enter their M-Pesa PIN, and your system receives a callback confirming the result. The customer never copies a number or a reference, which removes the most common source of failed payments.
The trade-off is that STK Push needs a registered Paybill or Till and a set of Daraja API credentials, and your integration has to handle the cases where the callback is delayed or lost. That is engineering work, and it is exactly what a proper M-Pesa integration covers.
Paybill
With Paybill, the customer opens M-Pesa themselves, enters your business number and an account reference, and pays. It is the right method for invoices, deposits and customers who simply prefer to pay manually.
The account reference is what lets you match the payment to an order, so the reference has to be something your system generates and the customer actually types correctly, which is the weak point.
Till, also called Buy Goods
Till payments are quick for the customer (enter the till number and amount) but there is no account reference, so you cannot automatically tell which order a payment belongs to.
For an online store that means matching by amount and time, which breaks as soon as two customers pay the same amount within a few minutes.
What most stores do
STK Push as the primary checkout
For the experience: the customer confirms a prompt instead of copying numbers.
Paybill as a fallback
For reconciliation and for manual payers.
Skip Till for online orders
Unless volume is very low.
What you need from Safaricom first
None of this is developer work, and all of it blocks developer work. Start it before the build, because the paperwork is usually the longest item in the timeline.
Register the Paybill or Till in the business name
Not in a director's personal name and not on a shared number. The shortcode is an asset of the business, exactly like the domain, and moving it later is painful.
A shortcode you control.
Create a Daraja account and an app
The developer portal is where the API credentials live. The business should own the account, with the developer added rather than the other way round.
Consumer key and secret held by you.
Get the production passkey assigned
Sandbox credentials let development start, but going live needs the shortcode linked and a passkey issued. This step is the one that most often adds a week.
Go-live credentials.
Agree the callback URL and whitelisting
The callback has to reach a public HTTPS endpoint on your site. Confirm what is whitelisted before launch day rather than during it.
A path payments can return to.
Confirm settlement and charges with your bank
How often funds move from the shortcode to your account, and what the transaction charges are, decides whether your margins survive small-ticket orders.
Pricing you can model.
Callbacks fail, and your checkout has to survive it
Most M-Pesa integrations that go wrong in Kenya do not go wrong because the API was misunderstood. They go wrong because the happy path was the only path anyone tested.
- The customer pays but the callback never arrives, so the order sits unpaid and the customer is told the payment failed.
- The callback arrives twice and the order is marked paid twice, or worse, fulfilled twice.
- The customer cancels the prompt and the checkout spins forever instead of offering another method.
- The customer enters the wrong PIN and the error message says only "payment failed".
- A timeout leaves a transaction in an unknown state with no record anyone can search.
- Partial payment, where the amount is edited at the handset, is treated as full payment.
The screen that pays for the integration
Whichever methods you support, the operational value sits in one unglamorous view that someone checks for five minutes a day.
Payments with no order
Money arrived that the system could not match. Usually a Paybill reference typed incorrectly or a Till payment with nothing to match on.
Match it by hand, once.
Orders with no payment
A checkout that started and never completed, or a callback that was lost. These are recoverable sales if someone sees them the same day.
Follow up while it is warm.
Amount mismatches
Paid less or more than the order total. Common with manual methods and a real source of silent losses.
Flag, never auto-accept.
Duplicates
The same transaction recorded twice, usually from a repeated callback. Harmless if detected, expensive if fulfilled.
Deduplicate on the receipt number.
What store owners ask us
Can I just use a payment aggregator instead of Daraja directly?
Yes, and for many stores it is the sensible choice. An aggregator handles the integration and often adds card payments, in exchange for a cut per transaction and less control over the checkout experience. Direct Daraja is cheaper per transaction and more work up front.
Do I need both a Paybill and a Till?
Usually not. Pick the one that matches how you take money offline, then use STK Push on top of it for online checkout. Running both multiplies reconciliation work for little gain.
How long does an M-Pesa integration take?
The development is rarely the constraint. Getting the shortcode registered, the Daraja app approved and the production passkey issued is what sets the date, so start that paperwork before the build begins.
What happens if Safaricom changes the API?
It has changed before and will again. That is an argument for keeping the integration in code you own, with the credentials in your account, so any developer can update it rather than only the one who built it.
