Lightning Network invoices are built to make payments easier to pass between parties and easier for nodes to process. According to the source material, once an invoice is created, it is stored on a node, which manages and stores a Lightning Network invoice database. Its main job is simple: carry the information needed for a payment between two parties.
The Lightning Network itself is described as a second-layer payment protocol that runs on top of the Bitcoin, Litecoin, and Monero blockchains. It was created to address scalability and supports fast transactions between participating nodes through a peer-to-peer system of bidirectional payment channels. That setup is also meant for micropayments, while keeping funds out of third-party custody. Fees are lower than on-chain operations. That is one of the practical reasons invoices matter.
Two parts: a readable prefix and a data section
The source breaks a Lightning Network invoice into two main sections: the human-readable part and the data part. In the example provided, the invoice begins with “lnt”, which refers to the Bitcoin Test Network. The next element, “1u”, represents the amount being sent in token units. The number 1 separates the two sections, and everything after that contains the transaction-specific details.
Those details can include when the invoice was created, the node ID that will receive the payment, the expiration time, a description, a backup bitcoin address, a route for payment, and other relevant data such as a transaction signature. One notable distinction in the source is that Lightning Network invoices expire, unlike standard Bitcoin invoices. To start using invoice payments on Lightning, the article points to the Lightning Network Daemon, which includes the invoice protocol.
What an invoice must include to be valid
The material lists six required fields for validity: Destination, Payment_hash, Num_satoshis, Expiry, Timestamp, and Cltv_expiry. Destination is the public key of the payment recipient. Payment_hash is the hash of the preimage used to lock the payment. Num_satoshis is the amount to be paid in satoshis. Expiry marks when a node treats the invoice as invalid. Timestamp records when the invoice was created, and Cltv_expiry is the delta used for the final-hop time-lock.
These fields are the minimum needed for a valid invoice, but the source notes that many more details may be added. A description can help explain the payment, and a fallback address can serve as a safety feature. If a Lightning transaction fails, that fallback allows payment to be issued on-chain directly to the Bitcoin blockchain.
Functions aimed at merchants and applications
The business section highlights several invoice features beyond basic payment collection. Fall Back Address Function lets a BTC address act as a fail-safe. Description adds a memo line so merchants can track where a payment came from and why it was made. Description Hash stores payment-related information with the receipt; after a QR code payment, the wallet keeps that hash, and a small business can upload an itemized receipt to a website for later lookup using the same reference.
The source also mentions AddIndex, which assigns a sequence number to all invoices so their status can be tracked. It is described as a good fit for subscription flows, because it can keep track of invoices that have not been paid. Users can also send invoices through a QR code. Put together, these functions show that Lightning invoices can be used not just for one-off transfers, but also for tracking, receipt management, and recurring billing support.
The article’s overall picture is that Lightning Network invoices are flexible and can carry much richer payment data than a simple address request. At the same time, the source says they remain somewhat difficult for the average user to handle. That leaves them more practical, for now, for users and businesses already familiar with Lightning’s payment flow and invoice mechanics.