Lightning payments fail when liquidity is not where it needs to be, not because the protocol breaks. River's 2023 Lightning report measured a 99.7% success rate across 308,000 payments and traced nearly every failure to liquidity placement. The tools that solve this, reliability measurement and machine-learned liquidity placement, already run in production. They are just not evenly distributed across the network yet.
Lightning is Bitcoin's payment layer. It settles transactions in under a second for a fraction of a cent by moving value through payment channels: two-party accounts pre-funded with bitcoin. A channel can only carry what its balance allows, so where that balance sits determines whether your payment goes through. William Gibson's line about the future applies directly to Lightning liquidity: the solution is already here, it is just not evenly distributed.
Why do Lightning payments fail?
The most common failure is a routing timeout: the sender's node cannot find a path where every channel along the way has enough balance to forward the amount. The second is that no route exists at all, usually because the receiver is offline or lacks inbound liquidity, the receiving-side channel balance needed to accept funds. Application errors like malformed invoices are rare by comparison.
River, which routed 6.6 million Lightning transactions in August 2023 alone, breaks failures on its nodes into four buckets:
| Failure reason | What it means | Root cause |
|---|---|---|
| Timeout searching for route | No path with enough liquidity was found in time | Poorly placed liquidity along the path |
| No route found | No usable path exists, often because the receiver is offline | Receiver-side provisioning and uptime |
| Insufficient balance | The sender does not have enough spendable balance | Sender-side liquidity |
| Incorrect payment details | The invoice (Lightning's payment request format) is wrong or stale | Application bug, not a network issue |
The report is direct about the ranking:
The most common reason why a Lightning payment fails is a timeout when searching for a route. This happens when no route can be found that has enough liquidity across the entire path.
River, The Lightning Network Grew by 1212% in 2 Years, October 2023
Notice what is missing from that list: cryptographic failures, double spends, or lost funds. Failed Lightning payments are provisioning problems, and provisioning problems are fixable.
Is a 99% Lightning payment success rate good enough?
No. A business processing 100,000 payments a month at a 99% success rate eats 1,000 failures: lost checkouts, stuck payouts, and support tickets. Card networks treat a 1% technical failure rate as an incident. Lightning operators who invest in liquidity do far better, which shows the gap is operational, not structural.
The trajectory in River's own data makes the point. Its routed-payment failure rate was 2.6% to 3% in 2022. By August 2023 it had pushed success to 99.7% on the same network, same protocol. What changed was how the operator managed liquidity, uptime, and routing, not anything about Lightning itself.
The lesson for anyone evaluating Lightning: do not ask "what is Lightning's success rate?" Ask "what is this provider's success rate, at my payment sizes, to my destinations?" The variance between operators is far larger than the variance in the protocol.
Are failed Lightning payments a protocol problem?
No. When a Lightning payment fails, funds are never lost or stuck in transit: the payment either completes atomically or returns to the sender. The failure is a routing outcome, meaning the network could not find enough well-placed liquidity between two specific points at a specific amount. That is a resource allocation problem layered on top of a protocol that works.
Research backs this up. In Optimally Reliable and Cheap Payment Flows on the Lightning Network, René Pickhardt and Stefan Richter showed that smarter pathfinding alone, with zero protocol changes, transforms deliverability:
Early experiments indicate that our approach increases the size of payments that can be reliably delivered by several orders of magnitude compared to the current state of the art.
Pickhardt and Richter, arXiv preprint, 2021
If failure were baked into the protocol, better algorithms could not produce orders-of-magnitude gains. They can, because the bottleneck is where liquidity sits and how routes are chosen.
How do you measure Lightning payment reliability?
A single success-rate number hides more than it reveals, because reliability depends on the payment amount and the destination. The honest measurement is a curve: the probability that a payment of a given size succeeds. Amboss computes this with max flow, a network-theory method that calculates how much value can actually move between two points given every channel constraint in between.
The method, described in our breakdown of max flow as Lightning's key metric, samples thousands of sender-receiver pairs across real network snapshots and fills in unknown channel balances with statistical estimates. The output reads like an SLA: this node can reliably receive $100 but not $1,000; that region of the network handles retail payments well but not payroll.
Public network data gives the raw inputs. As of September 2023, roughly 5,000 BTC (about $133 million at the time) sat in public Lightning channels per River's report, and live network statistics track capacity, channels, and fees in real time. Measurement turns "Lightning sometimes fails" from a rumor into a list of specific, fixable gaps.
How is the Lightning liquidity problem being solved?
In two layers: place liquidity where payments actually want to go, and stop making application developers manage it by hand. The first is an optimization problem. The second is a product problem. Both are solved today, in production, by specialists operating at network scale rather than by every business running its own node and learning channel management.
On placement, Amboss built MPFlow, a deep reinforcement learning agent that decides which channels to open to maximize how much payment volume a node can move. Per the peer-reviewed preprint, MPFlow has executed 4,640 channel-open decisions allocating 267.3 BTC, worth over $16 million, across 30 production nodes, and it consistently beats the connect-to-the-biggest-hub heuristics most operators still use.
On abstraction, the industry's old answer was "buy a channel," which forced every developer to learn inbound liquidity, channel lifecycles, and fee policies just to receive money. The better answer is an API where reliability is the provider's job and the business just sends and receives.
None of this is hypothetical. The machinery runs today. What remains is distribution: most of the network still allocates capital with connect-to-the-biggest-hub heuristics and default settings, which is why reliability varies so much from one operator to the next. Closing that gap is deployment work, not research.
Amboss Payments is that API: it lets businesses accept bitcoin and stablecoin payments over Lightning while funds settle to their own custody, with liquidity placement and routing managed behind the scenes by the same systems described above. If your interest in this topic comes from failed payments in production, start with Amboss Payments and make reliability someone else's full-time job.
Frequently asked questions
Do Lightning payments fail more often for large amounts?
Yes. Reliability falls as the payment amount rises, because larger payments need more balance available along every channel in the route. A $5 payment to a well-connected node succeeds almost every time, while a $5,000 payment to a poorly provisioned one often fails. This is why reliability should be quoted as a curve by amount, not a single percentage.
Do you lose money when a Lightning payment fails?
No. Lightning payments settle atomically: either every hop in the route completes and the receiver is paid, or the whole payment unwinds and the sender keeps their funds. A failed payment costs a retry, not money. This is different from a failed card payment, which can leave authorization holds on the customer's account for days.
What is inbound liquidity on the Lightning Network?
Inbound liquidity is the capacity on the receiving side of your channels, which determines how much you can be paid. A new node with fresh channels has outbound capacity (it can send) but no inbound capacity (it cannot receive) until a peer commits balance toward it. Missing inbound liquidity is the most common reason invoices from new nodes cannot be paid.
Is Lightning reliable enough for production payments?
Yes, when the operator treats liquidity as an engineering discipline. River sustained a 99.7% success rate across 308,000 payments in August 2023, and routed volume network-wide grew 1,212% in two years per its report. Providers that measure reliability and place liquidity deliberately reach production-grade rates; unmanaged nodes with default settings do not.
How can a business avoid failed Lightning payments?
Use a provider that manages liquidity for you rather than running an unprovisioned node. Ask any candidate for their measured success rate at your typical payment sizes, how they provision inbound liquidity, and what happens when a route cannot be found. Amboss Payments handles placement and routing behind an API while payments settle to custody you control.