Lightning Invoice Expired? Do Not Pay a New One Until You Check the Old Attempt

If a Lightning invoice has expired and you never tried to pay it, the fix is simple: ask the recipient or checkout page for a fresh invoice. If you already pressed Send, however, do not assume that the expiry message makes a second payment safe. First determine whether the old attempt failed, is still unresolved or already succeeded. Invoice expiry and payment settlement are related, but they are not the same state.

The safe answer depends on whether you already tried to pay

There are two fundamentally different situations. If the invoice expired before any Lightning payment attempt existed, replace it. If a payment attempt existed, establish its final state before paying anything else. This single distinction prevents the most expensive mistake in expired-invoice troubleshooting: paying a second invoice while the first attempt is still capable of settling.

Use the Expiry Recovery Gate

Move through these four gates in order.

• Gate 1 — Expiry proof: is the BOLT11 invoice actually past its encoded expiry time?
• Gate 2 — Attempt proof: did the sender create a Lightning payment attempt before or around expiry?
• Gate 3 — Final result: is that attempt failed, unresolved or successful?
• Gate 4 — Recipient settlement: does the recipient or merchant show the old invoice as paid, unpaid or expired?

Verdict A: expired and never attempted

This is the clean case. Stop using the old BOLT11 string and request a new invoice from the recipient. Coins.ph and current consumer payment guidance from Crypto.com both instruct users who encounter an expired Lightning invoice to obtain a fresh invoice. A new invoice should come from the recipient or the original checkout flow, not from editing the old string.

Do not edit the expiry field yourself

A BOLT11 invoice is signed by the payee. Its timestamp, amount, payment hash, expiry and other fields are covered by the invoice signature. Changing encoded characters to extend the lifetime invalidates the payment request. The recipient must generate a new signed invoice.

BOLT11 expiry is part of the invoice itself

The current BOLT11 specification defines an optional x field containing the invoice lifetime in seconds. If that field is absent, the protocol default is 3600 seconds, or one hour. The invoice creation timestamp plus its expiry gives the point after which the payee should no longer accept a new payment to that invoice.

One hour is not a universal wallet lifetime

Do not assume every Lightning invoice lasts exactly one hour. The BOLT11 format has a one-hour fallback when no explicit expiry is encoded, but implementations commonly choose their own explicit value. Current LND documentation says invoices it creates default to 86400 seconds, or 24 hours, while Core Lightning's invoice command currently defaults to 604800 seconds, or one week. Merchant checkouts can choose much shorter windows.

Decode the invoice instead of guessing from when you received it

If your wallet does not show the expiry clearly, decode the BOLT11 invoice locally. Core Lightning's current decode command returns created_at and expiry for a BOLT11 invoice. LND users can inspect a payment request with their node tooling as well. The relevant calculation is creation time plus the encoded lifetime, not the time the QR code happened to reach your phone.

Invoice expiry is not the same as CLTV expiry

These two uses of the word expiry are easy to confuse. BOLT11 invoice expiry is a wall-clock validity period for the payment request. CLTV expiry is a block-height timelock used by HTLCs while a Lightning payment is routed. Extending or replacing an invoice does not mean manually changing an HTLC timelock, and an expired invoice message is not an on-chain Bitcoin confirmation problem.

Verdict B: you clicked Send, but the wallet says the payment failed

A final failed result normally means the old attempt did not settle. Confirm that the recipient also has not marked the invoice paid, then request a new valid invoice and retry only after understanding the failure. Core Lightning's current renepay documentation includes a dedicated Invoice expired error when payment took too long or the invoice was already expired when payment began.

A fresh invoice does not fix a routing problem

If the old payment failed because the invoice expired after a long routing attempt, a fresh invoice may provide enough time for another attempt. If the actual cause is no route, insufficient liquidity, a disconnected destination or an amount that cannot be routed, replacing the invoice alone may reproduce the failure. Read the final payment error before retrying.

Verdict C: the wallet deducted or reserved funds but has no final result

Do not pay a replacement invoice yet. A custodial wallet may reserve a balance while its backend is still processing, and a self-hosted node may still have an in-flight HTLC. The expiry timestamp of the invoice does not itself prove that every payment attempt created before that boundary has already resolved.

An already committed HTLC has its own resolution path

Lightning payments use HTLC timelocks. If a payment attempt became committed before the invoice expired, that attempt still has to resolve according to Lightning payment and timeout rules. The correct action is to monitor the existing payment until it reaches a final success or failure state. This is where the problem becomes a pending-payment incident rather than a simple expired-invoice incident.

Do not use a second invoice as a diagnostic test

Paying a second invoice proves only that the second payment route worked. It does not prove the first one failed. If the first attempt later settles as well, you can create a duplicate payment to the same merchant or person. Obtain a final result for the original attempt first.

Verdict D: the sender says succeeded

If the sending wallet or node has a final successful Lightning result or payment preimage, stop treating the invoice as unpaid merely because its wall-clock expiry has passed. Settlement happened. The remaining task is merchant or recipient reconciliation if their application still shows the order unpaid.

The recipient's invoice database is useful evidence

A recipient running Core Lightning can query invoices and see statuses including paid, unpaid and expired; current documentation describes expired as no longer payable. LND similarly exposes invoice state through its invoice APIs. For a merchant or self-hosted recipient, that database is stronger evidence than a screenshot of an old QR code.

If sender and recipient disagree, compare the payment hash

The BOLT11 invoice contains a payment hash that identifies the payment condition. When investigating a disputed expiry, compare the payment hash from the original invoice with the sender's payment record and the recipient's invoice record. This prevents a newly generated invoice from being confused with the original one.

Merchant checkout expired? Reload the order, not just the QR image

A checkout can expire for business reasons in addition to Lightning invoice validity. The merchant may lock a fiat price, inventory reservation, order session or exchange rate for only a short period. Refresh the merchant's official checkout and confirm the item, amount and order identifier before paying the newly generated invoice.

Compare the amount on the new invoice

Bitcoin price movement, merchant pricing or routing policy can cause a new invoice to request a different satoshi amount than the expired one. Decode or review the new invoice before authorizing payment. Do not assume that a replacement QR is byte-for-byte equivalent to the old payment request.

A new invoice should have a new payment identity

Normal invoice-generation workflows create a new payment request rather than reviving the old BOLT11 string. LND rejects duplicate invoices in its invoice database, and Core Lightning creates invoices with a payment hash derived from the payment preimage. For ordinary payments, let the recipient application generate the replacement rather than trying to recycle low-level invoice secrets.

If you are the recipient, generate a new invoice instead of extending the old one

For a normal user payment, create a fresh invoice with the intended amount and a lifetime appropriate to the expected payment flow. If users repeatedly encounter expiry before they can pay, review the checkout lifetime rather than asking them to reuse expired strings. Longer validity is a product decision, not a repair performed by the payer.

If you operate LND, the default is currently 24 hours

Current Lightning Labs API documentation states that LND's invoice expiry defaults to 86400 seconds when no custom value is specified by its invoice API or lncli addinvoice command. Set a different expiry deliberately when your application requires it, and log the resulting creation time, expiry and payment hash so support can diagnose stale invoices.

If you operate Core Lightning, the command default is currently one week

Current Core Lightning invoice documentation states a default expiry of 604800 seconds when the expiry parameter is omitted. This illustrates why application-specific defaults must not be confused with BOLT11's protocol fallback. Inspect the invoice you actually generated rather than relying on a remembered default.

For QR codes displayed for a long time, static BOLT11 is often the wrong UX

A printed, cached or bookmarked BOLT11 invoice will eventually become stale. If a use case needs a reusable payment entry point, use a workflow designed to fetch or generate a fresh invoice at payment time rather than distributing one short-lived BOLT11 forever. The exact technology depends on the wallet and service support.

Do not send on-chain BTC to solve an expired Lightning invoice unless the merchant explicitly offers that route

A Lightning invoice and a Bitcoin on-chain address are different payment requests. An expired Lightning QR does not automatically authorize an on-chain payment to some address you find elsewhere. If the merchant offers an official on-chain fallback, start that checkout route from the merchant and verify the amount and destination independently.

A simple recovery sequence

Use this order whenever an invoice expires.

• 1. Save the old BOLT11 invoice and the exact wallet message.
• 2. Decide whether you ever pressed Send or otherwise created a payment attempt.
• 3. If no attempt existed, request a fresh invoice and verify its amount before paying.
• 4. If an attempt existed, obtain its Lightning-specific final state.
• 5. If FAILED, confirm the recipient did not settle the old invoice, then request a new one.
• 6. If IN_FLIGHT or otherwise unresolved, do not pay again; monitor or escalate the existing attempt.
• 7. If SUCCEEDED, reconcile the recipient or merchant record rather than paying again.
• 8. For merchant checkout, reload the official order and verify amount, order ID and invoice.

Use four final verdicts

End with one explicit result.

• REPLACE — invoice expired and no payment attempt exists.
• RETRY AFTER FAILURE — the old attempt has a final failed state and the recipient confirms no settlement.
• WAIT FOR RESOLUTION — an old attempt is still pending or in flight.
• RECONCILE — the old attempt succeeded; the recipient or merchant record needs correction.

What this page deliberately does not solve

A permanently failed payment with no route is a routing and liquidity problem. A payment still in flight after the invoice timestamp passes is a pending-payment problem. A completed payment missing from a recipient balance is a settlement-versus-accounting problem. Keeping those branches separate prevents the expired-invoice page from becoming a generic Lightning troubleshooting article.

What can change after August 7, 2026

Wallet interfaces, merchant checkout timers and implementation defaults can change. The durable rule comes from the invoice itself and the payment state: decode the BOLT11 validity, determine whether an attempt exists, wait for a final result if necessary, and generate a fresh invoice only when the original payment can no longer settle.

Sources checked on August 7, 2026

The BOLT specification and current Lightning implementation documentation were prioritized over generic wallet advice.

• Lightning BOLTs — BOLT #11 invoice encoding and expiry rules — https://github.com/lightning/bolts/blob/master/11-payment-encoding.md
• Lightning Labs LND — AddInvoice and current expiry default — https://lightning.engineering/api-docs/api/lnd/lightning/add-invoice/
• Lightning Labs LND — LookupInvoice — https://lightning.engineering/api-docs/api/lnd/lightning/lookup-invoice/
• Core Lightning — invoice command and current default expiry — https://docs.corelightning.org/reference/invoice
• Core Lightning — decode BOLT11 invoice fields — https://docs.corelightning.org/reference/decode
• Core Lightning — listinvoices statuses — https://docs.corelightning.org/reference/listinvoices
• Core Lightning — renepay expired-invoice error — https://docs.corelightning.org/reference/renepay
• Coins.ph — expired Lightning invoice handling — https://support.coins.ph/hc/en-us/articles/38598493821977-How-do-I-use-Lightning-Invoice-on-Coins-ph

FAQ