Anonymised case study ยท Payments
Connecting an M-Pesa payment flow to the records around it
This case study describes a completed Statum project without naming the client. It focuses on the system behaviour and delivery decisions that can be verified from the implementation scope.
Context
A digital product needed mobile-money payments connected to its own records.
Integration
M-Pesa payment initiation, callback handling, status tracking, and reconciliation.
Evidence
The delivered scope and integration responsibilities, without invented performance claims.
The problem to solve
A payment request is only one part of the work. The product also needs to know which customer or order the payment belongs to, what happened when the provider responded, and what a person should do when a callback is delayed or duplicated.
What Statum delivered
- Payment initiation through an M-Pesa integration.
- Callback handling for asynchronous provider responses.
- Transaction states that separate pending, successful, failed, and review cases.
- Records and views that support reconciliation and follow-up.
- Application and integration boundaries that can be tested separately.
Why the workflow matters
A callback can arrive late, more than once, or after a user has already left the screen. Treating the provider response as the only source of truth makes it difficult to investigate exceptions. Recording the request, the provider response, and the internal transaction state gives the team a clearer operational trail.
What we would verify before a new production integration
- Credentials and environment separation.
- Callback authentication and idempotent processing.
- Timeout, retry, reversal, and duplicate-response behaviour.
- Reconciliation ownership and reporting.
- Current requirements in the Safaricom developer portal.