Bitcoin Lightning Payment Pending? Find Out What Is Actually Pending

A Bitcoin Lightning payment marked pending can mean very different things. The sending app may not have started the Lightning payment yet, the node may be actively trying routes, an HTLC may already be locked and waiting to settle or time out, or the Lightning payment may have succeeded while a custodial service has not credited the recipient. The safest next step depends on which of those states is real. Do not send a second payment until you know.

First decide whether Lightning actually received a payment attempt

The word pending is often an application label, not a Lightning protocol state. A custodial wallet, exchange or payment app can debit or reserve your balance before its backend has successfully created or completed a Lightning attempt. If the service cannot show a payment hash, attempt record, Lightning-specific status or other evidence that a payment was handed to its Lightning infrastructure, treat the problem as platform-side until proven otherwise.

Use the Pending Ownership Test

Find the first layer that has not produced evidence. That layer identifies who still owns the next action.

• App Queue — did the wallet, exchange or merchant processor actually start a Lightning send, or is its own backend still processing it?
• Payment Attempt — did a Lightning node create a payment attempt for the invoice or payment hash?
• HTLC Resolution — is the attempt still in flight, already succeeded or permanently failed?
• Recipient Credit — if Lightning settled, did the receiving wallet or service credit the user-facing balance?

Case 1: the app says pending but there is no Lightning evidence

This is the most important consumer distinction. If a custodial sender only shows an internal transaction ID and a generic pending label, the delay may be inside that company's queue rather than inside the Lightning Network. Record the amount, time, invoice, internal transaction ID and recipient. Do not troubleshoot Bitcoin mempool fees because a Lightning payment is off-chain, and do not blame the recipient until the sender confirms that a Lightning attempt exists.

A Bitcoin mempool search usually cannot answer this question

A normal Lightning payment is not published as a standalone Bitcoin transaction, so there may be no transaction ID to paste into a Bitcoin block explorer. HTLC updates normally remain inside Lightning channels. An on-chain transaction becomes relevant only in exceptional channel-resolution paths, not as the normal receipt for a Lightning payment.

Case 2: the payment is IN_FLIGHT or pending at the node

LND currently reports a payment with active HTLCs as IN_FLIGHT. Core Lightning exposes payment status as pending, complete or failed. This is stronger evidence than an app spinner: it means a Lightning payment attempt exists and has not reached a final state yet.

Do not automatically retry an HTLC that is already locked in

Lightning Labs documents a critical boundary. If a payment fails before HTLCs become irrevocably locked along a route, another attempt can be safe. Once an HTLC is locked in, however, that attempt must resolve as success or failure. If the receiver does not reveal the preimage or a routing node disappears, resolution may wait for the HTLC timeout. Sending the same invoice again while the first attempt is genuinely unresolved can create duplicate-payment risk or conflicting wallet behavior.

Why a Lightning payment can remain in flight

A route is a chain of channel commitments, not one server request. A payment can be delayed while the sender searches or retries routes, while a multi-part payment waits for its parts, or while an already-committed HTLC waits for settlement or timeout. The precise cause is visible much more clearly to the sending node than to a third-party recipient.

The recipient's invoice status is a second source of truth

The recipient who created the invoice can check whether it settled. In LND, invoices can be queried by payment hash and settlement updates can be monitored. A recipient reporting 'settled' while the sender UI still says pending points toward a sender-interface or accounting delay. A recipient reporting 'open' or 'unpaid' does not by itself prove that no in-flight HTLC exists.

A payment preimage is the strongest proof of Lightning settlement

A successful Lightning payment reveals the payment preimage back toward the sender. Lightning documentation treats the preimage, together with the invoice or payment hash, as proof that the payment settled. If a self-hosted node reports SUCCEEDED or complete and exposes the preimage, stop trying to send again. Any remaining issue belongs to the merchant, recipient wallet or service accounting layer.

An expired invoice and a pending payment are not the same state

A BOLT11 invoice contains an expiry time, but invoice expiry and an already in-flight HTLC answer different questions. The invoice tells new senders when the payment request is no longer valid. An HTLC that was already committed must still resolve according to Lightning's timelock rules. Therefore, do not assume that seeing 'invoice expired' on the recipient side makes an existing in-flight attempt instantly safe to duplicate.

If no attempt was made before expiry, use a new invoice

When the sender can confirm that no Lightning attempt exists and the invoice has expired, ask the recipient to generate a fresh invoice. This is the clean branch. The separate problem 'lightning invoice expired what to do' starts from an expired request before or after an attempted payment and deserves its own recovery guide rather than being expanded here.

Case 3: the node reports FAILED

A final failed state closes the pending incident. LND distinguishes permanent failure reasons such as timeout, no route, incorrect payment details, insufficient balance and cancellation. If the failure is final and the recipient did not settle the invoice, a new attempt can be considered using a valid invoice. Diagnose a permanent no-route error separately because routing and liquidity are a different success state from a payment that is still pending.

Case 4: Lightning succeeded but the recipient balance did not change

If the sending node has settlement proof but the recipient-facing balance is unchanged, the Lightning transfer itself is no longer pending. The remaining delay may be the receiver's wallet sync, custodial accounting, swap operation or merchant order state. Give the receiving service the payment hash, amount, time and any settlement proof rather than asking the sender to make another payment.

Some wallets hide another payment rail behind a Lightning-looking flow

A receiving app may accept Lightning and then perform an internal swap or credit into another network or account. In that design, Lightning can succeed while the final user balance remains pending for a separate reason. Recent user reports involving wallets that convert incoming Lightning into another asset or network illustrate why the receiving product's architecture matters. Verify what the destination actually receives before treating its final balance as direct Lightning settlement evidence.

Custodial services can use pending differently from self-hosted nodes

A self-hosted node can expose protocol states directly. A custodial platform may combine account review, invoice handling, backend queues and Lightning execution behind one word. Coinbase, for example, currently warns that sends to some self-custody wallets may take hours or fail, and also documents a special case where a Lightning address entered where an invoice is expected can appear pending because the platform treats it differently. Provider-specific labels therefore need provider-specific interpretation.

Coinbase also shows why a pending invoice can be misleading

Coinbase currently states that its generated Lightning invoices remain pending in transaction history for up to 72 hours or until the sender completes the transaction. That is an incoming invoice state, not proof that an outgoing HTLC is stuck for 72 hours. Do not copy a platform's invoice-history window and present it as a universal Lightning timeout.

For an LND node, track the payment instead of reading logs blindly

LND's TrackPaymentV2 reports INITIATED, IN_FLIGHT, SUCCEEDED or FAILED and provides HTLC-attempt information. Use the payment hash to watch the existing payment reach a final state. The key question is not whether a log line looks alarming; it is whether the tracked payment still has in-flight HTLCs or has already transitioned to a final result.

For Core Lightning, query the payment record

Core Lightning's listpays can filter by BOLT11 invoice, payment hash or status and reports pending, complete or failed. Its sendpay documentation explicitly tells users with a pending result to monitor the status rather than treat the initial response as final. Current releases also expose HTLC state and expiry data for deeper node-level investigation.

Multi-part payments can make 'one payment' contain several attempts

A wallet can split one Lightning payment across multiple routes. The user sees one payment, while the node may track several HTLC parts. Do not infer failure because one route part failed if the overall payment is still trying other parts. Conversely, do not treat one successful-looking route message as settlement until the overall payment reaches a final successful state.

Contact the sender first when the sender's app is the only place showing pending

If the recipient has no settled invoice and you do not control the sending node, the sending provider has the best evidence about whether a payment attempt exists. Give support the Lightning invoice or payment hash if available, internal transaction ID, amount, exact timestamp, recipient wallet and screenshots of the status. Ask whether the Lightning attempt is not started, in flight, succeeded or failed—not merely whether the account transaction is 'still pending.'

Contact the recipient first when you have settlement proof

If the sender can prove SUCCEEDED or complete, asking the sender to retry is the wrong escalation. Give the recipient the payment hash and settlement evidence and ask them to trace the invoice or credit. For a merchant, include the order ID because the payment system and order database may have diverged.

Never resolve uncertainty by paying the same invoice twice

The risk-control rule is simple: while an existing payment is genuinely in flight, do not create a second independent payment just to see whether it works. Wait for a final state or obtain confirmation from the sending provider that no Lightning attempt exists. A second payment is appropriate only after the first attempt is definitively failed or absent and the recipient supplies a still-valid or new invoice.

A practical evidence record takes less than two minutes

Capture enough information before statuses change.

• Sending wallet or service and whether it is custodial or self-hosted
• Amount in sats and approximate fiat value
• BOLT11 invoice or payment hash if safe and available
• Time the payment was initiated
• Exact sender status and any Lightning-specific substatus
• Recipient invoice state: open, settled, canceled or expired
• Payment result from LND/Core Lightning if you control the node
• Any preimage or successful-settlement proof
• Whether the destination performs an additional swap or custodial credit

Use this decision sequence

Follow one branch at a time.

• 1. Confirm that the request was Lightning, not an on-chain Bitcoin address.
• 2. Ask whether the sending service can prove a Lightning attempt exists.
• 3. If no attempt exists, keep the issue with the sender's app or platform queue.
• 4. If the payment is IN_FLIGHT or pending at the node, do not duplicate it; monitor until final resolution.
• 5. If FAILED, confirm the recipient did not settle and then obtain a valid invoice before retrying.
• 6. If SUCCEEDED or complete, stop troubleshooting routing and move to recipient credit or merchant reconciliation.
• 7. If you cannot access node-level state, escalate to whichever provider controls that state and request a final Lightning-specific result.

What this page deliberately does not diagnose

A pending Lightning payment is not the same as an exchange withdrawal waiting to be broadcast, an on-chain Bitcoin transaction stuck in the mempool, a permanent no-route error, an expired invoice with no active payment, or a completed Lightning payment missing from the recipient balance. Keeping those states separate prevents generic advice such as 'raise the miner fee' or 'just generate another invoice' from creating a second problem.

What can change after August 7, 2026

Wallets and exchanges can change their status labels, retry behavior, invoice validity windows and support procedures. LND and Core Lightning can also evolve their APIs. The durable rule is to establish four facts in order: whether the platform started a Lightning attempt, whether that attempt is still unresolved, whether settlement proof exists, and whether the recipient credited the result.

Sources checked on August 7, 2026

Protocol and node behavior were checked primarily against Lightning Labs and Core Lightning documentation; provider-specific examples were checked against current support pages.

• Lightning Labs — Sending Payments and stuck HTLC behavior — https://docs.lightning.engineering/lightning-network-tools/lnd/payments
• Lightning Labs — TrackPaymentV2 payment and HTLC states — https://lightning.engineering/api-docs/api/lnd/router/track-payment-v2/
• Lightning Labs — Lightning payment cycle — https://docs.lightning.engineering/the-lightning-network/multihop-payments/the-payment-cycle
• Lightning Labs — Lightning invoice lifecycle and expiry — https://docs.lightning.engineering/the-lightning-network/payment-lifecycle
• Core Lightning — listpays — https://docs.corelightning.org/reference/listpays
• Core Lightning — sendpay — https://docs.corelightning.org/reference/sendpay
• Coinbase Help — Bitcoin Lightning — https://help.coinbase.com/en/coinbase/trading-and-funding/sending-or-receiving-cryptocurrency/lightning
• Kraken Support — sending Bitcoin on Lightning — https://support.kraken.com/articles/5068216131988-how-do-i-send-bitcoin-on-the-lightning-network-

FAQ