A payment request with machine-readable fields
BOLT 11 defines a compact invoice format used by Lightning wallets. It can carry information needed to attempt a payment, including the payment hash, optional amount, description-related data, expiry, and routing information. The invoice's signature helps bind the request to its signing identity. A wallet parses these fields rather than treating the invoice as an arbitrary text message or a conventional on-chain receiving address.
1 source for this section
An example at checkout
A merchant generates an invoice for a particular payment, and the customer's wallet displays the amount and relevant details before attempting a route. The payment hash connects the request to Lightning's conditional payment mechanism. If the invoice has expired or no usable route exists, scanning the QR code alone does not complete the transaction. An amountless invoice also requires the sender to choose an amount, which changes what the interface must explain.
2 sources for this section
Invoices, offers, and receipts
An invoice is a request, not proof that it was paid. Applications need to track the actual payment result and avoid assuming repeated attempts are harmless in every surrounding business workflow. BOLT 12 offers introduce a different reusable request-and-invoice model; their presence does not make older invoice formats identical. When documenting support, identify which format the wallet handles, what recipient information it exposes, and whether a merchant's confirmation reflects successful settlement or only creation of an invoice.
2 sources for this section
The source notesEvidence & further reading3 sources
- BOLT 11: Invoice encoding Lightning specification contributors · Primary source · accessed 2026-09-21
- BOLT 4: Onion routing Lightning specification contributors · Primary source · accessed 2026-09-21
- BOLT 12: Offers Lightning specification contributors · Primary source · accessed 2026-09-21