Xendit’s GCash failures shift as Paysafe outage drags on

Neither company disclosed the number of affected merchants, transaction volumes or financial losses. However, the status records provide unusually detailed evidence of the duration, frequency and changing nature of the disruptions.

Xendit records five GCash failures in 11 hours

Xendit’s GCash e-wallet payment channel experienced five separate incidents between 19:32 Cairo time on October 29 and 06:03 on October 30, covering approximately 10.5 hours.

The first four incidents involved intermittent charge-creation timeouts and HTTP 503 responses carrying the CHANNEL_UNAVAILABLE error. Xendit’s status history showed that the affected proportion of requests reached 8.0% during the first incident, followed by 5.4%, 6.1% and 5.8% during subsequent disruptions.

The incidents occurred during the following windows:

October 29: 19:32–19:42, 21:35–21:53 and 22:21–22:31 Cairo time.

October 30: 03:10–03:19 and 05:24–06:03 Cairo time.

Each recovery was followed by another disruption, suggesting that the earlier restorations did not produce lasting stability throughout the observation period.

The fifth incident was materially different. Rather than primarily reporting failures when merchants attempted to create charges, Xendit said transactions could be initiated successfully but payment-completion notifications were arriving late.

The company reported callback latency reaching 33,067.661 seconds, equivalent to approximately nine hours and 11 minutes. This was the maximum latency metric reported during the monitoring window, not evidence that every affected payment confirmation was delayed by that amount.

Importantly, Xendit explicitly instructed merchants to reconcile transactions initiated during the incident. It also recommended directing customers toward alternative e-wallet providers until the disruption was resolved.

All five GCash incidents were subsequently marked resolved. However, their progression from transaction-creation failures to extreme callback latency makes the sequence more significant than five ordinary short-lived outages.

Xendit also reported a separate BNI Virtual Account notification problem on October 30. Beginning at 08:54 WIB, equivalent to 03:54 Cairo time, the issue delayed payment callbacks and status notifications while customer payments continued processing. Xendit marked that incident resolved at 11:27 WIB, or 06:27 Cairo time.

The BNI disruption was separate from the GCash incidents, and there is no evidence that the two shared a technical cause.

Paysafe’s PagoEfectivo outage passes 14 hours

Paysafe’s PagoEfectivo disruption began at 21:01 UTC on October 29, equivalent to 23:01 Cairo time, under incident reference INC0327837.

The incident affected a broad group of services associated with PagoEfectivo in Peru, including the CCE electronic clearing system, CIP generation, merchant portal, merchant notifications, PagoEfectivo Wallet, Niubiz, GMoney, Banco de Crédito del Perú, QR payments and BBVA.

Paysafe initially acknowledged the service problem at 21:01 UTC. An investigating update followed at 21:59, before the company announced at 22:35 that it had identified the root cause and was working on a solution.

However, identifying the cause did not translate into an immediate recovery.

Further updates appeared at 00:50, 02:06, 04:11 and 08:07 UTC on October 30. At 08:07, Paysafe said its technical teams were still working through validation, remediation and recovery activities.

The situation remained unresolved in the subsequent 10:06 UTC update. Paysafe said the affected services were being kept temporarily unavailable as a precaution while technical remediation continued and the environment was validated before a controlled restoration.

By the time of this review, more than 14 hours had passed since the original incident announcement, without a published resolution.

The latest component-status snapshot also showed differences across the affected infrastructure. Merchant Portal, Merchant Notification and PagoEfectivo Wallet were marked operational, while CCE, CIP Generation, Niubiz, GMoney, BCP, QR Payments and BBVA continued to show major outages. The overall PagoEfectivo incident remained open.

One additional detail deserves attention: Paysafe had scheduled PagoEfectivo maintenance from 21:00 to 23:00 UTC on October 29, with minimal service impact expected. The major incident was reported at 21:01, just one minute after that maintenance window began.

The timing is notable, but Paysafe has not established a connection between the scheduled maintenance and the subsequent outage. It would therefore be premature to attribute the incident to the maintenance activity.

Delayed callbacks create a different risk from failed payments

The most important distinction between Xendit’s two GCash failure modes concerns what happens after a customer attempts to pay.

An HTTP 503 response generally indicates that the requested service is temporarily unavailable. Merchants can identify the failed request and apply retry procedures, subject to checking whether the transaction was created or processed before the error was returned.

Delayed callbacks create a more complicated situation. A customer may successfully complete a payment through GCash while the merchant’s order-management system continues showing the transaction as pending because confirmation has not arrived.

If the customer retries using another payment method, the original payment could subsequently be confirmed. Without appropriate transaction reconciliation and idempotency controls, merchants risk duplicate payment attempts, incorrect order statuses or fulfillment disputes.

This is not evidence that duplicate charges actually occurred during Xendit’s incidents. Rather, it explains why the company’s explicit reconciliation warning is important.

Dave Finances previously examined a similar issue when Xendit recorded 20 LinkAja QR failures in 14 hours. That sequence also involved repeated recoveries and delayed payment-completion notifications, demonstrating how short disruptions can create operational work long after a channel returns to normal.

The company has also experienced repeated payment failures across Indonesia and the Philippines, involving several e-wallets, banking partners and QR-payment routes. These earlier cases do not establish a common technical cause, but provide context for the recurring challenges of managing third-party payment dependencies.

Paysafe presents a different problem. Its PagoEfectivo incident involved a wider group of connected services, with recovery requiring additional technical validation before services could safely return.

Payment infrastructure reliability becomes the bigger issue

For merchants, the commercial consequences of payment interruptions extend beyond the number of minutes a provider reports as unavailable. Failed charge requests can reduce checkout conversion, while delayed confirmations create reconciliation costs and uncertainty over whether customer orders have actually been paid.

For payment processors, repeated incidents involving the same partner can also weaken merchant confidence in the reliability of individual payment methods. A unified API may simplify integration, but it cannot eliminate the operational risks of the underlying banks, e-wallets, clearing systems and notification infrastructure.

Paysafe’s latest incident is particularly relevant because the initial root-cause identification was followed by more than 11 hours of recovery work. The company was not simply waiting to discover what had failed; it was attempting to remediate and validate a wider environment before restoring services.

That distinction highlights the importance of recovery planning and third-party dependency management. The Bank for International Settlements’ CPMI-IOSCO discussion paper on financial infrastructure reliance on third-party service providers examines how dependencies on critical external services can amplify operational risks. Although its direct focus is financial market infrastructures rather than these specific payment processors, the broader resilience challenge is relevant to both incidents.

Paysafe has faced other prolonged payment disruptions during October. Its earlier paysafecard API incident, for example, remained unresolved for more than 60 hours, raising separate questions about recovery capabilities across its payment infrastructure. The previous Paysafe outage provides additional context, although the two incidents involve different services and should not be assumed to share a root cause.

For Xendit, the next important indicator is whether GCash maintains stable transaction creation and callback delivery after the five recovery cycles. Merchants will also need to establish whether delayed transactions were fully reconciled and whether any payment confirmations remained outstanding after the incident closed.

For Paysafe, the immediate priority is a confirmed restoration of the remaining affected PagoEfectivo components, followed by an explanation of the technical cause and the extended validation process.

Neither incident establishes a material financial loss for either company. However, both demonstrate why payment infrastructure reliability should be measured through successful transaction completion and accurate confirmation, not simply whether an API or payment gateway appears operational.

For merchants, the difference between a failed payment and a payment awaiting confirmation can determine whether an order is lost, duplicated or incorrectly fulfilled. That makes reliable recovery and reconciliation just as important as preventing the initial disruption.