Lightning enables off-chain payments backed by Bitcoin. Total channel capacity is not enough: available direction, routing and custody determine what you can actually send or receive.
Two directions
Amount and expiry
Routing and on-chain fees
Separate balance from capacity
In a hypothetical 100,000-satoshi channel, 80,000 sit on your side and 20,000 on the remote side. Before reserves and other constraints, this chiefly provides sending capacity; it does not let you receive an arbitrary 100,000. Payments shift balances without increasing total capacity. An interface may aggregate channels, so a global balance does not describe available routes.
Read the invoice
A Lightning invoice can include amount, expiry and routing information. Check those details in your application. A conventional Bitcoin address is not a Lightning invoice; unified wallets should make the actual payment method clear. Do not pay a fresh invoice merely because the previous attempt seems slow: first check its outcome to avoid making two separate purchases.
Account for the whole cost
Intermediate nodes can charge base and proportional routing fees. Your wallet may set a fee limit. Opening and closing channels also require Bitcoin transactions, while services may charge for liquidity access. Compare total cost against your actual usage, particularly infrequent payments. Lightning has no universal tariff or guaranteed payment delay.
Choose custody deliberately
A custodial wallet usually manages availability and liquidity for you, but creates dependence on the service and its ability to return funds. Self-custody makes you responsible for keys, backups and the monitoring required by your implementation. A node or watchtower does not replace a documented recovery procedure. Inspect any additional liquidity-provider dependencies.
Prepare recovery
A Bitcoin seed does not automatically recreate every channel state. Static channel backups and restoration differ across implementations; they may help request channel closure rather than resume channels unchanged. Restoring an outdated channel database can be dangerous. Follow your software documentation, practise with a small amount and retain funds for on-chain operations.
Diagnose failure
An expired invoice, unavailable route, fee limit or inadequate directional capacity can prevent payment. Record the status and error without publishing private node information. When the outcome is uncertain, inspect payment history before retrying. Receiving regularly requires incoming capacity and attention to its cost; depositing bitcoin alone does not solve every receiving constraint.
Scenarios and model limits
| Situation | Interpretation |
|---|---|
| 100,000 sat: 80,000 / 20,000 | Directional capacity before reserves; total ≠ receivable amount. |
| Expired invoice | Request a fresh invoice after checking previous status. |
| Channel closure | On-chain cost and timing depend on mechanism and state. |
Frequently asked questions
Why can I send but not receive?
Channel balances are directional. Incoming liquidity and a usable route must support the receipt; total capacity alone is insufficient.
Does Lightning remove Bitcoin fees?
Channel payments avoid an on-chain transaction for every payment, but opening, closing and some recovery operations use Bitcoin.
Is a seed phrase sufficient?
Not necessarily for channels. Check your implementation’s backups and recovery procedures before funding them.
Verifiable sources
- Lightning Labs — Payment channels
- Lightning Labs — Multihop payments
- LND — Recovery procedures
- LND — Operational safety
Independent educational content reviewed against primary documentation. No personalized recommendation or promise of returns. Updated October 3, 2026
