An invoice-request workflow
LNURL-pay, specified in LUD-06, lets a wallet contact a service, learn payment parameters, and request an invoice for a chosen amount. It helps create reusable payment entry points instead of requiring the recipient to distribute a new fixed invoice manually for every payment. The resulting payment still relies on Lightning invoice and routing mechanics. LNURL-pay is not itself a new settlement network or an asset separate from bitcoin.
2 sources for this section
What the wallet needs to verify
A typical interaction includes supported amount bounds, a callback endpoint, metadata, and an invoice returned for the selected amount. The specification defines checks connecting the invoice to the requested payment and metadata. For example, a wallet should not treat an invoice for a different amount as interchangeable merely because it came from the expected web page. The HTTPS service and its availability become part of the user experience before the Lightning payment is attempted.
1 source for this section
Usability and trust boundaries
A reusable address-like payment flow is convenient, but the service can learn request metadata and can become unavailable or change its responses. Wallets must still handle invoice expiry, failed routes, and user confirmation. The protocol does not prove that a merchant will deliver goods or that a displayed recipient name identifies the intended legal person. Distinguish the web-based request stage, the cryptographic invoice, and successful Lightning settlement when explaining what a completed payment screen actually confirms.
2 sources for this section
The source notesEvidence & further reading2 sources
- LUD-06: LNURL-pay LNURL contributors · Primary source · accessed 2026-09-21
- BOLT 11: Invoice encoding Lightning specification contributors · Primary source · accessed 2026-09-21