Nothing kills a Bitcoin merchant's enthusiasm faster than a customer ready to pay and a Lightning payment that fails. The customer is standing there, phone in hand, invoice scanned, and the payment bounces. "No route found." Or it times out. Or it partially routes and the rest fails. The customer pays with a card instead, slightly annoyed, and you have just demonstrated that Bitcoin payments do not work as smoothly as advertised.

The root cause, more often than not, is a liquidity problem. Your node does not have enough inbound capacity to receive the payment. Or the route between the customer's wallet and your node is congested. Or your channels are unbalanced and all the capacity is on the wrong side.

This guide covers the liquidity mechanics that merchants need to understand and the practical strategies that prevent failed payments.

Why Liquidity Matters for Receiving Payments

Lightning payments move through channels. Each channel has a fixed total capacity, split between the two channel partners. To receive a payment, you need capacity on the remote side of your channels (inbound liquidity). To send a payment, you need capacity on your side (outbound liquidity).

As a merchant, you mostly receive payments. That means you need inbound liquidity. Every payment you receive shifts capacity from inbound to outbound. After receiving enough payments, your channels fill up with outbound capacity and you cannot receive more until you rebalance or drain.

The fundamental merchant liquidity challenge:

  • When you open a channel, your funds are on your side (outbound). You have zero inbound capacity.
  • To receive customer payments, you need someone else to open a channel to you, or you need to push your funds to the other side through spending.
  • As you receive payments, your inbound capacity decreases and your outbound capacity increases.
  • Eventually, your channels are full on your side and you cannot receive more.

This is the single most common reason merchant Lightning payments fail.

How Much Inbound Liquidity You Need

The practical rule: your total inbound capacity should be at least 2 to 3 times your expected daily Lightning payment volume.

Example: If you expect to receive 200,000 sats (approximately 0.002 BTC) in Lightning payments per day, you need at least 400,000 to 600,000 sats of inbound capacity across your channels.

Why the multiple? Because:

  • Payments route through specific channels, not across your total capacity. If one channel is full, payments routed through it fail even if other channels have space.
  • Payment routing may split across multiple paths, each requiring available capacity.
  • You want headroom for unexpected payment volumes on busy days.

Strategies for Getting Inbound Liquidity

Strategy 1: Ask Someone to Open a Channel to You

The simplest conceptual approach. If another Lightning user opens a channel to your node, their funds start on their side, which is your inbound capacity.

Who opens channels to merchants?

  • Routing node operators looking for well-connected peers
  • Liquidity providers running channel services
  • Friends, colleagues, or community members willing to commit capital

How to attract inbound channels:

  • Keep your node online 24/7 with low latency (hosting providers are better than a home connection for this)
  • Set reasonable routing fees (not zero, which signals amateur, and not high, which discourages use)
  • Connect to well-known routing nodes so your node is accessible within the broader network
  • List your node on directories that Lightning wallets use for peer discovery

Strategy 2: Use a Liquidity Service

Several services exist specifically to provide inbound liquidity to Lightning nodes:

Channel marketplaces. Platforms where you can buy inbound liquidity from providers. You pay a fee (typically 1 to 3 percent of the channel size for a channel lease period) and a provider opens a channel to your node with funds on their side.

LSPs (Lightning Service Providers). Some LSPs provide automatic channel opening and liquidity management. They detect when your node needs inbound capacity and open or extend channels dynamically. This is the most hands-off approach but ties you to a specific provider.

Circular rebalancing. If you have both inbound and outbound channels, you can send payments from your node back to yourself through a circular route, shifting capacity from outbound to inbound on specific channels. This requires existing channels and costs routing fees, but it gives you fine-grained control.

Strategy 3: Spend From Your Lightning Wallet

Every Lightning payment you send reduces your outbound capacity and, on the other side of the channel, increases the counterparty's local balance, which on your side becomes inbound. Practically:

  • Pay Lightning invoices for business expenses (if suppliers accept Lightning)
  • Move funds from Lightning to on-chain via a swap service (submarine swap)
  • Purchase goods or services using Lightning for personal use

Submarine swaps are particularly useful for merchants. You convert Lightning balance to on-chain Bitcoin, which drains your channel and restores inbound capacity. The swap fee is typically 0.5 to 1.5 percent, which is a manageable cost for liquidity management.

Strategy 4: Open Balanced Channels

Some channel opening protocols allow you to negotiate a balanced channel where both parties commit funds. Instead of you committing 1 million sats of outbound capacity, you and the counterparty each commit 500,000 sats, giving you immediate inbound capacity.

Dual-funded channels are supported in CLN natively and available in LND through third-party tools. Not all peers support them, but those that do provide a more efficient starting point.

Channel Management for Merchants

How Many Channels?

For a small merchant, 3 to 5 well-chosen channels are typically sufficient. More channels spread your liquidity thinner and increase monitoring overhead. Fewer channels create single points of failure.

Recommended channel structure:

  • 2 to 3 channels with well-connected routing nodes (these provide route diversity for incoming payments)
  • 1 channel with your primary liquidity provider (for reliable inbound capacity)
  • 1 channel with a swap service (for easy outbound-to-inbound conversion)

Channel Sizing

Each channel should be large enough to handle your typical payment sizes with margin. For a merchant receiving payments of 10,000 to 200,000 sats:

  • Minimum useful channel size: 500,000 sats
  • Recommended channel size: 1,000,000 to 2,000,000 sats
  • Maximum practical channel size: depends on counterparty and your capital

Channels smaller than 500,000 sats become unusable quickly after a few payments.

Monitoring

Check your channel balances at least weekly. Look for:

  • Channels where inbound capacity has dropped below 20 percent of total (these need rebalancing or draining)
  • Channels that have been force-closed by the counterparty (these lock up your funds for days to weeks)
  • Channels with consistently high routing failure rates (these should be closed and replaced with better-connected peers)

When Liquidity Problems Are Not Actually Liquidity Problems

Sometimes payments fail for reasons unrelated to your liquidity:

  • Customer wallet issues. Outdated wallet software, poor route finding, or insufficient balance on the customer's side. You cannot fix this, but you can recommend well-maintained wallets.
  • Network congestion. During periods of high Lightning activity, routes become congested and payment attempts fail more frequently. There is no merchant-side fix beyond having diverse channel connections.
  • Invoice expiry. If the customer takes too long to pay, the invoice expires and the payment fails. Set appropriate expiry times for your use case.
  • Amount too large for available routes. Very large Lightning payments (above 1 million sats in a single payment) are more difficult to route because they require sufficient capacity along the entire path. For large amounts, on-chain payment may be more reliable.

The Practical Maintenance Cycle

Daily: No action needed unless you receive alerts about channel closures or payment failures.

Weekly: Check channel balances. If any channel's inbound capacity is below 20 percent, plan a rebalance or drain.

Monthly: Review channel performance. Close underperforming channels (low uptime, frequent routing failures) and open replacements.

Quarterly: Assess whether your total inbound capacity matches your payment volume growth. Adjust by opening additional channels or increasing channel sizes if volume has increased.

Honest Assessment

Lightning liquidity management is the most significant operational burden of self-custody merchant Lightning payments. It is not technically difficult, but it requires regular attention and a basic understanding of how capacity flows.

If you are processing fewer than 20 Lightning payments per month, the overhead of liquidity management may not be justified. Consider whether on-chain payments (which have no liquidity management burden) are sufficient for your volume.

If Lightning is important to your customer experience, invest the time to understand and manage liquidity, or use an LSP that handles it for you (at the cost of some fee and some reduced sovereignty).

For the BTCPay setup process, see our merchant setup checklist. For choosing your Lightning implementation, see CLN vs LND vs Eclair.