Payment request formats
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.
On-chain addresses #
Addresses are used for transactions on the base layer. More details on the address page in the Glossary.
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.
This draft specification has similarities with to LNURL-Pay and LNURL-Withdraw, but uses the Lightning network itself as the communication channel.
Lightning AMP invoices (Atomic Multi-Path) #
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.
Lightning node IDs #
Senders can initiate payments to recipients only knowing their node ID, using Keysend and AMP invoices.
This internet-based protocol establishes techniques on top of Lightning invoices for several important use cases, including the following:
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).
Allows for invoices to offer withdrawals with optional minimum and maximum amounts.
This identifier builds on top of LNURL-Pay and introduces the familiar format of email addresses as identifiers.
Each request format has its own unique approach to bundle payment information for transmission. Unique are Lightning addresses, which are easily readable and memorizable by users.
Lightning invoice (BOLT 11)
Offer (BOLT 12)
Lightning AMP invoice
Lightning node ID
Sending is one side of the process. Let’s look at things from the receiver’s perspective.