A shop sends you a replacement Lightning invoice because the first request has expired. Before scanning it, check what happened to the first payment. The invoice deadline tells your wallet when to stop attempting that request; the payment record is what you need to resolve whether the merchant has already been paid.
| What you need to know |
|---|
| BOLT 11 invoices contain a timestamp and an expiry interval. |
| The payment hash identifies an invoice in LND's single-invoice lookup. |
| LND tracks invoice creation and settlement separately. |
| An LND invoice memo does not have to be unique. |
This distinction applies to conventional BOLT 11 invoices, rather than every way of receiving Lightning payments. Lightning Labs documents invoice-based payments separately from experimental Keysend payments. A wallet’s labels and available transaction details can differ, so look for its payment history rather than treating the old checkout screen as a receipt.
Two records answer two different questions
The BOLT 11 specification defines the deadline as the invoice timestamp plus its expiry interval. After that point, a payer should not attempt payment. This is a rule about initiating a payment, not a historical statement that no payment succeeded before the deadline.
That timing rule and the merchant’s settlement record answer different questions. Lightning Labs’ LND receiving documentation describes an add index for newly created invoices and a separate settle index for settled invoices. Comparing the two documents shows why a countdown reaching zero cannot, by itself, resolve the earlier payment attempt.
Start with the first payment in your wallet. If it reports success, keep its details and ask the merchant to reconcile that invoice before you send another payment. If its outcome is still unclear, seek confirmation from the wallet provider or merchant. These are reconciliation steps: a fresh QR code supplies a new request, not evidence about the previous attempt.
Match the invoice, not just its description
LND can look up an individual invoice using its payment hash. Its memo, by contrast, is a description that does not have to be unique. Two requests displaying the same order description therefore need not identify the same invoice. Ask the merchant to compare the specific invoice or payment identifier in the available records, rather than matching only the shop name, amount or memo.
The specification also explains that a payer can prove a successful payment in a later dispute using the signed offer and proof of payment. Keep the original invoice and whatever payment proof your wallet provides. Share only the information needed for reconciliation through the merchant’s verified support channel; a recovery phrase or wallet private key has no place in an invoice dispute.
Once the merchant and wallet records establish that the original request remains unpaid, use the merchant’s current invoice and check its amount before confirming. If the first payment succeeded, resolve the order against that payment instead of paying the replacement merely because its timer is still running.
