Payment processors reported a series of disruptions on November 5, 2026, affecting mobile-money deposits and payouts, card authorization and buy-now-pay-later transactions across Africa, Europe-facing payment infrastructure and Indonesia. Today’s payments roundup covers simultaneous Airtel Kenya failures reported by PawaPay and dLocal, two separate Worldpay incidents involving HSBC acquiring and alternative payments, an internal PawaPay payout-wallet problem in the Democratic Republic of Congo, recurring Orange DRC outages, a PalmPay interruption in Nigeria and an unresolved Xendit Indodana disruption.
Several incidents were resolved during the morning, while others remained active in the latest official updates reviewed. The providers did not disclose affected transaction volumes, merchant losses or comprehensive root-cause reports.
Airtel Kenya failures hit PawaPay and dLocal simultaneously
Two independent payment processors reported problems involving Airtel Kenya at exactly 06:00 UTC on November 5, providing unusually clear evidence of overlapping disruption across separate payment integrations.
PawaPay identified an outage affecting Airtel Web Deposit and Payout services in Kenya. The provider began reporting improved transaction success rates at 06:59 UTC and declared the incident resolved at 09:07 UTC, approximately three hours and seven minutes after its initial notice.
dLocal independently acknowledged Airtel payment-processing difficulties in Kenya at 03:00 GMT-3, equivalent to 06:00 UTC. The company said it had contacted the processor and was investigating the problem. Its incident was marked resolved at 03:57 GMT-3, or 06:57 UTC.
Same start time, but not the same recovery time.
The simultaneous disclosures suggest that the disruptions may have originated in a shared Airtel-related payment service or another upstream dependency rather than two wholly independent processor failures. Neither company confirmed a common technical cause, and the matching timestamps alone cannot establish where the fault originated.
PawaPay had already experienced another Airtel Kenya incident earlier that morning. That disruption began at 00:38 UTC and affected betting-related web deposits, USSD deposits and payouts. Services were marked recovered at 04:09 UTC, giving the earlier incident a recorded window of three hours and 31 minutes.
The second outage followed less than two hours after the first recovery. PawaPay’s two incidents involved different configurations of Airtel services, and it has not established whether the same underlying fault returned.
The incident adds to a sequence of recent disruptions involving dLocal, including payment-processing problems reported by dLocal and other providers on November 3. Those earlier incidents concerned different payment systems and markets, with no confirmed connection to Kenya.
Neither PawaPay nor dLocal specified how many Kenyan merchants experienced rejected deposits, delayed payouts or transaction states requiring later reconciliation. The seperate recovery times also leave open whether both processors depended on precisely the same upstream components.
PawaPay reports internal DRC wallet fault and recurring outages
PawaPay separately acknowledged an internally attributed payout-wallet problem affecting mobile-money services in the Democratic Republic of Congo, distinguishing it from the operator-side failures that frequently appear in the company’s incident history.
At 04:43 UTC, PawaPay identified an issue on its own side involving a payout wallet. Although the incident was broadly titled as affecting DRC mobile-network-operator services, its affected component specifically identified Vodacom Payout.
At 11:03 UTC, the company reported improving transaction success rates and moved the incident into monitoring. It had not published a final resolution notice in the latest record reviewed.
The problem was on PawaPay’s end this time, at least as it described it.
The reference to an internal payout wallet narrows the investigation toward PawaPay’s own payment infrastructure. The disclosure does not specify whether the failure involved wallet-balance reconciliation, transaction processing, internal routing or another technical component. It provides no evidence of missing customer funds or a compromised wallet.
Another DRC incident emerged at 09:09 UTC, when PawaPay reported renewed instability involving Orange services. The affected components included Orange Web Deposit and Payout, although a later update at 10:57 UTC specifically described continued degradation in the payout gateway.
It was back again, and quite quickly.
PawaPay had resolved a previous Orange DRC incident at 22:42 UTC on November 4. The latest incident began approximately 10 hours and 27 minutes after that recovery notice. The company again referred the problem to the mobile-money operator, without confirming whether the two episodes shared a cause.
Nigeria recorded another interruption during the same morning. PawaPay reported degraded PalmPay Payout performance at 01:59 UTC, noted improving success rates at 02:44 UTC and declared recovery at 04:33 UTC. The recorded disruption lasted approximately two hours and 34 minutes.
The Nigerian incident was specific to the PalmPay payout channel through PawaPay, rather than evidence that all PalmPay services were unavailable. No figures were published for delayed disbursements or transactions requiring manual retries.
These disruptions involve both internally managed and third-party payment components. A Bank for International Settlements review of cross-border payment supervision identifies operational resilience, third-party dependencies and consumer protection among the risks that regulators should address when overseeing payment service providers.
PawaPay’s November 5 disclosures do not establish a regulatory violation. They do, however, identify where the provider attributed responsibility in each incident, information that would be relevent to assessing the resilience of its payment arrangements.
Worldpay suffers HSBC acquiring and alternative payment faults
Worldpay reported two separate authorization and payment incidents on November 5, including a technical problem involving HSBC acquiring and a subsequent interruption affecting its Alternative Payments Platform.
The first incident, INC0718460, was reported at 06:57 UTC. Worldpay warned that a third-party technical problem involving HSBC as acquirer could cause transaction-processing errors on the Worldwide Payment Gateway (WPG).
At 07:33 UTC, Worldpay confirmed that the problem was continuing and that its technical teams were working with the third party. At 08:15 UTC, the processor announced that the technical issue had been resolved and services were operating normally.
The incident covered a 78-minute interval between the first public notice and the resolution notice. Worldpay did not specify the exact technical failure, the number of authorization attempts affected or whether any merchants needed to resubmit transactions.
The disclosure concerned HSBC’s acquiring connection through Worldpay, not HSBC’s entire banking operation.
A second incident, INC0718658, affected selected alternative payment method traffic between 10:05 and 10:25 UTC. Worldpay confirmed at 10:55 UTC that the technical problem on its Alternative Payments Platform had been resolved.
Two incidents in one morning, and not quite the same systems.
Unlike the earlier HSBC notice, the second disclosure did not name an acquiring bank or external provider as the source. Worldpay also did not establish whether any shared routing or authorization dependency contributed to both events.
The disruptions follow Worldpay’s October 29 payment-processing failure, when an internal database problem affected card payouts, online refunds and order-management functions after scheduled maintenance.
That earlier incident involved a broader range of post-authorization services, while the November 5 problems concerned acquiring-related processing errors and selected alternative payment traffic. The operational histories show multiple incidents affecting different components, but not a single recurring defect.
Worldpay has not disclosed whether either November 5 interruption caused completed payments to be duplicated, customer purchases to be abandoned or merchant settlements to be delayed. Those outcomes cannot be established from the incident notices alone.
Xendit Indodana disruption blocks new payment transactions
Indonesian payment processor Xendit reported a partner-side failure involving Indodana PayLater on November 5, warning merchants that attempts to create transactions through the payment channel were returning errors.
The disruption was identified at 15:22 Western Indonesian Time, equivalent to 08:22 UTC. Xendit attributed the problem to its payment partner and said it was working to restore normal operations.
Unlike incidents involving delayed webhooks or merchant notifications, the Indodana failure directly affected transaction creation. Merchants could encounter errors before customers could complete the PayLater payment process.
A merchant could not simply wait for the usual confirmation message if the transaction had never been created successfully in the first place.
The problem follows Xendit’s earlier GCash payment disruptions, which involved both transaction-creation problems and unusually long payment-notification delays. During the GCash incidents, Xendit reported maximum callback latency exceeding nine hours and advised merchants to reconcile affected payments.
The Indodana case is operationally different. The published November 5 notice identifies errors at the creation stage but does not explain whether the underlying defect sits within Indodana’s own infrastructure or its integration with Xendit.
At the latest check, the incident remained unresolved, with no recovery estimate or affected transaction count availble. The provider had not said whether merchants could successfully route impacted purchases through alternative financing channels.
Across the November 5 incidents, the confirmed failures affected distinct stages of payment processing: initiating deposits, executing payouts, authorizing transactions and creating checkout payments. The available records identify individual restoration times and, in several cases, the responsible integration, but provide no reliable basis for calculating merchant losses or assuming a common technical cause across the different providers.
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. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574