What Happens After You Scan a Lightning Invoice
The invoice looks fine. Your wallet has enough bitcoin. You press Pay, but the confirmation never arrives. What is it waiting for? A Lightning payment needs funds in the right places along a route, not just a sufficient balance in your wallet. That distinction is easy to miss at checkout, where the network sits behind a simple button. Payment options vary across online services, from subscription publishers to gambling sites such as bonuseria casino. When Lightning is an available option, here is what happens between approving the invoice and receiving a result.
Before the first payment
Start with the balance screen. If it separates on-chain bitcoin from Lightning funds, the on-chain amount may not be ready for this payment. A provider-backed wallet can handle channel arrangements for you. With your own node, more of that preparation falls to you. Either way, look for the spendable Lightning amount, with some room left for fees.
Next comes the recipient's invoice. A BOLT 11 invoice carries an expiry and can specify an amount, though some let the payer choose it. Scanning a QR code saves typing; it does not prove who created the request. Get it from the intended recipient. Our wallet and node article covers the privacy questions that come with choosing a wallet.
A Lightning Network Bitcoin payment setup has several parts. When something goes wrong, separating them saves a lot of guesswork:
| Part of the setup | Its purpose | What to establish |
|---|---|---|
| Lightning wallet | Handles Lightning payments | Whether funds are ready to send |
| Recipient invoice | Describes the payment request | Amount and expiry |
| Channel liquidity | Carries value toward the recipient | Capacity in the needed direction |
| Fee allowance | Covers forwarding costs | The maximum charge you approve |
How does Lightning Network payment routing work
A direct channel to the recipient keeps the route short. Otherwise, the sender's node finds a path through other nodes and wraps their instructions in layers of encryption, known as onion routing. A forwarding node opens its layer to learn where to send the payment next. It cannot read the whole route, although that does not make it blind to everything. See the routing analysis chapter for the information it may infer.
At this point, nobody along the route has received an unconditional payment. For a standard invoice, settlement depends on a secret held by the recipient: the preimage. Revealing it lets the recipient claim the payment, then lets the preceding nodes settle their transfers in turn. What changes is the balance between channel partners. Bitcoin's blockchain does not need a separate transaction recording this purchase.
Forwarding nodes may charge a small base fee plus a fee proportional to the amount. Your node tries to find a path within the limit you allowed. It has incomplete information, though. It can see a channel on the network map without knowing how much that channel can currently send toward the recipient.
Your node may learn that a channel cannot carry the amount only after a payment attempt fails there.
Why a wallet balance is only half the story
Channel capacity counts funds on both sides of a connection. You send using your side's outbound liquidity; receiving needs inbound liquidity on the peer's side. As payments move back and forth, that split changes. The channel's total capacity can stay unchanged while the amount you can send falls.
For example, 80,000 satoshis available in one channel is not enough to send 90,000 through that channel. Fees only increase the gap. Your wallet might be able to split the payment across several routes instead, using multipart payments. But splitting cannot create liquidity where there is none. A shortage close to the recipient can still stop the payment, however much you hold at your own end.
Before moving funds around, open the failed payment's details. A useful error can narrow the problem down. Check these against the amount you were trying to send:
- The amount actually available to send over Lightning.
- The invoice's expiry time—an old request may need replacing.
- Your wallet's fee limit for this attempt.
- The recipient's available receiving liquidity, if they can check it.
- Any route or liquidity failure reported by the application.
When the payment screen keeps waiting
“Pending” is frustrating because it does not tell you whether to try again. The wallet might be searching for a route, or waiting for an outcome after sending the payment. These are different stages. Lightning Labs' documentation makes a distinction between the dispatch timeout and settlement time: stopping the search for new routes does not instantly resolve transfers already in progress.
Suppose checkout is still waiting, but your wallet already lists the payment as successful. Paying a fresh invoice could now mean paying twice. The recipient needs to trace the first payment instead. Send them its reference from your wallet history. If that history still says “pending,” there is no final result to report yet; keep following the original attempt.
An expired invoice is a different case: you need a replacement request. The table below separates that problem from a payment which has already been sent.
| What you see | What may be happening | Useful next step |
|---|---|---|
| Invoice rejected | The request is invalid or expired | Obtain a current request |
| No route found | Available paths cannot carry the payment | Read the reported failure |
| Payment pending | An attempt has not resolved | Track the existing payment |
| Wallet shows success | Settlement has completed in the wallet | Confirm the order was credited |
Where fast processing actually begins
Why use channels at all? After an on-chain funding transaction establishes a channel, its participants can update their balances without putting each payment into a Bitcoin block. A Bitcoin Lightning Network payment uses those existing connections. That makes lightning-fast payment processing possible, although the initial funding may take time. Your wallet may arrange channels in the background, out of view.
A small first transfer lets you try an unfamiliar wallet before committing a larger amount. Compare the approved fee with the recorded charge and find out where the receipt lives. You can follow the payment through these screens:
- On the balance screen, locate the amount available over Lightning.
- Use the invoice supplied by the person or checkout you intend to pay.
- At approval, check the requested amount and the maximum fee.
- In the history, find this payment and its final status.
- At the recipient's end, confirm the purchase or balance was credited.
Even a settled payment may leave you watching a checkout page. The merchant's software still has to match the incoming payment to your order. Your wallet and the order page are reporting on different parts of the purchase, so they will not always update together.
A successful small payment tells you that amount got through. A larger payment may need liquidity the same route cannot provide.
The invoice at the start of this article could have stalled for several reasons. Perhaps the route lacked liquidity; perhaps the payment settled while checkout failed to refresh. The wallet's recorded outcome helps you tell those cases apart. Keep the payment reference until the order is credited. If you need help, that record lets you describe what actually happened, rather than asking someone to guess from an unchanged checkout screen.