Payment information can be shared in many formats and over diverse communication channels. Each has its advantages and limitations, these formats seen together allow for broad flexibility in initiating payments. Some of them are still maturing and have varying support across applications.
Lightning invoices are the basic payment mechanism on the Lightning network. They are usually set to expire after 1 hour and should only be paid once for best security and privacy. Invoices must be created by the recipient and shared with the sender, who then makes the payment.
Lightning invoices are not addresses
It could be tempting to refer to a Lightning invoice as a “lightning address.” Doing so could be confused with the lightning address protocol described below. Therefore, avoid calling an invoice an address. A “payment request” would be a better synonym for “invoice.”
This type of invoice allows for small payments to be broken up, potentially increasing the likelihood of success for larger amounts. Invoices typically expire after one day but can also be configured to be static and be paid multiple times. Unlike BOLT 11 invoices, AMP invoices can also be initiated by the sender without action by the recipient.
This internet-based protocol establishes techniques on top of Lightning invoices for several important use cases, including the following:
LNURL-Pay
Makes it possible to generate Lightning invoices on-demand, based on a static identifier (in contrast with regular Lightning invoices, which expire and should only be paid once).
LNURL-Withdraw
Allows for invoices to offer withdrawals with optional minimum and maximum amounts.
Each request format has its own unique approach to bundling payment information for transmission. Unique are Lightning addresses, which are easily readable and memorizable by users.