Planning & implementation decisions
How does an M-Pesa payment update a business account?
A payment request starts a process; it does not prove payment. The backend must validate the supported provider event, match its transaction identity, reference and amount, and apply an allocation only once. Unresolved payments remain visible for review.
| Scenario | Application response | Review evidence |
|---|---|---|
| Delayed callback | Keep pending; use the supported status or reconciliation route | Request identity, timestamps and query outcome |
| Duplicate callback | Return the recorded outcome; do not allocate again | Unique transaction identity and original allocation |
| Unmatched or conflicting payment | Place in an exception queue; avoid guessing the account | Reference, amount, merchant account and reviewer decision |
| Confirmed reversal | Record a linked compensating entry under approved rules | Original transaction, reversal evidence and approval history |
- Step 1 →
Initiate and identify
Create the order or invoice reference and expected amount.
- Step 2 →
Receive and validate
Process supported confirmation/status evidence; check identity, account and amount.
- Step 3 →
Match and allocate once
Apply the confirmed transaction atomically to the correct account.
- Step 4
Reconcile and report
Compare provider records, allocations and unresolved exceptions.
Exception & recovery path
Unmatched reference, conflicting amount or invalid event → exception queue → authorized review → traceable allocation or correction. A reversal preserves the original history.
How do we prevent a duplicate callback from paying an invoice twice?
Use a unique provider transaction identity within the merchant account and an atomic database operation covering the payment record and allocation. Repeated delivery returns the existing outcome. An in-memory “seen” flag is insufficient across restarts or simultaneous requests. Treat conflicting payloads with the same identity as exceptions.
What happens when confirmation is delayed?
Keep the payment pending and make that status visible. Use the query or reconciliation mechanism supported by the selected API and account; STK request status and transaction-status services are not interchangeable. Do not silently start another charge because a callback has not arrived.
Can payments update our existing ERP?
Yes, where supported access is available. Record confirmation independently of downstream ERP availability, then deliver the allocation through a durable queue or equivalent recovery mechanism. Agree which ledger is authoritative and who reviews failed transfers.
What must the business provide before implementation?
Confirm merchant account ownership, API eligibility, production access, sample references, allocation rules and finance ownership. Keep credentials on the server. Agree provider-specific event verification and production tests with the current Daraja documentation.
Take this into your project discussion
- Confirm enabled Daraja products and production prerequisites.
- Map provider identity, merchant account and invoice reference.
- Test concurrent duplicate delivery and conflicting payloads.
- Test delayed confirmation, ERP downtime and controlled replay.
- Reconcile provider records to payments and allocations; assign exception owners.
Planning content reviewed . Confirm current provider requirements and project-specific assumptions before implementation.
Integrate Payments with Your Business Workflow
A reliable payment journey covers the amount due, customer action, provider response, confirmation and the update to the underlying record. We map how those steps work for orders, invoices, fees or other obligations, including what staff should see when a payment is incomplete.
M-Pesa APIs and Supported Payment Providers
Project requirements may involve STK Push, Paybill or C2B collection flows, callbacks and transaction-status checks. Available APIs, credentials, fees and operating permissions are defined by the relevant provider and business account—not by the corporate website.
Make Reconciliation and Exception Handling Clear
We consider unique references, delayed or duplicated notifications, unmatched payments, reversals, reconciliation reports and authorized adjustments. These workflows help finance and operations teams see what happened without relying on manual guesswork.
Connect Existing ERPs, Apps and Websites
Where secure interfaces are available, we can integrate payment confirmation with existing systems instead of replacing them. We document the integration responsibilities, tests and support expectations before deployment.
Frequently asked questions
Can you add M-Pesa STK Push to an existing website?
We can review the current website, merchant credentials, provider interfaces and desired payment flow, then scope the integration.
Are you a licensed payment service provider?
This page describes software development and integration services. Any regulated processing arrangement and its responsible provider must be established separately.
Can an M-Pesa payment update invoices automatically?
Yes, when supported APIs and reliable reference matching are in place, that can be designed as part of the integration.