Malipo Popote Solutions — How does an M-Pesa payment update a business account?
Reviewed: 2026-10-15

Planning worksheet. Examples are illustrative, not deployed client results.

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.

[ ] 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.

Decision comparison
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

Open questions / owner / due date:

Evidence / acceptance decision:

Sources:
https://developer.safaricom.co.ke/apis
https://developer.safaricom.co.ke/apis/TransactionStatus

Reference page: /services/payment-integration/