Xendit’s long-running Indonesia payout disruption was finally declared resolved on October 12, only for essentially the same failure pattern to return twice within the next 70 minutes, turning what looked like the end of a multi-day incident into a much more troubling recovery story.
The payment infrastructure company marked the original incident resolved at 13:00 WIB on Sunday. Forty minutes later, Xendit opened another Indonesia payout incident involving Permata and a broad range of other banks and e-wallets. That disruption was declared resolved at 13:50.
It did not last.
At 14:10 WIB — just 70 minutes after the original outage had supposedly ended — Xendit opened a third incident with almost the same transaction-value pattern. More than four hours later, the problem was still active.
At the same time, Xendit disclosed a separate failure affecting Batch Payout and Payout Link. That incident was blocking bank-account validation, and by 18:15 WIB the company said recovery was taking longer than expected, the timeline remained uncertain and the disruption could be prolonged.
A Multi-Day Payout Incident Was “Resolved” for Just 40 Minutes
The first Indonesia payout incident began at 22:20 WIB on October 9 and developed into an unusually complex disruption lasting more than two and a half days.
Rather than simply knocking one bank offline, the problem repeatedly shifted between receiving institutions and precise rupiah transaction ranges. BCA, BNI, Mandiri, Permata and other banks and e-wallets appeared and disappeared from Xendit’s warnings, while affected transaction bands changed between low-value transfers, IDR50 million-to-IDR100 million transactions and much larger payouts.
Dave Finances previously tracked how Xendit’s Indonesia payout outage kept moving between exact amount bands, a pattern that suggested some form of amount-sensitive processing or routing deeper in the payment chain. Xendit did not disclose the underlying architecture and consistently attributed the delays to system issues involving a partner.
By 12:30 WIB on October 12, the remaining affected destinations were Permata transactions from IDR1 to IDR7,999 and above IDR100,000,001, along with transactions from IDR1 to IDR250 million for other banks and e-wallets.
At 13:00, Xendit marked the incident resolved.
That resolution lasted 40 minutes.
The Same Amount-Band Pattern Came Back Twice
At 13:40 WIB, Xendit reported another payout disruption. This time, Permata transactions from IDR1 to IDR9,999 and above IDR100,000,001 were affected, along with other banks and e-wallets from IDR1 through IDR250 million.
Xendit again blamed system issues involving its partner. Ten minutes later, at 13:50, the company marked that incident resolved.
Twenty minutes after that, another incident appeared.
The 14:10 warning listed Permata transactions from IDR1 to IDR7,999 and above IDR100,000,001, while other banks and e-wallets were again affected from IDR1 through IDR250 million.
The disruption continued through the afternoon. At 15:10, BNI was also listed for transactions from IDR1 to IDR9,999 and above IDR100,000,001. Later updates removed BNI again while retaining Permata and the wider bank and e-wallet ranges.
At 18:20 WIB, Xendit was still reporting delays in payouts, disbursements, remittance and escrow, with Permata affected at IDR1–7,999 and above IDR100,000,001 and other banks and e-wallets affected between IDR1 and IDR250 million.
The repeated recoveries are notable because Xendit has already shown similar instability elsewhere in its payment stack. On October 8, the company recorded six LinkAja QR failures alongside shifting Indonesia payout glitches, while October 10 produced an even more extreme sequence.
A Separate Failure Is Blocking Bank-Account Validation
The renewed payout disruption is not the only unresolved problem on Xendit’s status page.
Xendit says a separate disruption affecting Batch Payout and Payout Link began at 11:46 WIB on October 12. The company publicly posted the incident at 17:53, saying bank-account validation was experiencing failures and merchants were unable to receive a response from the validation step.
That distinction matters. The incident description does not say that underlying bank transfers themselves are failing. Instead, a prerequisite used to validate the destination account is preventing the payout workflow from progressing.
At 18:15, Xendit said information from its partners indicated recovery was taking longer than initially expected. It said the recovery timeline was uncertain and that the disruption “may be prolonged.”
Xendit has not publicly identified the partner responsible for the validation service, nor has it said whether beneficiaries that were already validated before the incident can continue receiving payouts. There is also no public evidence establishing that this validation failure and the separate amount-band payout incident share the same technical cause.
This Is Now a Recovery-Stability Problem, Not Just an Outage
The most important change in the story is what happened after Xendit pressed “resolved.”
A long outage is operationally painful, but relatively straightforward. Systems fail, traffic is stopped or queued, engineers repair the problem, and service resumes.
A service that repeatedly looks healthy and then fails again is harder to manage.
Xendit’s October 10 LinkAja history already demonstrated that problem when the company logged 20 separate LinkAja QR failures in 14 hours. Many individual outages were short, but repeated restoration meant merchants could repeatedly send fresh traffic into a channel that deteriorated again minutes later.
The October 12 payout sequence now raises a similar question at a more consequential layer.
Why did a payout system that had been affected for more than 62 hours appear sufficiently stable to be declared resolved at 13:00, only for nearly the same affected amount ranges to return 40 minutes later?
One possibility is that traffic was shifted back onto an upstream route or partner system that had not fully stabilized. Another is that recovery was uneven across different processing paths, with monitoring briefly showing acceptable conditions before performance deteriorated again.
Those are plausible technical explanations, not established facts. Xendit has not disclosed whether it was failing traffic over between partners, progressively restoring routes or simply responding to changes inside an external provider’s systems.
But the sequence makes the distinction between “recovered” and “stable” important.
The Validation Failure Shows How a Control Layer Can Stop Money Movement
The second incident illustrates another weakness of modern payment infrastructure: the transfer rail does not have to fail for the payout product to become unusable.
If validating the recipient’s bank account is mandatory before a Batch Payout or Payout Link can proceed, then the validation service is effectively part of the critical payout path. A failure there can stop a transaction even if the receiving bank, settlement rail and actual funds-transfer infrastructure remain healthy.
That is why dependency architecture matters so much in payments. A platform can have redundant banking connections and still have a single operational bottleneck somewhere earlier in the workflow.
The regulatory backdrop also makes resilience more than a purely technical concern. Bank Indonesia’s current payment-system industry rules, effective from March 31, 2026, place governance, risk management and payment-system infrastructure within the regulatory framework covering payment service providers and related participants.
For merchants, the unanswered questions are now practical rather than theoretical.
Does Xendit have another validation provider when the primary service fails? Can previously validated beneficiaries bypass the broken step? Can payouts be rerouted automatically when one upstream route becomes unstable? And what stability period does Xendit require before declaring a prolonged incident resolved?
The Oct. 12 sequence makes those questions more important because the system did recover — repeatedly. The problem is that recovery did not hold.
For payment infrastructure, that can be worse than a clean outage. A service that is clearly down tells merchants to stop sending traffic. A service that repeatedly switches between healthy and degraded states keeps inviting new transactions into an uncertain processing environment.
Until Xendit explains what changed between 13:00, 13:40 and 14:10 WIB, the strongest signal from the incident is no longer simply that a partner system failed. It is that Xendit’s recovery from that failure was unstable enough for essentially the same payout pattern to return twice within 70 minutes.
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