# Lightning invoices: amount, expiry and payment status

A Lightning invoice is a payment request that a compatible wallet can decode and pay. The BOLT 11 format includes a network, payment hash, creation time, signature and other fields; the amount can be unspecified. Expiry limits when a new attempt should begin. An invoice is not proof that money arrived, and its signature does not by itself establish a merchant’s real-world identity.

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)

Canonical: https://degreesofsatoshi.com/encyclopedia/lightning-invoices/
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

- **Amount:** May be fixed or unspecified ([BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md))
- **Expiry:** Measured from the invoice creation time ([BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md))
- **Payment evidence:** Requires more than displaying the request ([BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md))

## Check the wallet’s decoded request

The invoice’s encoded units and prefixes are for software to parse. Use the wallet’s readable amount and network display instead of guessing from the string. An amountless invoice asks the payer to choose an amount; it does not mean that the payment must be zero.

A description can explain what is being paid for, but treat it as supplied content. Match the request to the intended recipient through the channel you already trust.

Evidence: [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md)

## An expiry is a deadline for starting payment

Imagine an invoice created at 12:00 UTC with an explicit expiry of 900 seconds. Its new-payment window ends at 12:15 UTC. BOLT 11 specifies a one-hour default when its expiry field is absent; wallets may include their own explicit value.

An attempt already in progress can remain unresolved beyond an interface timer. Inspect its final status before requesting or paying a replacement, so a delayed success does not become an unintended second payment.

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)

## Request a fresh invoice for a separate purchase

Ordinary BOLT 11 invoices are not a general reusable donation address. BOLT 12 identifies invoice reuse and repeated attempts as limitations addressed by an offer-and-invoice-request flow. Use the recipient’s supported reusable mechanism when that is what you need.

A signed invoice plus its matching payment preimage can provide evidence that the invoice was paid. That evidence alone does not prove which person paid it; the recipient also knows the preimage.

Evidence: [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

### Can a Lightning invoice leave the amount open?

Yes. BOLT 11 permits the amount to be omitted, and the wallet should tell the payer that it is unspecified. Confirm the chosen amount before authorizing payment.

Evidence: [BOLT 11: Invoice Protocol for Lightning Payments](https://raw.githubusercontent.com/lightning/bolts/1aadb719b4007c4cea0ba6e36b08c4fb53788dee/11-payment-encoding.md)

### Does an expired invoice mean a pending payment definitely failed?

No. Invoice expiry and the final state of an already dispatched payment are separate. Check the wallet’s recorded payment status before paying again.

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)

## Claims and scope

### lightning-invoices-quick-answer

A Lightning invoice is a payment request that a compatible wallet can decode and pay. The BOLT 11 format includes a network, payment hash, creation time, signature and other fields; the amount can be unspecified. Expiry limits when a new attempt should begin. An invoice is not proof that money arrived, and its signature does not by itself establish a merchant’s real-world identity.

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-invoices-fact-amount

Amount: May be fixed or unspecified

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

### lightning-invoices-fact-expiry

Expiry: Measured from the invoice creation time

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

### lightning-invoices-fact-payment-evidence

Payment evidence: Requires more than displaying the request

Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [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.
- [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 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 invoices: amount, expiry and payment status.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/lightning-invoices/
