# Lightning payment pending, failed or succeeded: when to retry 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. Evidence: [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) Canonical: https://degreesofsatoshi.com/encyclopedia/lightning-payment-status/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:29:20.637Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **In flight:** The payment remains unresolved ([Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md)) - **Succeeded:** The payment reached a successful final state ([Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md)) - **Failed:** The documented payment has a final failure state ([Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md)) ## 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. Evidence: [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) ## 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. Evidence: [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) ## 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. Evidence: [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md); [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md); [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) ## Questions ### 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. Evidence: [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md); [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) ### 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. Evidence: [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) ## Claims and scope ### lightning-payment-status-quick-answer 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: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-payment-status-fact-in-flight In flight: The payment remains unresolved Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-payment-status-fact-succeeded Succeeded: The payment reached a successful final state Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### lightning-payment-status-fact-failed Failed: The documented payment has a final failure state Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [Sending Payments](https://raw.githubusercontent.com/lightninglabs/docs.lightning.engineering/0456e1627b2579ac18108cb921fe609f87c8b009/lightning-network-tools/lnd/payments.md) — Lightning Labs. LND initiated/in-flight/succeeded/failed statuses and safe retry semantics. Locator: Pathfinding; Dispatching Payments; Payment Fees; Monitoring Payments. Retrieved: 2026-10-02T18:53:57.437Z. - [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md) — Lightning 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. Retrieved: 2026-10-02T18:53:57.096Z. - [BOLT 12: Negotiation Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/12-offer-encoding.md) — Lightning 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. Retrieved: 2026-10-02T18:53:57.136Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees 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/