Moving money at scale is not an integration, it is a system.
API integration connects your systems to each other and to external services; M-Pesa platforms move money at scale over the Daraja API. Haryes builds collection, disbursement and reconciliation platforms with the logging and failure handling production money movement requires.
A payment integration handles one payment. A platform handles ten thousand.
Taking a single M-Pesa payment on a website is a known piece of work. Running collections and disbursements for a lending business, a sacco, a marketplace or a payroll is a different category of problem, and it fails differently.
At volume, these stop being edge cases:
- A disbursement sent twice because a retry was not idempotent.
- Reconciliation done manually at month end, which does not scale past a few hundred transactions.
- No transaction log that can answer what happened to one specific payment nine months ago.
- Rate limits and timeouts hit during peak, with no queue to absorb them.
- Systems that do not share an identifier, so the same customer exists three times.
How a platform is built
Money systems are built failure-first. The happy path is the easy part.
Model the money
Every movement, who initiates it, what state it passes through, and what happens when each step fails.
A state machine, written down.
Design for failure
Idempotency keys, retries with backoff, queues and timeouts decided before any code is written.
Nothing paid twice.
Build collections and payouts
Daraja integration for the flows you need, with callbacks treated as untrusted and status confirmed by query.
Money that moves reliably.
Reconcile automatically
Platform records matched against M-Pesa records continuously, with exceptions surfaced to a human.
Month end stops being an event.
Log and monitor
Every transaction traceable end to end, with alerting on failure rates rather than a dashboard nobody opens.
Answers when you need them.
What production money movement requires
Four properties. A platform missing any of them will lose money eventually.
Idempotency
The same request submitted twice must not pay twice. In disbursements this is the difference between a retry and a loss.
Non-negotiable.
An audit trail
Every transaction traceable from initiation to settlement, months later, by someone who was not there.
Answers, not guesses.
Automatic reconciliation
Continuous matching against M-Pesa records, with only the exceptions reaching a person.
Humans on exceptions only.
Failure visibility
Alerting when failure rates move, because silent failures in a money system are the expensive kind.
Told, not discovered.
What you get
Custom platform work, scoped during discovery. See application pricing.
Collections and disbursements
At volume.
- STK Push, Paybill, Till and B2C as needed
- Queued and retried safely
- Idempotent by design
Reconciliation
Continuous, not monthly.
- Automatic matching
- Exception queue for humans
- Statements your finance team can use
Logging and monitoring
Built for questions asked later.
- Full transaction trace
- Alerting on failure rates
- Searchable by reference or customer
Integrations
Your systems, connected.
- Accounting and core systems
- Shared identifiers across systems
- Documented for whoever maintains it next
Questions clients ask before they commit
How is this different from adding M-Pesa to a website?
A website integration takes payments for orders. A platform initiates payouts, handles volume, reconciles continuously and has to answer for every shilling months later. The failure modes are different and so is the engineering.
Do you handle B2C disbursements?
Yes. B2C has its own registration and approval requirements with Safaricom, and we build the idempotency, approval workflow and reconciliation around it rather than treating it as a single API call.
What about compliance?
We build the logging, audit trail and controls that a regulated business needs to demonstrate. What your specific obligations are is a question for your compliance advisers, not for us.
Can you work with our existing systems?
Usually. Where an API exists we integrate directly, and where it does not there are other routes. Establishing that is part of discovery rather than an assumption in a proposal.
What are you building?
Collections or payouts beyond what a website integration handles.
Discovery first, with the money flow modelled before any build.
Scope my platformYour systems do not talk and data is typed in twice.
Integration work, scoped against what each system can expose.
See custom applicationsMoney systems are judged on what they do when something fails, not on what they do when everything works.
