How to make your first Lightning payment

What you will end up with

A Lightning wallet holding a small amount of bitcoin, one payment sent against somebody else's invoice, and one payment received against an invoice you produced yourself. Both directions, because sending works first time for almost everyone and receiving is where people get stuck.

It is for someone who already holds a little bitcoin and has never used Lightning, and it assumes nothing about running a node.

On versions. The steps below were written on 20 August 2026 against each project's own documentation and against the BOLT specifications, not against one release's screens. Wallet interfaces change faster than any guide can be re-checked, so where a button in your app is named differently from a word here, trust the app and check which version you are running before following anyone's instructions, ours included.

Before you start

• An amount you would not mind losing entirely. This is a first run of an unfamiliar system. Treat the money as tuition.
• Somebody to pay. A friend with a Lightning wallet is ideal, because you can send in both directions and compare what each side saw.
• A phone or a computer, and about an hour, most of it spent waiting for an on-chain confirmation and only on the self-custodial route.
• A rough idea of current on-chain fees on that route, because opening a channel is an ordinary Bitcoin transaction that pays them. See how fees buy block space.

The decision that changes every later step

Lightning wallets come in two shapes, and the shape decides how you fund, how you receive, and what a backup even means. Decide before you install anything.

A custodial wallet holds the keys and runs the node; you hold an account. Blink's own documentation puts it plainly: "In Custodial Mode, Blink holds funds on your behalf and can help with account recovery. In Non-Custodial Mode (powered by the Spark protocol), you hold your own keys and Blink cannot access, freeze, or recover your funds."

A self-custodial wallet keeps the keys and the channel state on your device. Phoenix, from ACINQ, is one: "when creating a new wallet, a 12-words recovery phrase is generated. Only you have it." Zeus, "a mobile Bitcoin wallet and node management app", is another, and can either run an embedded node or drive a node you already operate.

Both are real Lightning. Neither is the beginner option and neither is the advanced one.

The tradeoff you are accepting

Custodial hands a company the ability to freeze, lose or refuse your balance, and the ability to see every payment you make. In exchange, receiving works on day one, there is nothing to back up beyond your account credentials, and no on-chain fee to get started. The failure mode is somebody else's decision.

Self-custodial means nobody can freeze the balance and nobody sees your payment history by default. In exchange you pay an on-chain fee to open the channel, your first receive may cost more than the amount received, and the backup obligations are larger than for an ordinary on-chain wallet. The failure mode is your own mistake. If holding your own keys on chain is still new, do that first and come back.

Funding the wallet

If you chose custodial

1. Install the app and create the account.
2. Open the receive screen and choose the on-chain option, if the wallet offers one.
3. Send a small amount from wherever your bitcoin currently sits.
4. Wait for the confirmations the provider requires, then check the balance is spendable on Lightning rather than sitting in a separate on-chain balance.

If you chose self-custodial

1. Install the app and write the recovery phrase on paper, offline, before funding anything.
2. Open the receive screen and take the on-chain address it gives you.
3. Send a small amount to it and wait for confirmation. The wallet now has on-chain funds, not Lightning funds.
4. Let the wallet open a channel, or open one yourself. Either way this is a Bitcoin transaction that pays a fee, and until it confirms you cannot pay over Lightning.

Paying an invoice

1. Ask the other side for an invoice for a specific amount. It is a long string beginning lnbc, usually shown as a QR code. What it encodes is covered in what a Lightning invoice actually is.
2. Check the expiry first. Under BOLT 11 an invoice carries an expiry in seconds, defaulting to 3600, one hour, when the field is absent. An expired invoice cannot be paid; ask for a new one.
3. Scan or paste it into your wallet's send screen.
4. Read the amount and the fee shown before confirming. The fee is quoted up front because your wallet picks the route before it sends anything.
5. Confirm. A payment that works settles in seconds.

Receiving, and the problem nobody warns you about

The mechanism first, because the symptom makes no sense without it. A channel is funded by one side. BOLT 0 describes the starting position: the two participants "each hold a bitcoin transaction that sends all the bitcoin (e.g. 0.1 bitcoin) back to one party." A payment only moves that split. So the money you can receive over a channel is whatever currently sits on the other side of it, and a channel you funded starts with none there at all. That is inbound liquidity, and no wallet can wish it away.

1. Open the receive screen and enter an amount.
2. If the wallet is custodial, you will get an invoice immediately. The provider's node holds the channels, and its inbound liquidity is its problem.
3. If it is self-custodial and this is your first receive, expect to be asked to pay for the liquidity, or to see a cap on how much you can be sent. Phoenix charges a fee to provision it automatically and publishes the schedule in its FAQ; a node you run yourself needs you to buy inbound capacity or to spend outward first.
4. Send the invoice to whoever is paying, and watch for it to settle rather than for the app to merely show it as created.

Spending outward is the cheapest way to earn inbound capacity, which is why the order for a first session is: fund, pay, then receive.

Verify it worked

1. Check the receiving side says settled, not pending. A created invoice proves nothing.
2. Send it back. Have the other person pay you, then pay part of it back. One payment in each direction is the smallest test that exercises both balances.
3. Look at your capacity numbers. After paying out, a self-custodial wallet should show more receiving capacity than before. If it does not, the payment did not settle.
4. For self-custodial wallets, do the restore test on a spare device while the balance is still trivial, following the section below. Not later, with real money in the channel.

When a payment fails

Failures are normal, and usually not your fault. Your wallet routes through other people's channels using a public map that says how big each channel is and never says how the balance inside it is currently split. So it guesses, and sometimes guesses wrong.

The hop that cannot forward returns an error to the sender. BOLT 4 defines them; two are worth telling apart:

• temporary_channel_failure: "The channel from the processing node was unable to handle this HTLC, but may be able to handle it, or others, later." Almost always the balance was on the wrong side of that channel. Retry, and retry with a smaller amount.
• incorrect_or_unknown_payment_details: the destination rejected it. The invoice is expired, already paid, or for a different amount. Ask for a new one.

A failed payment does not lose the money. A payment either settles all the way along the route or is unwound along it. The one case that looks alarming is a stuck payment, where an intermediate node goes offline mid-attempt: the amount is held until the on-chain timeout on that hop passes, then it comes back. Wait, and do not pay the same invoice again from another wallet until the first attempt has resolved.

Backups, and exactly what they cover

For a custodial wallet, the backup is your account credentials, and the provider can still lose or freeze the balance. There is no seed phrase because there are no keys of yours.

For a self-custodial wallet, a recovery phrase alone is not the whole story, because the current state of a channel is not derivable from a seed the way an on-chain address is. LND's recovery documentation lists two required items: the 24-word cipher seed, and the encrypted Static Channel Backup file. Phone wallets hide this by keeping the channel backup on the device and often in the vendor's cloud, but the requirement underneath is the same.

Two rules follow, and both cost people money regularly:

• Never run two copies of the same wallet. LND's safety guide is blunt: "you should never use the same seed on two different nodes and restoring from SCB is not a migration but an emergency procedure." Two instances can each broadcast a channel state the other has already revoked, and the counterparty is then entitled to take the whole channel balance.
• Test the restore before the wallet matters. Restore onto a second device while the balance is small, confirm the funds appear, then wipe that device.

None of this removes the requirement to be online. A Lightning wallet that is never opened cannot notice a channel being closed against it, which is a real difference from keeping coins on chain and the reason a phone holding a large Lightning balance is a worse idea than it looks. What is running underneath these apps is four different implementations, and they differ in ways worth knowing.