Lightning payments are the reason the lightning network exists: fast, cheap bitcoin payments for everyday use. You have seen how the protocol works in Lesson 4.1, how channels and routing work in Lesson 4.2, and which wallets exist in Lesson 4.3. Now you put it into practice.
This lesson walks through your first payment, receiving sats, a few real uses and how they work, moving between on-chain and Lightning, and what to do when a payment fails. The examples use Phoenix, the wallet we recommend for a first try; if you run your own node with Zeus, the steps are the same but you manage the channels yourself.
Making Your First Lightning Payment
Once your wallet is set up, a payment takes seconds. Here is the whole process, from installing to paying.
Step 1: Get a Lightning Wallet
Install a lightning wallet on your phone. For a first experience we recommend Phoenix: it manages channels for you, so you can focus on using Lightning.
Step 2: Write Down Your Recovery Words
Before you put in a single sat, write down the 12 recovery words the wallet gives you, on paper, and keep them somewhere safe and offline. They are the only way to get your money back if your phone is lost, stolen or broken: with Phoenix, the 12 words on a new phone restore your wallet and its channel. Don’t photograph them or store them in the cloud. Our lesson on storing a seed phrase explains how to keep them safe.
Step 3: Fund Your Wallet
You need bitcoin in the wallet before you can spend. Two ways:
- Send on-chain bitcoin: the wallet shows a Bitcoin address; send to it from an exchange or another wallet. Sending from an exchange for the first time? Our lesson on your first withdrawal covers the checks, including the small test payment first. Phoenix waits for 3 confirmations (about half an hour on average), then moves the funds into your Lightning channel, as long as the mining fee for that move is below the maximum you set in Settings → Channel management. If fees are higher, the funds show as “sleeping”: they are still yours, and Phoenix tries again later (Phoenix FAQ). You pay the mining fee, and 1,000 sats if the deposit creates your first channel.
- Receive a Lightning payment: create an invoice and have someone pay it. Receiving needs inbound liquidity (Lesson 4.2). Phoenix arranges it automatically, for a fee; Lesson 4.3 works through what a first Lightning deposit costs and when Phoenix would return it.
Either way, the first deposit carries a fixed cost, so a very small first deposit loses a large share to fees.
Step 4: Scan an Invoice
To pay someone, you need their lightning invoice, shown as a QR code or as text starting with lnbc. Open your wallet, tap “Send” or “Scan”, and point the camera at the code. The wallet shows the amount, the description and the fee.
Step 5: Confirm and Send
Check the details and confirm. The payment usually completes in a few seconds, and the wallet shows a confirmation with the amount and a payment preimage, your proof of payment.
No block confirmations, no waiting: the recipient sees the funds straight away.
Receiving Lightning Payments
To receive lightning payments, you create an invoice that the payer can pay.
Creating an Invoice
- Open your wallet and tap “Receive”.
- Enter an amount, or leave it blank so the payer chooses.
- Optionally add a description, such as “Freelance work: logo design”.
- The wallet creates an invoice and shows it as a QR code.
- Share the QR code, or copy the invoice text and send it to the payer.
Inbound Liquidity Requirement
As Lesson 4.2 explained, you can only receive up to your inbound liquidity, the balance on your channel partners’ side. How that affects you depends on your setup:
- Phoenix: if a payment doesn’t fit, Phoenix resizes your channel automatically and charges 1% plus the mining fee for the added room, as long as that fee is within your limit. By default Phoenix returns the payment to the sender if the fee would be more than 5,000 sats or 50% of the amount. Since 1% of 500,000 sats is already 5,000, a large payment needs a higher limit in Settings → Channel management.
- Your own node (with Zeus or another app): nothing happens automatically. A channel you funded yourself can’t receive until you have spent through it or obtained inbound liquidity in one of the ways listed in Lesson 4.2.
Lightning Addresses
Many wallets offer a lightning address, which looks like an email address (yourname@walletprovider.com). Payers type it instead of scanning an invoice, and their wallet asks your provider for a fresh invoice behind the scenes. It’s convenient for tips and regular payments. The provider’s server takes part in every payment, so it learns when you are paid.
Lightning Payment Use Cases
A few common uses, and how each one works.
Tipping and Social Media
Nostr is an open social network where your profile can include a lightning address. Tipping a post, called a “zap”, is one tap: your Nostr app fetches an invoice from the author’s lightning address, your wallet pays it, and a public receipt attached to the post shows the zap. The money goes straight to the author’s wallet; no platform takes a cut.
Micropayments
Lightning can move amounts too small for cards, such as paying a few sats per article or per request to an online service. Tiny payments are cheap in absolute terms, but fixed fees weigh heavily on them. On the open network the median routing node charges 0.5 sat per payment plus a small percentage (mempool.space, August 2026), so a route through two nodes costs about 1 sat in base fees alone. In Phoenix, each payment you send costs 0.4% + 4 sat: sending 10 sats costs about 4 sats in fees, 40% of the payment. Micropayments work best through wallets or services designed for them.
Shops and Online Checkout
A shop, online or in person, shows a lightning invoice as a QR code at checkout; the customer pays from any Lightning wallet and the shop sees the payment within seconds. Merchants can run their own payment software, such as BTCPay Server, so no company sits between them and their customers, or use a payment company that handles it for them.
History note: in 2021 El Salvador made bitcoin legal tender and launched a government wallet, Chivo, with Lightning payments. Under its 2024 agreement with the IMF, accepting bitcoin became voluntary for businesses and the government’s part in Chivo was to be “gradually unwound” (IMF, December 2024).
Paying On-Chain Merchants With Lightning (and Vice Versa)
Sometimes your money is on one layer and the person you’re paying wants the other. A submarine swap bridges the two: an exchange of on-chain bitcoin for Lightning sats, or the reverse, done so that neither side can cheat.
Who needs this? If you use Phoenix, almost nobody: Phoenix handles on-chain payments and deposits itself. Swap services matter if you run your own node or use a wallet that can’t do this itself.
Lightning to On-Chain (Loop Out)
You send Lightning sats to a swap service and it sends on-chain bitcoin to an address you choose, such as a merchant’s. Lightning Labs’ Loop does this for LND nodes. Boltz, which did it from any Lightning wallet, switched off all its swaps on 3 August 2026 and was still offline when we checked on 8 November 2026. Several wallets and node tools built their swaps on Boltz, so if your wallet offers a swap, check that it works and try a small amount first. On your own node, a Loop Out also frees up inbound liquidity.
On-Chain to Lightning (Loop In)
The reverse: you send on-chain bitcoin to the swap service, and it pays a Lightning invoice for you. This is useful for refilling a channel from an exchange that only withdraws on-chain.
How Submarine Swaps Work
A swap ties both payments to the same secret, the way an HTLC does (Lesson 4.1). The secret that unlocks the Lightning payment also unlocks the on-chain one, so if one side completes, the other can too. If the swap times out, each side can reclaim what it locked, though not always in full: coins locked on-chain come back through a refund transaction that pays its own mining fee, and a Loop Out that fails on your side can cost you Loop’s no-show penalty. Until a swap settles, keep any refund details your wallet gives you.
Swaps cost more than a plain Lightning payment: a service fee, which each service shows before you confirm, plus on-chain mining fees.
Troubleshooting Failed Lightning Payments
Lightning payments fail more often than on-chain ones, because each one depends on the current state of channels across the network. Wallets word their errors differently; Phoenix shows simpler messages than node software, but the causes are the same.
“No Route Found”
Your wallet couldn’t find a path to the recipient with enough capacity. Possible causes:
- the recipient’s wallet or node is offline
- the recipient has no public channels and the invoice has no routing hints
- your node is poorly connected to the rest of the network
Fix: ask the recipient whether their wallet is open and online. If you run your own node, open channels to well-connected nodes. Try again in a few minutes; the network changes constantly.
“Payment Timed Out”
Your wallet tried routes and gave up because a node along the way was slow or unresponsive.
Fix: once the payment no longer shows as “pending”, retry; the wallet will usually avoid that node. If it stays “pending” for a long time, don’t retry: that is a different situation, explained in Lesson 4.2.
“Insufficient Local Balance”
You are trying to send more than you have available in your channels.
Fix: add funds, or send a smaller amount.
“Channel Reserve” Error
Each side of a channel must keep a small amount it can’t spend, the channel reserve, so it always has something to lose if it tried to cheat. The Lightning specification suggests 1% of the channel. Some money is also set aside for fees in case the channel is closed on-chain.
Fix: you can’t spend your whole channel balance. Send a bit less, or add funds.
“Invoice Expired”
The invoice is past its expiry time. Each wallet sets its own; the specification’s default, used when an invoice doesn’t say, is one hour, and LND’s invoices last 24 hours unless set otherwise.
Fix: ask the recipient for a new invoice. Creating one costs nothing.
For more cases and deeper diagnostics, see our lightning troubleshooting guide for failed transactions.
Lightning Payments Best Practices
Keep Channels Balanced
Phoenix does this for you. On your own node, a channel that only ever sends runs out of outbound, and one that only receives fills up. Using your channels in both directions keeps them useful; when that isn’t enough, Lesson 4.8 covers rebalancing.
Use the Right Wallet for Your Needs
Don’t keep large amounts in a custodial wallet, and don’t take on a node-connected wallet if you only want to buy coffee. Match the wallet to the use; Lesson 4.3 compares them.
Keep Small Amounts on Custodial Wallets
If you use a custodial wallet for convenience, treat it like cash in your pocket: keep only what you could afford to lose. Move larger amounts to a self-custodial wallet or on-chain cold storage. Apply the same rule to any wallet whose custody model you can’t check yourself. Wallet of Satoshi is a case in point: it was custodial for years, and the company now describes two modes: self-custody on Spark with a 12-word recovery phrase, and a custodial account that new users get by default in the regions where it is offered (its disclosure, 25 August 2026). Check which mode yours is in; we have not verified either (Lesson 4.3).
Back Up the Right Things
A Lightning wallet holds money in channels, and channels need more than a seed in some setups:
- Phoenix: your 12 recovery words. ACINQ’s node keeps an encrypted copy of your channel data and returns it when you restore.
- Zeus with its built-in node: the recovery words. With LDK Node, the default for new wallets since Zeus v13, Zeus also saves your channel state continuously, encrypted, to a VSS server: restore against that same server and your channels should come back open. With embedded LND, the default before v13, you also need the channel backup Zeus uploads by default, and restoring from it closes your channels, so the money returns on-chain after a wait.
- Your own node: the recovery words and a recent channel backup, the small file a restored node uses to get the money out of your channels. The node’s live channel database is not a backup: never restore an old copy of it or start a node on one. Our lesson on Lightning backups and watchtowers explains what each file does.
Keep Payment Proofs
Every successful lightning payment produces a payment preimage, a 32-byte secret the recipient reveals when paid. Having it proves the invoice was paid. If a merchant says you didn’t pay, the preimage and the invoice settle it. Most wallets keep it in the payment details (in Phoenix, in the technical section of a sent payment). For large payments, save it.
Key Takeaways
- Before funding any wallet, write down its recovery words on paper and keep them offline
- Sending takes seconds: scan an invoice QR code, check the amount, confirm. No block confirmations needed
- The first deposit has a fixed cost (in Phoenix: on-chain, the mining fee plus 1,000 sats if it creates your first channel; over Lightning, 1,000 sats plus 1% and a mining fee), so don’t start with a tiny amount
- Receiving needs inbound liquidity: Phoenix arranges it for a fee, within a fee limit you can raise (5,000 sats by default); on your own node you arrange it yourself
- Tiny payments are cheap in sats but expensive as a percentage: Phoenix’s 4-sat minimum is 40% of a 10-sat payment
- Submarine swaps (such as Loop for LND nodes) move money between on-chain and Lightning, and Phoenix does this for you; Boltz has been offline since 3 August 2026
- A timed-out payment can be retried; a payment stuck pending should be left to finish
Frequently Asked Questions
How fast are lightning payments compared to on-chain Bitcoin?
Lightning payments usually complete in a few seconds. An on-chain payment needs at least one block confirmation, about 10 minutes on average, and many services wait for 3 to 6 confirmations (30 to 60 minutes). For everyday purchases, that difference is what makes Lightning practical.
Can I get a refund on a lightning payment?
Lightning payments are final: there is no chargeback as with credit cards. For a refund, the recipient has to send you a new payment. BOLT12, the newer invoice format, includes a way for a merchant to pay you back, but not every wallet supports it yet. Finality protects merchants from chargeback fraud, and it means you should check the details before you confirm.
What is the maximum amount I can send over lightning?
The protocol sets no single maximum, but every channel on the route must have enough on the right side, and a channel can never carry more than its capacity minus its reserve. Multi-path payments help by splitting one payment across several routes. Small and medium payments usually route without trouble; large ones may need well-connected nodes with big channels. For very large transfers, an on-chain transaction is usually the better choice.
Do I need to be online to receive lightning payments?
Yes. Your wallet or node must be online to accept a Lightning payment, unlike an on-chain address, which receives whether or not your wallet is open. If you are offline when someone pays, the payment fails and they keep their money. Phoenix reduces the problem with push notifications that wake the app in the background so it can accept the payment; that needs the phone to be on and connected (Phoenix FAQ). And anyone can always pay your on-chain address instead.
Is it possible to earn money by routing lightning payments?
Yes, if you run a Lightning node with well-funded channels that sit on useful routes: you earn a small fee on each payment you forward for others. The income is usually small, and it needs an always-on node and active channel management. Lesson 4.8 covers routing and its economics.
Check Your Understanding
1. You’ve installed Phoenix and want to send it 50,000 sats from an exchange. What should you do before sending anything, and why?
Answer
Write down the 12 recovery words on paper and store them safely offline. If the phone is lost or broken, those words are the only way to restore the wallet and the money in its channel.
2. You send 50,000 sats to your Phoenix on-chain address, but an hour later they show as “sleeping”. Is your money lost?
Answer
No. Phoenix waits for 3 confirmations and then moves the funds into Lightning only if the mining fee is below the maximum you set. Sleeping funds are still yours; Phoenix tries again later, or you can raise the maximum fee in Settings → Channel management.
3. Why is sending 10 sats over Lightning cheap in one sense and expensive in another?
Answer
The fee is only a few sats, a tiny amount in absolute terms. But fixed fees dominate tiny payments: with Phoenix’s 0.4% + 4 sat, a 10-sat payment costs about 4 sats, 40% of the amount.