Xendit recorded six separate LinkAja QR payment disruptions in less than five hours on October 8, while two other Indonesia payout incidents affected transactions only within specific rupiah value bands that changed while engineers were working on the problem.
The incidents were all ultimately resolved and Xendit attributed them to systems operated by its partners rather than its own core infrastructure.
But the pattern is more unusual than a conventional payment outage.
During the LinkAja problems, merchants could still successfully initiate QR transactions even though payment-completion callbacks could be delayed. Xendit repeatedly warned that the successful-payment rate had fallen below its normal threshold and that merchants would need to reconcile transactions initiated during the affected periods.
Separately, the payout disruptions did not take entire banks offline. Instead, failures appeared only above or below precise IDR thresholds, with those boundaries changing several times before service normalized.
Together, the events show two different ways payment infrastructure can become operationally difficult without going completely offline: transactions can remain possible while their final state becomes uncertain, or they can fail only when their value crosses an invisible routing threshold.
LinkAja Failed Six Times Between 9:00 and 13:51 WIB
Xendit’s official status page shows six distinct LinkAja QR incidents on October 8.
The first began at 09:00 WIB and was declared resolved at 09:05. A second began at 09:50 and lasted until 10:08.
Service degraded again at 11:33 and recovered at 11:42, followed by another incident from 12:16 until 12:23.
The final two disruptions came in rapid succession. One began at 13:33 and was marked resolved just one minute later. Ten minutes after that recovery, another incident started at 13:44 and continued until 13:51.
That means LinkAja moved between degraded and resolved states six times during a four-hour-and-51-minute period.
The incidents collectively lasted about 47 minutes, but cumulative downtime understates the merchant problem because each recovery potentially created a new boundary between transactions initiated while the channel appeared healthy and those initiated while payment completion was impaired.
The QR Code Could Work Even When the Payment State Did Not
Xendit’s repeated incident wording is important.
The company did not say merchants were unable to create LinkAja transactions. Instead, it said transactions could still be initiated successfully while merchants were likely to receive delayed callbacks confirming payment completion.
That creates a different operational problem from a hard outage.
In a simple outage, the merchant knows the payment channel is unavailable and can immediately redirect the customer elsewhere.
A delayed callback creates uncertainty.
The customer may have completed the payment while the merchant’s order-management system still considers the invoice unpaid. An automated merchant workflow that relies on the webhook could therefore wait to release goods or services until confirmation finally arrives.
Xendit’s own reconciliation documentation explains why this matters. Its transaction-reconciliation process exists to ensure that orders and payments remain correctly matched and specifically helps prevent situations where unpaid services are delivered or valid payments cannot be associated with the corresponding order.
The company also says temporary connectivity problems or delays from banking and payment partners can create missing transactions because callbacks arrive late or fail.
Repeated Recovery Cycles Make the State Problem Harder
One LinkAja outage would create a defined reconciliation window.
Six short outages create six.
That matters for merchants trying to determine whether they can trust the real-time state displayed in their own systems.
A transaction submitted at 09:45 WIB, for example, falls between the first recovery and second incident. One submitted at 09:55 falls inside the next degradation period. Similar boundaries recur throughout the morning.
Xendit explicitly told merchants that transactions initiated during the incidents would require status reconciliation and recommended moving customers to another e-wallet provider until the issue was resolved.
The potential downstream consequences include stale order states and customers retrying transactions because a merchant still shows an invoice as unpaid after funds have actually moved.
There is no evidence that such duplicate payments or merchant losses occurred on October 8. They are operational risks created by delayed confirmation, not confirmed outcomes of these incidents.
That distinction is important because modern payment systems increasingly depend on layers of middleware, external partners and asynchronous status updates. Dave Finances previously examined how complex payment stacks create reconciliation dependencies between multiple financial systems, even when the consumer-facing application appears seamless.
Xendit’s Payout Failure Started With a Very Specific BCA Range
Hours before the LinkAja sequence began, Xendit recorded a separate Indonesia payout disruption affecting BCA.
The incident started at 04:20 WIB on October 8, equivalent to 00:20 in Cairo.
Initially, Xendit said delays affected BCA payouts and disbursements between IDR 10,000 and IDR 50 million.
Ten minutes later, the affected range expanded dramatically to IDR 5,000 through IDR 250 million.
The incident was resolved at 05:00 WIB.
The unusual feature is the presence of lower and upper thresholds rather than a complete BCA payout outage.
A transfer below IDR 10,000 or above IDR 50 million was initially outside the announced problem range, even though an otherwise identical transfer inside that band could be delayed.
The Second Payout Incident Changed Its Thresholds More Than Once
A second Indonesia payout incident started at 08:00 WIB and was even more granular.
Xendit initially said Permata transfers were delayed when their value was between IDR 1 and IDR 7,999 or above IDR 100,000,001.
By 08:10, the problem had expanded to other banks and e-wallets.
For those destinations, affected amounts were IDR 1 through IDR 9,999 and IDR 100,000,001 through IDR 250 million. Permata retained its original lower band and remained affected above IDR 100,000,001.
At 10:40, the boundaries changed again.
The broad lower range narrowed to IDR 1 through IDR 4,999. Permata’s high-value problem also shifted, with the bank then affected above IDR 250,000,001 rather than above IDR 100,000,001.
The incident was fully resolved at 12:20 WIB.
The Exact Amount Bands Point Toward Routing or Limit Logic
Xendit has not publicly disclosed the technical root cause behind those thresholds beyond attributing the disruption to a partner system.
That means it would be premature to say exactly what happened.
But a failure divided by transaction value is fundamentally different from a bank being unreachable.
Payment platforms can route transactions differently depending on destination, amount, partner limits, liquidity arrangements, risk controls or the rail used to execute the transfer. Precise boundaries such as IDR 100,000,001 and IDR 250,000,001 strongly suggest that some processing rule changes when transactions cross those points.
The fact that the bands changed during the incident is even more interesting.
One possibility is that Xendit or its partner progressively restored individual routing paths. Another is that engineers changed which transaction ranges were being directed through affected infrastructure as mitigation continued.
Neither explanation has been confirmed.
What can be established from the status updates is that the failure was segmented by transaction amount and that the segmentation itself changed before recovery.
Payment Reliability Is More Than an Uptime Percentage
The October 8 events illustrate why payment-infrastructure reliability cannot be measured solely by whether an API endpoint responds.
During the LinkAja incidents, transaction initiation continued even though completion notifications were impaired.
During the payout incidents, some transfers could proceed while otherwise similar transfers to the same market encountered delays solely because their values fell inside particular ranges.
Both situations can look partially healthy from the outside.
For merchants, however, the difficult part is determining which transaction state should be trusted.
Xendit recommends reconciling merchant order records against gateway and balance reports, and says partner outages can sometimes mean missing transactions are only identified later through automated reconciliation.
Its reconciliation policy also recognizes that partner notifications are not always real-time and says repeated partner failures can lead to operational reviews or changes in processing requirements.
This type of dependency is becoming more significant as fintech companies build broader payment stacks across banks, wallets and third-party processors. Dave Finances has also followed the growth of multi-rail payment platforms attempting to connect different settlement systems behind a single merchant interface.
The Next Question Is What Happened at the Thresholds
All of the October 8 incidents were resolved, so there is no evidence of an ongoing Xendit outage.
The more useful follow-up is architectural.
For LinkAja, the question is why the same partner connection repeatedly recovered and degraded six times in under five hours, and whether merchants experienced any duplicated customer attempts, stale orders or manual reconciliation burden as a result.
For payouts, the question is what exactly changes when an Indonesian transfer moves from IDR 4,999 to IDR 5,000, from IDR 7,999 to IDR 8,000 or across the IDR 100 million and IDR 250 million boundaries.
Those thresholds may expose the routing structure underneath a payment interface that ordinarily hides it.
That is what makes the October 8 incidents more interesting than a conventional service interruption.
Xendit did not simply experience a period when payments were “down.” Some transactions could be created while their confirmation lagged. Other payouts failed only inside changing value ranges.
For merchants building automated systems around those rails, the real infrastructure risk is therefore not always that a payment stops.
Sometimes it is that the payment keeps moving while the systems responsible for telling everyone what happened fall temporarily out of sync.
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.