The payment works. It is the failures that cost you orders.
M-Pesa payment integration connects your website or application to the Safaricom Daraja API so customers pay by STK Push, Paybill or Till and payments reconcile automatically. Haryes handles the callback security, timeout and reversal edge cases that break most DIY integrations.
Every integration handles the happy path. Almost none handle the rest.
Connecting to the Safaricom Daraja API and taking one successful payment is a day of work. Running payments for a real business means handling everything that happens when the network, the handset or the customer does something unexpected.
These are the failures that lose money quietly.
- The customer pays, the callback never arrives, and the order is marked unpaid.
- The callback arrives twice and the order is fulfilled twice.
- The customer cancels the prompt and the checkout spins with no way out.
- A timeout leaves a transaction in an unknown state that nobody can look up.
- Payments match orders by amount and time, which breaks the first busy afternoon.
How the integration runs
The paperwork is usually longer than the code, so it starts first.
Credentials and shortcode
Paybill or Till registered to the business, a Daraja account you own, and the production passkey requested early.
Credentials in your name, not ours.
Design the flow
What the customer sees at every state: prompt sent, confirming, succeeded, cancelled, failed, timed out.
No dead ends at checkout.
Build and secure
STK Push, plus Paybill or Till where you need them, with validated callbacks on an endpoint that rejects anything unexpected.
An endpoint that cannot be spoofed.
Test the unhappy paths
Cancelled prompts, wrong PIN, lost callbacks, duplicates, partial amounts and reversals, all exercised before launch.
Confidence under real conditions.
Reconciliation and handover
A view listing payments without orders and orders without payments, plus training for whoever will check it.
Problems found the same day.
The four methods, and what each is for
Most businesses need two of these, not all four.
STK Push
The prompt appears on the customer's phone and they enter their PIN. Built for website and app checkout.
Your primary method.
Paybill
The customer pays manually using an account reference, which is what lets you match it to an invoice.
Invoices and manual payers.
Till
Fast for the customer but carries no reference, so matching relies on amount and time.
Low volume only.
B2C
Paying out: refunds, vendor settlements and marketplace payouts, with its own approval requirements.
Money going the other way.
What you get
Built into a store, a site or an application. Read the comparison of the three methods.
A working checkout
Every state handled.
- STK Push at the point of payment
- Clear messaging on cancel, timeout and failure
- Retry without starting the order again
Secure callbacks
Treated as untrusted input.
- Validated and deduplicated
- Idempotent order updates
- Status confirmed by query, not by waiting
A reconciliation view
The screen that pays for the integration.
- Payments with no order
- Orders with no payment
- Amount mismatches flagged, never auto-accepted
Credentials in your name
Not held by an agency.
- Daraja account owned by your business
- Shortcode registered to you
- Documentation for whoever maintains it next
Questions clients ask before they commit
How long does an M-Pesa integration take?
The development is usually two to three weeks. The constraint is getting the shortcode registered and the production passkey issued, which is why we start that paperwork before the build.
Should we use an aggregator instead?
Often yes, particularly if you also want cards. You trade a cut of each transaction for less engineering and less maintenance. We will tell you which is cheaper for your volume.
What happens if Safaricom changes the API?
It has changed before. Because the integration is in code you own with credentials in your account, any competent developer can update it, not only the one who built it.
Can you fix an integration we already have?
Yes, and it is a common job. We usually start by testing the failure paths, because that is where the lost orders are hiding.
New integration, or a broken one?
You are building a store or an application that needs to take payments.
We scope the methods, the credentials and the reconciliation together.
Integrate M-PesaPayments arrive but orders do not, or the other way round.
We test the failure paths and fix what the original build skipped.
Get it auditedCustomers forgive a slow site. They do not forgive paying and being told the payment failed.
