Lightning Payment In Flight: Check the Result Before Retrying

Do not create a second independent payment while the first Lightning payment is still in flight or its outcome is unknown. A waiting screen, disconnected app or expired interface timer is not a final failure. Recover the existing payment’s status using its record and payment hash, then reconcile it with the recipient before deciding whether to retry.

One purchase can acquire two different payment obligations

Imagine a fictional sender, Evan. He approves a Lightning invoice, sees a spinner and loses mobile connectivity. The seller suggests a new invoice while Evan’s original record still says pending. If he pays the new request from another wallet, the first operation has not thereby disappeared. He has introduced a separate payment that must be reconciled if the original later completes.

The useful question is therefore not how many times the Pay button was pressed. It is which payment each action refers to. Keep the original invoice, the wallet’s payment identifier and the seller’s order reference together. A renewed invoice, a second wallet and a seller’s new checkout link can each change the context. Do not assume their anti-duplicate protections are shared.

For a refresher on the request itself, see Lightning invoices versus Bitcoin addresses. The present task starts after a payment was initiated: it is a reconciliation problem, rather than an explanation of invoice formats or a recommendation to try another route.

Read the state at the right level

An individual routing attempt may fail while the wallet continues working on the payment. Conversely, losing the connection that delivered status updates tells you about that connection, not the result of every attempt. Keep an app-level error, a payment-level outcome and a routing-part outcome separate when describing the incident to support. This distinction is especially helpful when a technical log contains several apparently contradictory entries.

For an LND-based system, TrackPaymentV2 tracks updates for a payment identified by its payment hash. Its payment states distinguish an in-flight payment from a settled success or failure. You do not need to become a node administrator to use this distinction: ask the wallet operator to retrieve the existing payment, rather than interpreting a missing notification as authorization to send again.

A blank history is also inconclusive if you have opened a different wallet profile, switched networks or not finished synchronizing. Record which account actually initiated the payment. Reinstalling the app or restoring a wallet to another device merely to clear the spinner can make that investigation harder. Preserve the current history and use the wallet’s supported reconnection process first.

There are several clocks, and none is a refund receipt

A request’s expiry tells a payer when the invoice should no longer be used for a new payment. It is different from a mobile app’s waiting timer and from the conditions governing a payment already forwarded. An invoice passing its expiry while your screen is still pending is therefore not sufficient evidence that the payment failed or that its funds are immediately available for another attempt.

The current LND SendPaymentV2 reference expressly warns that cancellation can stop additional attempts while existing in-flight attempts can still settle. Its timeout description likewise does not promise to abort forwarded HTLCs immediately. Treat those as implementation-specific meanings, not a universal cancel button. Do not close channels, increase fees or start unrelated recovery operations merely to make a pending label disappear.

A different example comes from the Breez SDK sending guide. For its documented Lightning flow, a completion timeout can return a pending object, followed by later completion information. That is a product-specific API design, not a claim that every wallet uses Breez or Spark. It demonstrates why the caller finishing its wait and the payment reaching its final result must not be treated as the same event.

Ask for a status lookup, not another send

1. Save the original invoice, initiating wallet account, payment hash if exposed, amount, initiation time and merchant order reference.
2. Reconnect the same wallet and inspect that payment’s current detailed record. Keep screenshots of any change in state.
3. Ask the recipient to check the matching invoice, not just the overall account balance or a different order.
4. If pending remains, request an explicit status investigation from the wallet operator. Ask what evidence will establish final success or failure.
5. If successful, resolve any missing order credit with the recipient. If definitively failed, review the error and agree on the current invoice or a replacement before another payment.

Node operators have dedicated status queries as well. Core Lightning’s listpays documentation describes aggregate payment states and a lookup by invoice or payment hash. Its waitsendpay reference distinguishes a timeout while still waiting from a completed result. These references support the investigation; they are not instructions for a retail user to expose node credentials or run a payment command found in a forum.

When discussing a retry, distinguish returning to the wallet’s supported handling of the same payment from creating a new commercial obligation. Do not rely on the slogan that Lightning can never pay twice. Behaviour depends on the request format, wallet implementation and whether you have actually created a new request. Another wallet does not automatically know what the first wallet is still doing.

The recipient says unpaid, but the wallet says successful

Compare the payment hash, intended amount and exact invoice before comparing screenshots of balances. A successful payment to one request does not pay a different request merely because both were issued for the same purchase. Ask the seller to investigate its invoice and order mapping. Keep the proof available through your wallet’s supported interface; share it only with the party resolving the dispute, rather than publishing it as a public troubleshooting post.

A useful private message reads: ‘My wallet’s original payment is still pending. The order reference is attached, and the payment hash and initiation time are below. Please check this specific invoice and tell me whether you see it settled. I will hold off on a replacement payment until we reconcile the result.’ Once the state changes, update the message with the new evidence rather than starting another disconnected ticket.

If you ultimately agree on an alternative route, retain both the old and replacement references until the order is settled. A no-account swap has its own order and accepted destination requirements, while the Bitcoin asset page is background information. Neither is a status lookup for the pending Lightning payment. Resolve the original operation before treating another service as a replacement path.