When a card transaction fails, the customer rarely knows why. Was it their bank? The network? The merchant’s terminal? For the person standing at a checkout counter, the uncertainty is the problem, and increasingly, fintech engineers are treating that uncertainty itself as something to be designed against, not just tolerated.
That idea sat at the centre of Moniepoint’s inaugural “Off the Record Engineering Mixer” in Lagos, where the leading fintech gathered senior engineers from across Nigeria’s payments industry, including Flutterwave, Cowrywise and Nomba, for closed-door conversations on the mechanics of running financial infrastructure at scale.
The sessions, titled “Building for Scale: The Trade-offs of Distributed Systems in Fintech” and “Building Distributed Systems for POS at Scale,” steered clear of polished case studies in favour of harder terrain: system failures, network dependencies, architectural trade-offs, observability and security.
Moniepoint used the occasion to walk through its own answer to a question every payments engineer eventually faces: what happens when a transaction’s outcome is unclear?
According to Ayomide Kolawole, Engineering Manager for Card Payments at Moniepoint, the answer starts with treating every stage of a transaction as a point where something could go wrong, and matching each one with a deliberate response rather than a default.
“Building reliable payment infrastructure is about understanding every point at which a transaction can fail, determining what the system knows at each stage and designing the right response when things go wrong,” Kolawole said. “Our responsibility is to ensure that customers are not left carrying the consequences of uncertainty created within a system they rely on.”
That distinction, between speed and accountability, shapes how Moniepoint’s card payments infrastructure, which handles tens of millions of transactions daily, is built. Where the system is confident a transaction won’t succeed, it fails fast rather than stringing the customer along. Where the outcome is genuinely unclear, it holds off on a response and works to confirm what actually happened before telling the customer anything at all.
“For us, the goal is not simply to process transactions quickly, but to make sure that when something goes wrong, the customer experience does not become the cost of that failure,” Kolawole added.
One piece of this system runs continuously in the background: real-time monitoring of issuing banks across individual processors, tracking success rates and response times. When a route’s performance drops below a set threshold, the system stops sending transactions there automatically — before failures start piling up and customers start waiting.
That same logic- plan for the failure, not just the happy path- ran through the broader Mixer discussions. Sharding, asynchronous processing, service decomposition: speakers returned repeatedly to the point that each of these choices solves one problem while quietly introducing another, whether in maintenance burden, latency, or operational blind spots. Observability and security, participants agreed, are what make those trade-offs visible before they turn into incidents.
Moniepoint framed the event itself as a bet on transparency between competitors: that the operational challenges of African fintech infrastructure are shared rather than proprietary, and that comparing notes directly — engineer to engineer, failure to failure — moves the industry forward faster than any conference panel could.
The takeaway threading through both the Mixer and Moniepoint’s own systems design was less about uptime metrics and more about posture: reliability isn’t just building things that work. It’s building things that fail honestly, and making sure the customer is never the one left holding the bill for a system’s blind spot.