Guide
Lightning vs on-chain Bitcoin payments
When to use Lightning, when to use plain on-chain Bitcoin, and how to choose for your specific payment flow.
Affiliate disclosure. Some links on this page are partner links. LN Cash may earn a commission if you sign up. This does not change which tools we recommend — see our methodology and the full disclosure.
“Lightning or on-chain?” is the second-most-asked Bitcoin payment question, after “which wallet should I use?” The answer is rarely binary — most setups support both — but the trade-offs are worth understanding before you build a payment flow around either.
At a glance
| Lightning | On-chain | |
|---|---|---|
| Settlement time | Sub-second | 10 min to 1 hour for typical confirmations |
| Typical fee | Fractions of a cent | $0.50 to $20+ depending on mempool |
| Best for | Small, frequent payments | Large, infrequent payments |
| Liquidity required | Yes (channel management) | No |
| Reversibility | Final once settled | Final after confirmations |
| Privacy | Better — fewer parties see each payment | All payments are on a public ledger |
| Wallet ecosystem | Smaller, growing | Mature, ubiquitous |
| Trust model | Same Bitcoin trust + channel/routing trust | Pure Bitcoin trust |
When to prefer Lightning
- Small payments. Anything under a few dollars where on-chain fees would be a meaningful percentage.
- Tips and creator donations. Frequent, small, low-friction.
- Point-of-sale. Sub-second settlement is the right shape for “customer scans, pays, walks out.”
- Recurring payments. Subscriptions, micropayments, streaming sats.
- API-driven flows. Lightning APIs are mature; payment confirmation hooks fire in seconds.
When to prefer on-chain
- Large transactions. A $50,000 transfer where settlement-finality and chain history matter more than speed.
- Settlement out of Lightning channels. Periodically closing a channel and re-opening it; or moving sats to cold storage.
- Customers without a Lightning wallet. On-chain is the universal fallback.
- Counterparties who require it. Some institutions, exchanges, and accounting systems are not yet Lightning-aware.
When to offer both
Most merchant payment processors do exactly this:
- BTCPay Server — native on-chain Bitcoin + Lightning out of the box. The customer’s wallet determines which is used.
- OpenNode — Lightning first, on-chain fallback when the customer’s wallet doesn’t support Lightning.
- Speed — Lightning + on-chain + USDT/USDC stablecoin support.
For a merchant, the practical setup is: offer Lightning as the primary “pay with Bitcoin” option, with on-chain as the explicit fallback for customers without a Lightning wallet.
Common misunderstandings
- “Lightning is risky because it’s off-chain.” Lightning payments are secured by the same Bitcoin chain — on-chain transactions enforce the channel state if something goes wrong. The trust model is “Bitcoin plus a small amount of channel-counterparty trust during open channels.”
- “On-chain is always slower.” Average Lightning settlement is under a second. Average on-chain settlement for a small fee is 10–30 minutes. Yes, on-chain is slower — but for transactions where you would wait for accounting confirmation anyway, the speed gap matters less.
- “Lightning is hard to use.” It used to be. Modern wallets (Phoenix, Alby, Wallet of Satoshi) have onboarding that’s competitive with consumer payment apps.
Practical decision rules
For a creator: Lightning. The payments you’ll receive are small, frequent, and benefit from sub-second settlement.
For a small merchant: both. Lead with Lightning; offer on-chain as a fallback. Most processors handle this automatically.
For an ecommerce store: both, configured in your processor. Most customer wallets default to Lightning when it’s available.
For a treasury or cold-storage flow: on-chain. Lightning is not the right place to park large amounts; channels are for moving sats, not for holding them.
Next step
- Lightning fees explained — the cost side of the decision.
- Is Lightning safe? — the trust side.
- How to accept Lightning payments — the practical setup paths.
FAQ
If Lightning is faster and cheaper, why would I use on-chain? +
Lightning has trade-offs: liquidity to manage, channels to open, occasional payment failures on poorly-connected routes. On-chain is conceptually simpler, doesn't require liquidity planning, and is the right choice for large, infrequent transactions and for cold storage.
Can I run both? +
Yes, and most payment processors do — they accept Lightning when the customer's wallet supports it and fall back to on-chain when it doesn't. From a merchant's perspective, you usually offer both.
Are Lightning payments final? +
Once a Lightning invoice settles, the payment is final. There is no chain reorganization risk because no on-chain transaction is involved. On-chain payments are final after a small number of confirmations (typically 1-6 depending on amount).