Encyclopedia Upgrades and scaling · Entry 213
Lightning payment pending, failed or succeeded: when to retry
In this article
At a glance
Key facts
A failed route need not mean a failed payment
A route can fail because a node is offline, liquidity is insufficient or the allowed fee cannot support the path. The sender may try another route within the same payment operation. Routing nodes’ usable balances are not all publicly known in advance.
Once a conditional payment is locked along a route, it must resolve through success or timeout. The sender cannot always immediately treat those funds as available for another attempt.
A short timer can coexist with a longer pending payment
Suppose an application allows 30 seconds for dispatch. A payment dispatched during that period may still be waiting for settlement after the timer ends. Displaying a spinner for longer than 30 seconds does not prove the software violated that particular timeout setting.
Use the payment record and its identifier to track the same operation. Starting an unrelated second payment before the first resolves can lead to paying twice if both eventually succeed.
Keep the request, status and payment evidence together
In LND, TrackPaymentV2 reports In Flight, Succeeded or Failed. A final failure means that payment operation will not automatically be attempted again; a separate retry is a new decision made after understanding the failure.
For an invoiced payment, retain the invoice and available payment evidence. A preimage matching the invoice supports that it was paid, but does not on its own identify the human payer.
Direct answers
Questions people ask
Does invoice expiry automatically cancel an in-flight payment?
No. The deadline for starting an invoice payment and resolution of an already committed payment are different. Inspect its final status rather than using invoice expiry as proof of failure.
Can one payment try more than one route?
Yes. The sender can attempt different paths, and supported multi-part payments can split an amount. A route attempt and the overall payment should not be confused.
Inspect the evidence
The answer and key facts have stable claim links. These records retain the scope and qualification when reused.
A Lightning payment can be in progress, successful or finally failed. Several route attempts may belong to one payment, and an interface timeout does not always resolve funds already committed along a route. In LND, the dispatch timeout limits time spent trying to send; it is not a guarantee that the complete payment settles within that time. Check the recorded final status before sending a separate replacement payment.
Educational explanation. Product-specific behavior is scoped to the cited documentation, checked 2026-10-02.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimIn flight: The payment remains unresolved
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimSucceeded: The payment reached a successful final state
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimFailed: The documented payment has a final failure state
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimRevision history
- — First publication after primary-source research and separate automated verification.
Source register
Sources and references
Retrieval dates and locators are recorded individually.- Sending PaymentsLightning Labs
LND initiated/in-flight/succeeded/failed statuses and safe retry semantics.
Locator: Pathfinding; Dispatching Payments; Payment Fees; Monitoring Payments · Version / scope: Pinned Lightning Labs documentation revision; LND/Loop implementation scope · Retrieved: 2026-10-02T18:53:57.437ZOpen source - BOLT 11: Invoice Protocol for Lightning PaymentsLightning specification contributors
Invoice amounts, payment hashes, expiry, signing and feature constraints.
Locator: Human-Readable Part; Data Part; Tagged Fields; Payer / Payee Interactions; Payer / Payee Requirements · Version / scope: Pinned BOLTs revision · Retrieved: 2026-10-02T18:53:57.096ZOpen source - BOLT 12: Negotiation Protocol for Lightning PaymentsLightning specification contributors
Reusable offers produce separate invoice requests and authenticated invoices.
Locator: Limitations of BOLT 11; Payment Flow Scenarios; Offers; Invoice Requests; Invoices; Payer Proofs · Version / scope: Pinned BOLTs revision · Retrieved: 2026-10-02T18:53:57.136ZOpen source
Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.
Editorial method and correctionsDegrees of Satoshi editorial project. “Lightning payment pending, failed or succeeded: when to retry.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/lightning-payment-status/