A Lightning balance can be real and still face the wrong direction

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

A Lightning wallet can show channel capacity without being able to send that amount, receive that amount, or route it in the required direction. Capacity is the size of the channel; liquidity is where the balance currently sits. Troubleshooting gets faster when “payment failed” is split into direction, amount, route and invoice state instead of treated as proof that Lightning or the wallet is down. If an on-chain fallback then waits, switch to the base-layer transaction triage; Lightning liquidity cannot repair it.

Start with the payment direction

For a send, inspect local or outbound liquidity. For a receive, inspect remote or inbound liquidity. Lightning Labs' liquidity guide states the core relationship: sending moves balance away from your side and increases inbound capacity; receiving moves it toward your side and consumes inbound capacity. Opening and funding a new channel normally starts with outbound liquidity, not an equal ability to receive.

Record the attempted amount, invoice, expiry, wallet or node version, channel states and available inbound/outbound figures. Do not publish invoices casually; they may include node and payment metadata. Check that the invoice is for the intended network and has not expired or already settled.

Use a directional decision tree

Cannot send: Is total outbound liquidity above the amount plus the wallet's fee limit? Are one or more channels active? A large total split across unsuitable channels may still fail. Try a smaller amount only as a diagnostic, not as proof the original payment was impossible.

Cannot receive: Is inbound liquidity available on an active path to the payer? Core Lightning's FAQ says receiving requires inbound liquidity, obtained when another node opens toward you or when you successfully pay out through a channel you funded. A merchant that only receives will eventually push balances toward its own side and exhaust that direction.

Both directions look sufficient: inspect routing and connectivity. Lightning Labs' payment guide explains that channel balances are not publicly advertised, so route finding operates with incomplete information. A route may appear to have capacity yet lack balance in the needed direction. Offline peers, restrictive fee limits and in-flight HTLCs can produce similar symptoms.

Choose a remedy that matches the fault

• Send a normal payment through the affected channel to create inbound room when that payment was already useful.
• Ask a suitable peer to open a channel toward you, recognizing that a channel to a poorly connected peer may not solve reachability.
• Rebalance through a circular payment if the node software supports it and the expected routing cost is acceptable.
• Use a submarine-swap service to move value between on-chain and off-chain balances. Lightning Labs' Loop documentation describes Loop Out as acquiring inbound capacity and Loop In as refilling depleted outbound capacity. That is one commercial implementation, not a recommendation or a universal trust/cost profile.

Do not open another channel automatically. It ties up more on-chain funds and may reproduce the same directional problem. Compare the on-chain transaction cost, service fee, routing cost, lock-up time and counterparty assumptions before choosing a liquidity action.

Respect in-flight state

A failed route can often be retried; an in-flight payment has already locked HTLCs and must resolve or time out. Check the implementation's payment tracker before resending. Creating duplicate invoices or repeated payments while the first remains in flight can cause confusing or duplicate outcomes.

The foundational Lightning mechanism article explains the channel model. This checklist answers the narrower operational question. It cannot guarantee a route, because balances, peers and policies change privately and continuously. Keep logs, set cost ceilings, and distinguish a liquidity shortage from a software or invoice error before committing more capital.