PawaPay’s Monnify integration in Nigeria remained disrupted for almost 37 hours after the payment aggregator first reported degraded performance, extending well beyond a restoration target supplied by Monnify and exposing how outages at an underlying processor can affect different payment platforms for very different lengths of time.
PawaPay first reported degraded Monnify performance at 11:03 UTC on October 2, affecting both its Nigerian web-deposit and payout gateways.
By 14:34 UTC, deposits were in outage and payouts were degraded. PawaPay later said payout flows had begun improving, but the deposit gateway remained unavailable.
At 22:26 UTC, the company provided a more specific explanation: Monnify had informed PawaPay that an urgent system update had made its services unavailable and expected full restoration before 07:00 UTC on October 3.
That target was missed.
At 10:03 UTC, more than three hours after Monnify’s expected restoration time and almost 23 hours after the first incident report, PawaPay said both its Monnify Nigeria deposit and payout gateways were still in outage.
The disruption ultimately continued much longer. PawaPay moved the incident into monitoring at 22:31 UTC and marked it resolved at 23:59 UTC on October 3, according to its official status history.
PawaPay Itself Was Not the Component That Failed
The distinction between the payment aggregator and its downstream processor is important.
PawaPay’s status system separates the health of its own platform from individual mobile-money and payment-provider integrations. Its core platform, Merchant API, dashboard and payment-reconciliation services remained operational while the Monnify gateways were affected.
In practical terms, a merchant could still reach PawaPay’s infrastructure while being unable to successfully use one particular route for Nigerian deposits or payouts.
That is a familiar architecture across modern payments. The platform a merchant integrates with may sit above banks, mobile-money operators, card processors and local gateways. An outage several layers downstream can therefore make one payment method unavailable even while the API accepting the original request remains healthy.
It is exactly the kind of dependency problem that infrastructure providers increasingly try to hide from end users. Dave Finances previously examined how financial platforms are trying to reduce the number of separate middleware layers sitting between users and settlement. The PawaPay incident illustrates why those layers matter when something breaks.
Monnify’s Own Status Page Told a More Complicated Story
Monnify’s public status history broadly confirms that its disbursement infrastructure was undergoing work, but the timeline is less straightforward than a single outage with one restoration time.
One Monnify notice said disbursements would be unavailable from 11:00 p.m. WAT on October 2 while the company carried out system checks. It initially expected service to return before 8:00 a.m. WAT on October 3, equivalent to 07:00 UTC.
That maintenance entry was marked completed at 8:00 a.m. British Summer Time, also 07:00 UTC.
But just 18 minutes later, Monnify published another disbursement-maintenance entry covering the same overnight period. The second notice changed the expected restoration point to before 10:00 a.m. WAT, or 09:00 UTC, and said maintenance was still in progress shortly afterward.
That sequence is important because PawaPay’s 10:03 UTC update came after both restoration targets.
It also shows why a processor’s top-level status page does not necessarily tell a merchant whether a particular upstream integration is functioning normally.
dLocal’s Monnify Route Recovered Earlier Than PawaPay’s
A comparison with another payment company provides the most useful evidence that Monnify availability was not uniform across every integration.
dLocal separately reported processing problems involving Monnify-Moniepoint in Nigeria beginning on October 2.
Its first recorded incident began at approximately 20:22 UTC on October 2 and was marked resolved at about 05:52 UTC on October 3.
That means dLocal considered its affected route recovered more than four hours before PawaPay was still reporting both Monnify deposits and payouts unavailable at 10:03 UTC.
The comparison does not prove that one company repaired its integration faster. dLocal and PawaPay may have been using different Monnify products, different transaction paths, different bank or Moniepoint dependencies, or different criteria for declaring service restored.
But it does weaken the idea of one simple processor-wide state in which Monnify was either “up” or “down” for everyone at the same time.
dLocal Then Saw Monnify Problems Return
The comparison became even more complicated later on October 3.
dLocal opened another Monnify-Moniepoint incident at approximately 21:33 UTC, saying it had again identified payment-processing problems in Nigeria.
That incident continued through the night and was not marked resolved until approximately 13:13 UTC on October 4.
PawaPay, by contrast, moved its Monnify incident into monitoring at 22:31 UTC on October 3 and declared it resolved at 23:59 UTC.
The two status histories therefore crossed in both directions.
Early on October 3, dLocal had recovered while PawaPay remained down. Later that night, PawaPay recovered while dLocal was still investigating renewed problems.
That pattern strongly suggests that merchants should be careful when interpreting a single aggregator’s outage as evidence of the state of the entire Nigerian payment network.
Deposits and Payouts Also Recovered Differently
The PawaPay timeline itself shows another layer of asymmetry.
At 20:25 UTC on October 2, the company said payout flows were improving while deposits remained unavailable. By 10:03 UTC the next morning, however, both deposit and payout gateways were again described as being in outage.
At 13:21 UTC, PawaPay’s update referred specifically to the payout gateway still being down. At 18:50 UTC, it again said both deposits and payouts were unavailable.
This kind of movement can happen because collections and disbursements often depend on different systems.
A payment provider may be able to recognize incoming transfers while being unable to send money out, or vice versa. Even where the customer sees both functions under one brand, the settlement accounts, bank APIs, authentication systems and processing routes underneath them may be different.
That makes the original Monnify restoration estimate less useful than it initially appears. “Services restored” at the processor level does not necessarily mean every API function and every downstream partner route is immediately healthy.
Nearly 37 Hours Is Significant for Merchants Even Without a PawaPay Platform Failure
For PawaPay customers, the operational consequence was straightforward.
A merchant depending specifically on Monnify for Nigerian payment collection or disbursement could have faced degraded or unavailable service from 11:03 UTC on October 2 until the incident was finally closed at 23:59 UTC on October 3.
That is approximately 36 hours and 56 minutes.
The fact that PawaPay’s API remained available does not eliminate the commercial impact. A functioning orchestration layer cannot complete a transaction if the downstream rail it is being asked to use is unavailable.
For merchants operating high-volume payment flows, that distinction can affect deposit conversion, customer withdrawals, reconciliation backlogs and support volume even if no funds are lost.
The natural defense is route redundancy: when one processor is unavailable, traffic can be moved to another provider capable of reaching the same market.
But the dLocal comparison shows why that is more complicated than simply connecting two aggregators. Providers may share the same underlying banks, processors or mobile-money dependencies, meaning apparently separate routes can fail together or recover at different stages of the same underlying incident.
The Real Story Is the Dependency Map
The October disruption therefore reveals more about payment infrastructure than a simple “Monnify was down” headline would suggest.
PawaPay saw a nearly 37-hour incident. Monnify published changing maintenance timelines. dLocal experienced two separate Monnify-Moniepoint disruption windows and recovered at different times from PawaPay.
Those differences matter because fintech infrastructure is increasingly sold as a unified API over fragmented local payment rails.
When everything works, that abstraction is the product.
When it fails, the underlying dependency map suddenly becomes visible.
The next useful question is therefore not simply whether Monnify has restored service. It is which Monnify products, banking connections and routing paths failed, and why one integration could appear healthy while another remained unavailable.
For merchants choosing payment infrastructure, that answer matters more than the headline uptime percentage. True redundancy depends not on how many providers a company connects to, but on how many independent failure paths those providers actually offer.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.