Lightning for Bitcoin Merchants: Invoices, Channels, and LSPs

A barista in San Salvador scans your phone and — before the espresso machine finishes pulling the shot — a green checkmark appears on the till. Total: 210 satoshis. Fee paid: less than a cent. Settlement: final. That is the Lightning Network at work, and in 2026 any merchant with a smartphone and an afternoon can set it up.

This guide covers how Lightning channels and invoices work, why the inbound-liquidity barrier that once blocked merchant adoption has been solved by a class of businesses called Lightning Service Providers (LSPs), and how to choose a stack that matches your appetite for custody and complexity.

How Lightning Channels Work

A Lightning channel is a 2-of-2 multisig UTXO locked on the Bitcoin blockchain. Two parties co-fund it, then exchange signed-but-not-broadcast Bitcoin transactions — called commitment transactions — that record the latest agreed balance. As long as both cooperate, balance updates happen in milliseconds, not in on-chain blocks.

Payments route across multiple channels via HTLCs — Hash Time-Locked Contracts. When you pay a merchant two hops away, each routing node locks funds behind the same cryptographic hash. The merchant releases a preimage proving receipt; it propagates backward and settles every hop simultaneously — or rolls everything back inside the timelock if anything fails. Routing nodes cannot steal funds without broadcasting an outdated channel state and forfeiting a penalty transaction.

Lightning Network payment channels covers the full channel lifecycle. What matters for merchants: settled payments are irreversible and fees run fractions of a cent regardless of payment size.

BOLT11 is the original invoice standard. The merchant generates a one-time payment request encoding the amount, destination node, and a payment hash. Every sale requires a fresh one, and every invoice exposes the merchant's public node key.

BOLT12 Offers, merged into the official Lightning specification in October 2024 and enabled by default in Core Lightning (CLN) in November 2024, replace per-payment invoices with reusable static identifiers. A customer's wallet fetches a fresh invoice over onion messaging each time, so the merchant prints one QR code that works indefinitely. BOLT12 also adds route blinding: the receiver's node position in the channel graph is hidden behind a blinded path, protecting merchant privacy. More than 20 wallets and services now support BOLT12, including Phoenix, Alby Hub, Strike, Breez SDK, and Zeus.

Public channel capacity tracked by 1ML stands at roughly 2,860 BTC across approximately 21,276 channels and 6,257 nodes — understating real capacity, because private (unannounced) channels used by most mobile wallets and merchants are invisible to public explorers.

The Inbound-Liquidity Problem — and How LSPs Fix It

A freshly opened Lightning node starts with zero inbound capacity: it can send payments, but cannot receive any until a counterparty opens a channel toward it. This was historically the biggest barrier to merchant adoption.

LSPs — Lightning Service Providers — are businesses that open and manage channels on behalf of users or merchants, providing inbound liquidity for a fee. Think of them as bandwidth providers for the payment network.

The LSP specification originally lived at github.com/BitcoinAndLightningLayerSpecs/lsp. That repository was archived on January 10, 2025 when the group transitioned to a bLIP (Bitcoin Lightning Improvement Proposal) process. The three core protocols became bLIP-50 (transport), bLIP-51 (channel leases), and bLIP-52 (JIT channels).

bLIP-52 standardises just-in-time (JIT) channel opens: when a first payment arrives for a merchant wallet with zero inbound capacity, the LSP intercepts the incoming HTLC, opens a channel on-chain in real-time, and forwards the payment through it. The channel-open fee is deducted from the payment amount, so the merchant receives slightly less on that first transaction but never has to pre-fund liquidity or manually negotiate channel opens.

bLIP-51 channel leases let merchants pay an LSP upfront to hold an inbound channel open for a fixed period — similar to renting bandwidth — giving predictable fees and longer-term liquidity planning compared to the per-payment JIT model.

LDK v0.1, released in January 2025, shipped support for both sides of the LSPS negotiation protocols, enabling any LDK-based application to act as an LSP client or server.

Choosing Your Merchant Stack

The central decision is how much operational complexity you will own, and how much custody you will delegate.

Self-hosted (BTCPay Server) is the most sovereign option. It is open-source, charges zero fees, and settles funds directly into the merchant's own wallet — no intermediary touches the keys. It integrates with WooCommerce, Shopify, PrestaShop, and Magento via official plugins, and includes a built-in Lightning node, a point-of-sale interface, and a Greenfield REST API for custom integrations. The cost is operational: you run and maintain a server (a $5/month VPS, or a home node via Umbrel or Voltage) and manage your own channel liquidity.

Non-custodial managed-node wallets — Phoenix (by ACINQ), Breez, and Zeus — handle node complexity in the background. You hold your own keys, but the app communicates with an LSP for channel management. Phoenix uses a single dynamic channel backed by ACINQ's LSP with JIT top-ups on first receive; it charges approximately 0.4% of the received amount on JIT channel opens. The custody tradeoff: you retain self-custody, but ACINQ is a single point of operational dependence — if their LSP becomes unreachable, inbound payments fail until you establish an alternative channel.

Custodial services — Strike, OpenNode, Wallet of Satoshi — handle all node and liquidity management. The merchant receives BTC or fiat credited to an account, instant settlement, zero technical overhead. In exchange, the custodian holds the keys and counterparty risk applies; KYC requirements are standard.

The decision matrix: custodial services for zero ops burden and fiat conversion; non-custodial managed wallets for self-custody without server management; BTCPay Server for maximum sovereignty. Choose based on honest assessment of your operational capacity, not aspiration.

For merchants more comfortable with stablecoin settlement than BTC price exposure, the crypto payment rails overview in this series covers the stablecoin merchant stack in parallel.

Stablecoins on Lightning: Taproot Assets

The volatility problem — accepting BTC for a $5 item and watching the price move before you convert — is Lightning's most cited commercial objection. Taproot Assets addresses it at the protocol layer.

Taproot Assets (formerly Taro) is a Lightning Labs protocol that uses Bitcoin's Taproot upgrade to embed asset metadata in Bitcoin UTXOs. Assets issued this way can be deposited into Lightning channels and transferred over the existing Lightning Network without requiring any intermediate routing node to upgrade or opt in. The routing mechanism is elegant: an asset-denominated payment moves as ordinary sats through BTC-only nodes; conversion to the asset happens only at the destination.

Lightning Labs' documentation states the protocol explicitly enables users to "hold a balance in their wallet different from BTC: for instance, a stablecoin," with atomic swaps between assets and BTC supported at routing hops. Tether has expressed interest in deploying USDT on Taproot Assets rails — which would bring the world's largest stablecoin by volume to instant-settlement Bitcoin payments — though merchants should verify current deployment status with Tether and Lightning Labs before depending on native USDT issuance.

The Taproot Assets ecosystem is still maturing in 2026. Wallet and LSP support for asset channels lags BTC-only Lightning. Merchants wanting price stability today are better served by converting to fiat at the custodial layer rather than depending on asset-channel wallets that, while production-capable, are not yet broadly deployed.

Your Path to Accepting Lightning in 2026

1. Choose a custody model. BTCPay Server for maximum sovereignty; Phoenix or Zeus for self-custody without server management; Strike or OpenNode for zero operational overhead.

2. BTCPay Server path. Deploy on a VPS using an official one-click image (LunaNode or Voltage). Connect LND or CLN, install the WooCommerce or Shopify plugin. Typical time to your first invoice: under two hours. Manage inbound liquidity by opening a channel to a well-connected peer, or use Voltage Flow for automated provisioning.

3. Phoenix or Breez path. Install the app and generate a Lightning address (via LNURL or a custom domain via BIP 353). Share the address or a BOLT12 offer QR with customers. Inbound liquidity is handled automatically on first receive for the JIT fee.

4. Deploy BOLT12 at point of sale. Generate a BOLT12 offer and print one static QR. Every customer scans the same code; the wallet fetches a fresh invoice over onion messaging. No per-sale merchant interaction required.

5. Zelcore integration. Users already holding Bitcoin in Zelcore have Lightning access built in. Confirm inbound transactions in Zelcore's Bitcoin and Lightning view and move confirmed funds to cold storage when batch sizes justify the on-chain fee — understanding why on-chain Bitcoin fees can spike during mempool congestion helps you time those moves.

6. Test before going live. Send a 1,000-sat payment to yourself from a second wallet, verify receipt, then process a real customer transaction. The two most common failure modes — misconfigured network and zero inbound capacity — surface immediately on a sub-$1 test.

Key Takeaways

• A Lightning channel is a 2-of-2 multisig UTXO; payments route trustlessly via HTLCs without touching the base layer, settling in seconds for fractions of a cent.
• BOLT12 Offers (merged October 2024, CLN default November 2024) replace per-sale invoices with reusable static QR codes and add route blinding for merchant privacy; more than 20 wallets already support BOLT12.
• LSPs solve the inbound-liquidity barrier via JIT channel opens (bLIP-52): the first payment to a new merchant node triggers an instant on-chain channel open with the fee deducted from the received amount — no pre-funding required.
• Stack choice maps to custody: BTCPay Server (sovereign, higher ops), Phoenix/Breez/Zeus (self-custody with LSP management), custodial services (zero ops, counterparty risk). Be honest about your operational capacity when choosing.
• Taproot Assets enables stablecoin balances to move over the Lightning Network without node-wide upgrades — relevant for merchant volatility concerns, but wallet support is still maturing in 2026.

Sources

• https://1ml.com
• https://bitcoinops.org/en/topics/offers/
• https://bolt12.org
• https://github.com/lightning/bolts/blob/master/12-offer-encoding.md
• https://github.com/BitcoinAndLightningLayerSpecs/lsp
• https://github.com/lightning/blips/blob/master/blip-0052.md
• https://bitcoinops.org/en/newsletters/2025/01/17/
• https://btcpayserver.org
• https://docs.lightning.engineering/the-lightning-network/taproot-assets/taproot-assets-on-lightning