Lightning invoice and Lightning address – how payments work
When someone first encounters Lightning Network, one of the first things that confuses them is that payments here do not work the way they do with classic Bitcoin. With Bitcoin you send money to an address. A simple, understandable principle that anyone who has ever made a bank transfer knows. With Lightning Network it is different. You encounter terms like invoice, Lightning address, or LNURL, and if nobody explains what these terms mean and why they exist, it is easy to get lost.
This article will explain exactly that. We will look at what a Lightning invoice is, why it works differently from a Bitcoin address, what it contains, and why it expires. Then we will look at the Lightning address, what is behind it, how to get one, and how it differs from an invoice. Finally we will discuss LNURL, a technology that most users do not even know they are using, even though it is the foundation of most modern Lightning payments. Understanding these three concepts will give you a complete picture of how payments on Lightning Network actually work.
Why Lightning does not use classic addresses
To understand why a Lightning invoice exists and why it is designed the way it is, we first need to look at how a classic Bitcoin address works and why this model does not work for Lightning.
A Bitcoin address is static. You create it once and can share it with anyone. Anyone can send you bitcoin at that address at any time, without you knowing in advance, without you being online, without you confirming anything. The entire process is asynchronous: the sender submits a transaction to the blockchain, the transaction waits for confirmation in a block, and after a few minutes it is final. You find out about the payment when you look at your wallet.
Lightning Network operates on a completely different principle. Payments here do not travel through the blockchain but through a network of payment channels in real time. It is an active, synchronous process: the sender and recipient must both be online, the network must find a path between them through available channels with sufficient liquidity, and the entire payment completes in seconds, or not at all. If the recipient is not online, the payment simply does not go through.
This difference has a fundamental impact on how payments work. A static address to which anyone can send any amount at any time is problematic in the Lightning technical model. The recipient must actively expect the payment, must know the exact amount, and the network must know where to route the payment. That is why the invoice was created: an active payment request that contains all of this information and has a time limit corresponding to how long the recipient is ready to receive the payment.
What is a Lightning invoice
A Lightning invoice is a one-time payment request. Each invoice is unique, valid only once, intended for a specific amount, and has a time limit. After being paid or after its validity expires, it ceases to exist.
Visually an invoice looks like a long string of characters starting with the letters lnbc, for example lnbc500n1p3qhlfapp5... and so on for several lines. This string is an encoded version of all the information the recipient needs to process the payment. You usually do not see it in raw form: wallets display it as a QR code that you simply scan. But if you need to share an invoice as text, for example via a message, this is what it looks like.
An invoice can either have a fixed amount or no amount. A fixed-amount invoice is more common: the recipient specifies in advance how much they want to receive, and the sender cannot send a different amount. An invoice without an amount, sometimes called a zero-amount invoice, leaves the amount up to the sender. It is used for example for tipping, where the sender decides how much to send.
What exactly a Lightning invoice contains
When a wallet decodes an invoice, it sees several key pieces of information. The first is the payment amount: either a specific value in satoshis, which is the smallest unit of bitcoin, or an empty field for an invoice without an amount. The second is the recipient identification: not their name, but a cryptographic key that uniquely identifies their Lightning node in the network. This is what allows the network to find a route to the recipient through payment channels.
The third important piece of information is the payment hash. It is a cryptographic fingerprint of a secret number that only the recipient knows. When the payment arrives, the recipient reveals this secret number, proving they received the payment, and the funds are released. This mechanism ensures that nodes along the route cannot steal the payment: money only moves when the secret number is revealed, and that happens only when the payment actually reaches the recipient. If the payment does not go through, the secret number is not revealed and the funds are automatically returned to the sender.
The fourth piece of information is the expiry time. Every invoice has a set time after which it is no longer valid. The standard is 3600 seconds, that is one hour, but the recipient can set a different time. Some systems generate invoices valid for only a few minutes, others valid for several days. After this time passes the invoice expires and payment through it is not possible.
The fifth piece of information consists of optional descriptions and notes. An invoice can contain a text description of the payment, for example Coffee at Café XY or Monthly subscription. This description is visible to the sender in their wallet before confirming the payment and can be viewed later in the transaction history. It is just informational text and has no effect on the technical processing of the payment.
Why an invoice expires and what to do when it happens
Invoice expiration is one of the things that surprises beginners. We are used to addresses being permanent, and when an invoice suddenly stops working after an hour or two, it feels like an error. In reality it is an intentional design with a good reason.
When the recipient generates an invoice, their wallet reserves resources and waits for an incoming payment. If the invoice did not expire, the wallet would have to wait indefinitely for a payment that might never come. Moreover, the payment hash in the invoice is one-time: once used it cannot be used again. If someone tried to use the same invoice twice, the second payment would be rejected. Expiration thus cleans up the system state and prevents the accumulation of unused pending payments.
What to do when an invoice expires? The solution is simple: ask the recipient for a new invoice. Nothing was lost, no money disappeared, the payment request simply expired. If you are shopping and the invoice expired, tell the merchant to generate a new QR code. If you are sending a payment to a friend and their invoice expired, message them to send you a new one. It is as natural as the situation where someone sends you a link to fill out a form and the link expires in the meantime.
Limitations of invoices and why they are not enough for all situations
An invoice works excellently in situations where the recipient is actively generating payment requests: in a shop, when paying for a specific service, when sending money to someone who will generate an invoice for you on request. But there are situations where an invoice is impractical or insufficient.
Imagine you want to publish a contact where people can send you payments at any time, without having to write to you and ask for an invoice. For example on your website, on social media, or on a business card. That is not possible with a classic invoice: an invoice is one-time, expires, and must be generated for each payment separately. A Bitcoin address would work here, but a Lightning invoice would not.
Another situation is tipping or a voluntary payment. If someone spontaneously wants to send a few satoshis to their favorite podcaster or open-source developer, they cannot wait for the author to generate an invoice. They need a way to send a payment without prior interaction with the recipient.
Two solutions were created for exactly these situations: Lightning address and LNURL. Both solve the same problem in different ways, and both are worth understanding.
LNURL – the technology behind modern payments
LNURL is a protocol that most regular Lightning Network users have never heard of, even though almost everyone uses it every day. It is a technical layer that allows wallets to automatically communicate with each other and perform actions that would otherwise require manual steps from the user.
The basic idea of LNURL is simple. Instead of the recipient sending you a static invoice, they send you the address of the server where their wallet or service runs. When your wallet visits this address, the server automatically generates a fresh invoice specifically for you at that moment. Your wallet receives the invoice, you confirm it, and the payment goes through. This entire process happens in the background in a fraction of a second, and all you see is that you scanned a QR code and paid.
LNURL thus solves the problem of invoice staticness in an elegant way: instead of sharing the invoice itself, you share a link to a place where an invoice is always freshly generated. A QR code can remain the same for months and years because it does not contain an invoice but only a server address. Everyone who scans it receives a new unique invoice generated specifically for them.
There are several variants of LNURL for different uses. LNURL-pay is used for receiving payments: the recipient has a QR code that can be printed on a poster, published on the web, or shared anywhere, and anyone who scans it can send a payment. LNURL-withdraw works in the opposite direction: it allows you to withdraw funds from a service directly into your wallet by scanning a QR code. LNURL-auth is another variant that allows logging into services using a Lightning wallet without a password, but that is a separate topic.
Lightning address – LNURL in human-readable form
A Lightning address is a layer on top of LNURL-pay that simplifies the entire technical process even further and makes it human-readable. While an LNURL-pay QR code contains a long encoded string, a Lightning address looks like something you know from everyday life: name@domain.com.
Technically a Lightning address works like this: when someone wants to send a payment to an address like jan@getalby.com, their wallet contacts the server at the getalby.com domain and asks it to generate an invoice for user jan. The server responds with a fresh invoice, the wallet presents it to the sender for confirmation, and the payment goes through. This entire process is automatic and happens in a fraction of a second. From the sender's perspective, they simply enter the Lightning address, the amount, and click send.
The advantages of a Lightning address over a classic invoice are obvious. It is permanent: you can share it once and payments can come in at any time. It is human-readable: easy to remember and easy to share. It is reusable: anyone can send you a payment, even multiple times, without you having to generate a new invoice. And it is compatible: most modern Lightning wallets support Lightning addresses.
However, a Lightning address also has limitations that are important to know. It only works when the server managing it is online and available. If the server goes down or if you stop using the wallet, the Lightning address stops working. This is a fundamental difference from a Bitcoin address, which exists independently of any server. Moreover, the server managing your Lightning address sees metadata about incoming payments: when they arrived, for how much, though not necessarily from whom. For most users this is not a problem, but it is good to be aware of it.
Where to get a Lightning address
Lightning addresses are provided by various services and wallets. Some wallets create a Lightning address for you automatically upon registration, others require you to create one manually or register an account with an external service.
Phoenix wallet does not currently provide Lightning addresses directly, but you can connect it to external services. Breez has integration with some Lightning address services. Wallet of Satoshi automatically assigns every user a Lightning address in the format name@walletofsatoshi.com.
If you want a Lightning address independent of a specific wallet, there are dedicated services. Getalby.com is one of the most popular: you register, create an address in the format name@getalby.com, and payments arriving at that address can be forwarded to any wallet. Stacker.news, lnaddr.com, and other services work similarly. The advantage of an externally managed Lightning address is that you can change wallets and the address remains the same.
For those who want maximum control and independence from third parties, there is the option of running your own server that manages the Lightning address. This requires technical knowledge and your own Lightning node, however, which is beyond the scope of a regular user.
Comparison: invoice vs Lightning address vs LNURL
Now that you understand all three concepts, it is useful to compare them and know when to use which.
An invoice is suitable for one-time payments with a specific amount where the recipient is actively waiting for a payment. Typical uses include paying in a shop, invoicing for a service, or sending money to a specific person on request. An invoice is one-time, expires, and must be generated by the recipient just before the payment.
A Lightning address is suitable for repeatedly receiving payments, sharing a payment contact, and situations where you want a permanent identifier similar to an email address. It works well on websites, social media, and business cards. It is permanent, human-readable, and does not require manually generating an invoice before each payment. It does depend on server availability, however.
An LNURL-pay QR code is suitable for physical locations or online platforms where you want a static QR code for receiving payments without needing a Lightning address. The advantage over a Lightning address is that you do not need a domain or email address, just a QR code. The disadvantage is that it is not human-readable and cannot be shared as text.
Practical tips when working with invoices and Lightning addresses
When using Lightning invoices in everyday life, a few practical rules apply. When you receive an invoice to pay, check the amount and recipient before confirming. Most wallets display this information clearly. If you see an invoice without an amount, that is a zero-amount invoice, and you determine how much to send. Make sure you understand how much you want to send and enter the amount in the wallet.
Never send bitcoin to a Lightning invoice from a classic on-chain Bitcoin wallet. These two networks are incompatible. If you have an invoice starting with lnbc, you must pay it from a Lightning wallet. If you have a Bitcoin address starting with bc1, you pay from an on-chain wallet. Mixing these two can lead to loss of funds.
When you generate your own invoice to receive a payment, do so just before you need the payment. It is not worth generating an invoice an hour in advance and leaving it to wait: it may expire. Modern wallets can generate an invoice in seconds, there is no reason to do it too far in advance.
With a Lightning address, pay attention to where it is registered. If you use a Lightning address from a custodial wallet like Wallet of Satoshi, payments first arrive on their server and are then made available to you. If privacy or control is important to you, consider using a Lightning address from a non-custodial solution or your own server.
Summary
A Lightning invoice is a one-time payment request with a specific amount, recipient identification, and a time limit. It replaces the static Bitcoin address in situations where an active payment is taking place in real time. It expires to match the technical reality of the Lightning network, and if it expires you just generate a new one.
LNURL is a protocol that enables automatic invoice generation in the background, solving the problem of invoice staticness and one-time use. Most modern Lightning interactions use it without the user even realizing it.
A Lightning address is a layer on top of LNURL that wraps the entire process in a human-readable format similar to an email address. It is permanent, shareable, and does not require manually generating an invoice. It does depend on server availability, however, which is its main limitation compared to an on-chain Bitcoin address.
In the next article [How to send a Lightning payment step by step] we will go through the entire process of a first real payment from start to finish. We will take a specific wallet, show what each step looks like, and address all the situations you might encounter when paying for the first time.
Frequently asked questions
Why did my invoice expire sooner than I expected?
Different wallets and services set different invoice expiration times. Some set the standard 60 minutes, others only 10 minutes, and some online stores generate invoices valid for only a few minutes for security reasons. Always make sure to pay as soon as possible after receiving an invoice. If an invoice expires, simply ask for a new one.
Can I use the same invoice for multiple payments?
No. Every invoice is one-time and can only be paid once. After being paid it ceases to be valid. If you need to receive two payments, you must generate two different invoices. The exception is when you use a Lightning address or LNURL-pay QR code: these can be used repeatedly because each use automatically generates a new one-time invoice in the background.
What happens if I accidentally pay an invoice twice?
The second payment will be automatically rejected. An invoice loses its validity after the first payment and the network will not accept another payment through the same invoice. Your funds will be returned. This is one of the security features of Lightning Network that protects against duplicate payments.
Is a Lightning address the same as an email address?
Visually yes, but technically they are completely different things. A Lightning address uses the same name@domain.com format just to make it understandable and memorable for people. In reality it is an address of a Lightning server running scripts that generate invoices. A Lightning address cannot be used for emails and vice versa.
Can I have multiple Lightning addresses?
Yes. You can register a Lightning address with multiple services and use them in parallel. For example you can have jan@getalby.com for regular payments and jan@walletofsatoshi.com for other purposes. Payments to each address arrive at the corresponding wallet or service.
How do I know if a Lightning address I received is real?
Modern wallets automatically verify a Lightning address before allowing you to send a payment. If the address does not exist or the server does not respond, the wallet will display an error. A bigger problem is if someone sends you a correct address but is pretending to be someone else. Always verify a Lightning address directly with the recipient through a trusted communication channel, not just through a message from an unknown person.