Invoices on the Lightning Network(LN) serve an important role as they are a method of facilitating payments.  A LN invoice contains all the necessary information for a user to make a transaction.  When they are created, they are stored and updated in the invoice database of a LN node.  In this way, invoices are actually dynamic in nature.  

Here's an example of what an encoded Lightning Network invoice looks like:

Okay.  That looks pretty terrifying.  Let's see if we can make it more palatable by displaying it as a QR code.

QR Code of a Lightning Network Invoice

Much better!  Now every invoice must include the following information in order to be valid:

  • destination: The public key of the person receiving the LN payment.
  • payment_hash: The hash of the preimage that is used to lock the payment. You can only redeem a locked payment with the corresponding preimage to the payment hash. This enables routing on the Lightning Network without trusted third parties.
  • num_satoshis: The amount of satoshis to be paid.
  • expiry: Time when your node marks the invoice as invalid. Default is 1 hour or 3600 seconds.
  • timestamp: Time when the invoice was created.  This is measured in seconds since 1970.
  • cltv_expiry: Delta to use for time-lock of CLTV extended to the final hop.

An invoice can also include other information such as:

  • description: A memo line for the invoice which can contain any information as long as it is 639 bytes or less.
  • description_hash: Use this feature if the information you want to communicate is larger than 639 bytes. Hash what you want to share and leave the resulting alphanumeric string here for the person paying the invoice to verify.
  • fallback_addr: Leave a BTC address in the invoice in the event the LN payment fails.  That way the payer can resort to sending you an on-chain transaction at the "fall back" address to complete their payment.  
  • route_hints: The person creating the invoice fetches all available private channels connected to their LN node and leaves them as clues for the payer. This will increase the payer's chances of making a successful payment.

Here's what an invoice looks like once it's been decoded via the command line of lnd.  This was taken from the invoice I provided earlier.

{
    "destination": "034143d1a45cb9bcb912eab97facf4a971098385c47",
    "payment_hash": "f77779af9aab99db344dd6a5f3d366ba57c8a37b59edafbfa2457de582b76679",
    "num_satoshis": "100",
    "timestamp": "1544319954",
    "expiry": "3600",
    "description": "Sample Invoice for 100 Sats",
    "description_hash": "",
    "fallback_addr": "",
    "cltv_expiry": "144",
    "route_hints": [
    ]
}

What you see here is an invoice of 100 satoshis was generated by the Lightning Network node with the public key 034143d1a45cb9bcb912eab97facf4a971098385c47. The invoice is time stamped at 1544319954 seconds since 1970 (Dec. 9, 2018) and will expire in 1 hour. Finally, the person who generated the invoice left a short description of the invoice, which was to create a Sample Invoice for 100 Sats.

Leveraging Lightning Network Invoices

Now let's talk about about how the different features of LN invoices can be leveraged for businesses and applications.  

Fall back address

The purpose of fall back addresses is to provide a customer with a Bitcoin(BTC) address that they can make an on-chain payment to in the event their LN payment fails.  This is a great tool for businesses who are currently accepting Lightning Network payments.  Because the LN is still in beta and the network is growing, there can be a number of reasons why a LN payment may not be successful.  There may not be enough channel capacity to route a payment, the customer may unknowingly be trying to pay while the channel is still pending, or perhaps the only available routing node is hosted on a VPN and has been disconnected temporarily.  Rather than not completing the sale, the customer can make a payment to the fall back BTC address instead.

Description

The memo line to Lightning Network invoices.  Use this to annotate your invoices so you can keep track of where your payments come from and for what purpose.  If you have a B2B model, leaving descriptions are particularly helpful with accounting.

“Bob’s burgers paid $1,000 for hamburger buns on 12/18”

Description Hash

This would be a great tool for grocery stores.  After the cashier rings you up, they can create a description hash of the itemized receipt.  When you make the payment by scanning the QR code, your LN wallet stores the description hash.  The grocery store can then upload the itemized receipt to a website which you can look up at a later time by providing the description hash.

AddIndex

AddIndex is a feature that wasn’t included in the decoded invoice above but is still available to be used.  It adds a sequence number to all subsequent invoices, starting with the number 1.  Customers can then use this number as a “checkpoint” to keep track of unpaid invoices.  This method of generating invoices is well-suited for subscription or streaming services.  

For example, let’s say a customer subscribes to Netflix with monthly payments of $10 per month.  Netflix would then generate indexed invoices every month which the customer could autopay once they receive it.  The great thing about indexed invoices is that if you store them outside of your LN node and your node goes offline, it can automatically catch up with the most recent invoices and pay them once it comes back online.


Hopefully this article provides Lightning Network builders a good starting point on how invoices can be leveraged for various Lightning applications (Lapp’s) or businesses.  

Special thanks to Patrick Walters and Alex Bosworth for their comments and review.


Subscribe to our mailing list for the latest!