Xendit’s LinkAja QR payment channel failed and recovered 20 separate times on October 10, creating an unusual operational pattern in which most individual disruptions lasted only a few minutes but merchants repeatedly faced delayed payment-completion callbacks and post-incident reconciliation.
The first recorded LinkAja QR incident began at 08:55 WIB and was marked resolved at 08:59. By 22:33, Xendit had logged another 19 fail-and-recover cycles affecting the same payment method.
Across the day, the incidents began at approximately 08:55, 09:32, 09:57, 11:15, 12:52, 15:02, 15:49, 16:45, 17:01, 17:23, 17:41, 18:10, 18:38, 19:22, 20:26, 20:44, 21:36, 21:56, 22:12 and 22:26 WIB.
Added together, the published incident windows amount to roughly 101 minutes of disruption. But the more important number is 20.
This was not one prolonged outage. It was a payment rail repeatedly being declared restored and then failing again.
According to Xendit’s official status history, the underlying disruption was on a partner’s side. Xendit repeatedly said merchants could successfully initiate transactions but were likely to receive delayed callbacks confirming payment completion. It also said the successful-payment rate had fallen below its normal threshold.
Most Failures Lasted Only a Few Minutes
The individual outages were remarkably short.
The first lasted four minutes. Later incidents lasted 14 minutes, two minutes, five minutes, eight minutes, five minutes, three minutes and four minutes.
During the particularly unstable late-afternoon stretch, LinkAja failed at 17:01 and recovered at 17:03, failed again at 17:23 and recovered six minutes later, then failed at 17:41 before being marked healthy again at 17:43.
The median disruption during the 20-event sequence was only four minutes.
Normally, short recovery times would be reassuring. In a payment system, however, repeated short failures can create a different kind of operational burden from one continuous outage.
A merchant responding to a long outage can disable a payment method, direct users to alternatives and restore the channel once stability is confirmed.
With repeated fail-recover cycles, traffic can return each time the channel appears healthy, only for another group of transactions to enter an uncertain state minutes later.
The Dangerous State Was Not Necessarily “Payment Failed”
Xendit’s wording explains why this matters.
The company was not consistently telling merchants that LinkAja payments could not be started. It said payment initiation could succeed while the callback confirming completion arrived late.
That distinction matters because modern payment systems often have at least two relevant states.
The customer’s payment can succeed at the wallet or upstream payment provider, while the merchant’s own system still believes the transaction is pending because the asynchronous completion notification has not arrived.
That creates a reconciliation problem rather than a simple checkout failure.
Xendit explicitly told merchants after the incidents that reconciliation would be required for transactions initiated during the affected periods.
There is no evidence that the October 10 incidents actually caused widespread duplicate fulfillment or double charging. But delayed state confirmation creates the conditions in which merchants need to be especially careful about retries, order expiration and fulfillment logic.
If a customer sees an apparently stalled checkout and tries again through another payment method, the original LinkAja transaction may subsequently complete. A merchant that treats a missing callback as a definitive failure rather than an unknown state can then end up reconciling multiple attempts against one order.
Twenty Recoveries Can Be Harder to Operate Than One Outage
The operational question is therefore not simply how many minutes LinkAja was unavailable.
It is how many times merchants had to transition between failure and recovery states.
A conventional uptime calculation would make approximately 101 minutes of disruption across a 13-hour-and-38-minute observation period look relatively contained.
But that calculation hides the churn.
Every restoration potentially encourages automated systems and customers to route new transactions back to LinkAja. Every subsequent degradation creates another set of transactions whose final state may need to be checked later.
For merchants processing meaningful volumes, that can turn a short technical interruption into a longer operations task for finance, support and reconciliation teams.
The pattern illustrates the kind of middleware complexity that Dave Finances previously examined when looking at payment stacks built across multiple banking, processing and reconciliation layers. A customer sees one checkout option, but completing that payment can depend on several independent systems agreeing on its final state.
Why Was LinkAja Repeatedly Marked Resolved?
The status history raises a question that Xendit has not publicly answered: what threshold was being used to declare each incident resolved?
A channel can appear recovered based on improving success rates and then deteriorate again if an upstream service remains unstable.
That does not necessarily mean Xendit made an incorrect recovery decision. Payment networks often have no practical choice but to restore traffic once telemetry returns to acceptable levels.
But after repeated recurrences, merchants may prefer a longer stabilization window over rapid restoration.
By the tenth or twentieth incident, the trade-off changes.
Keeping LinkAja disabled for longer would block transactions that might otherwise succeed. Restoring it quickly increases availability but exposes another batch of payments if the partner deteriorates again.
Xendit’s public status entries do not disclose whether traffic was automatically failed over, manually re-enabled, progressively restored or simply remained available while the upstream partner moved in and out of normal performance.
That is the missing technical detail.
LinkAja Was Not the Only QR Channel Showing Instability
The October 10 history also shows separate QR incidents affecting Xendit’s own QR channel and DANA at other points in the day.
Those should not automatically be assumed to share the same root cause.
Each status record attributes the relevant disruption generally to a partner, and Xendit has not publicly identified one common infrastructure failure connecting all of them.
Still, their coexistence makes the status page unusually important for Indonesian merchants relying on several e-wallet and QR options rather than one payment rail.
Redundancy only works when the alternative routes themselves remain available.
The Better Metric May Be Reconciliation Events, Not Downtime
For payment processors, uptime is an intuitive metric because customers immediately understand whether a channel is working.
October 10 shows why it can also be incomplete.
A four-minute event during which every transaction hard-fails is operationally different from a four-minute event during which customers can initiate payments but merchants cannot immediately determine whether they completed.
The latter leaves work behind after the status page turns green.
Xendit acknowledged that directly by repeatedly instructing merchants to reconcile transactions from the affected windows.
That means the effective duration of the incident for a merchant may extend well past Xendit’s recorded resolution timestamp.
Twenty brief outages can therefore create 20 separate populations of transactions requiring state verification.
Nothing on the public status page establishes that merchants suffered material financial losses from the sequence, and Xendit has not disclosed the number or value of affected payments.
But the October 10 incident history provides an unusually clear example of why payment reliability is not simply about whether a rail is technically “up.”
When initiation works, completion confirmation lags and the same rail repeatedly moves between healthy and degraded states, the hidden cost shifts from downtime to uncertainty.
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.