Money in an emerging market does not move through one place. It moves through mobile money wallets, through aggregators, and through banks, each with its own API, its own quirks, and its own failure modes. The first time a product team integrates two or three of these directly, the code is manageable. By the fifth, every change is risky and reconciliation is a spreadsheet.
There is a better shape for this.
One layer over many rails
The pattern that holds up is a single integration layer that sits between your product and every payment provider. Your application talks to one interface. Behind it, the layer routes to mobile money (MTN MoMo, AzamPay, InTouch), to bank channels (Access Bank), or to whichever provider fits the transaction.
This does three things:
- Your product code stays simple. It asks to collect or pay out. It does not need to know which rail does the work.
- Adding a provider is a contained change. New rails go in behind the same interface, without touching the rest of the system.
- Reconciliation has one home. Every transaction passes through one place, so settlement and matching are consistent across providers.
Collections, payouts, and the hard part
Collecting money is the easy half. The hard half is everything around it:
- Reconciliation. Money in and money out must match across every rail, every day. This is where most home-grown integrations quietly break.
- Idempotency. Networks retry. Without careful handling, a retry becomes a double charge or a double payout.
- Status truth. A payment can be pending, succeeded, failed, or reversed, and providers report these differently. The layer has to present one clear, correct status.
Getting these right is what separates a demo from a payment system you can run a business on.
Built for real scale
We have built payment systems that move money across networks and borders, from cross-border university and hospital payments to cashier platforms and forex settlement. The common thread is the same: one well-engineered interface, clean reconciliation, and behaviour that holds up when volume is real and the network is not perfect.
If you are wiring up payments and can already feel the integration sprawl coming, it is worth designing the single-layer approach before the third provider, not after the fifth.
