Why Lightning Fits Commerce
The Lightning Network is a payment protocol built on top of Bitcoin that moves transactions off the base layer into payment channels. Funds are locked on-chain once, and the two channel parties can then exchange an effectively unlimited number of payments instantly, settling back to the Bitcoin blockchain only when the channel closes. Payments route across the network through connected channels, so a customer does not need a direct channel with the merchant to pay. The mechanics are covered in How Do Lightning Payments Work?
For a business at the point of sale, three properties matter:
- Instant settlement. A Lightning payment completes in seconds. The customer scans, pays, and the register can close the sale immediately. There is no waiting for confirmations and no settlement window measured in business days.
- Fees measured in fractions of a cent. Routing fees on Lightning are typically well under one cent for retail-sized payments. Card processing at two to three percent makes a $3 coffee cost the merchant roughly a dime in fees; Lightning makes the same fee close to invisible. This changes the economics of small transactions and makes micropayments viable at all.
- Finality. A completed Lightning payment cannot be reversed by a bank, a card network, or the customer. Chargeback fraud is structurally impossible.
Chargebacks exist partly as a consumer protection: a cardholder who never receives the goods can dispute the charge. Lightning removes that mechanism, so the trust burden shifts to the merchant's reputation and refund policy. Merchants who want repeat customers should publish clear refund terms and honor them; a Lightning refund is simply a new payment sent against a fresh invoice provided by the customer. For businesses selling to strangers at any scale, this trade is usually favorable: fraud losses drop to zero while honest refunds remain fully within the merchant's control.
Liquidity Basics: What a Merchant Needs to Know
Lightning's one new operational concept is liquidity. Funds in a payment channel sit on one side or the other, and the balance on the far side, called inbound liquidity, is what determines how much a merchant can receive.
A merchant who opens a new channel funds it from their own side, which means the channel starts with all the capacity pointed outward and none available to receive. Customers cannot pay until some capacity faces the merchant. There are three standard ways to get it:
- Buy it. A Lightning service provider (LSP) sells channels opened toward the merchant's node, with inbound liquidity available immediately. The LSP specifications standardize how clients request these channels, and most merchant-focused node software can negotiate them automatically.
- Earn it by spending. Every payment a merchant sends out through a channel converts outbound liquidity into inbound liquidity. A business that pays suppliers over Lightning replenishes its inbound liquidity as a side effect.
- Rebalance. Tools such as submarine swaps move funds between Lightning and on-chain (or other layers) to shift channel balances, in exchange for a small fee.
Sizing matters more than mechanism. A merchant expecting $2,000 of Lightning sales per day needs at least that much inbound liquidity per day, minus whatever flows back out through spending or scheduled settlement. Underestimating inbound liquidity is a common cause of failed payments at otherwise healthy merchant nodes. Network-wide capacity context is covered in Lightning Network Capacity and Adoption.
Integration Paths for Lightning Payments
A business can adopt Lightning at three levels of involvement. The levels are not exclusive; many businesses start at the first and migrate toward the third as volume grows.
Hosted Lightning Through Payment Processors
Payment processors that support Lightning handle everything: the node, the channels, the liquidity, invoice generation, and settlement. Many convert each payment to fiat at the moment of sale, so the business receives local currency and never holds bitcoin. Service fees in this category are typically around one percent.
This is the shortest path to accepting Lightning and requires no Bitcoin expertise. The cost is custody and dependence: the processor controls the funds between payment and settlement, applies its own compliance policies, and sits in the payment path. A business choosing this route should ask the same questions it would ask of any financial intermediary, starting with how customer funds are held and what happens to in-flight settlements if the processor has an outage.
Self-Hosted Nodes With Core Lightning
At the other end, a merchant can run its own Lightning node. Core Lightning (CLN) is Blockstream's open-source implementation of the Lightning protocol, written in C and Rust, in production on Bitcoin mainnet since 2018. It is free to use, lightweight enough to run on modest hardware, and built around a plugin architecture that lets a business extend the node in any language that speaks JSON-RPC. Community plugins cover accounting exports, automated channel management, and dynamic fee adjustment, and the built-in Bookkeeper module tracks every payment at millisatoshi resolution with CSV export for financial reporting.
CLN also includes support for the LSP specifications: the LSPS0 transport is built in, and LSPS2 liquidity negotiation is available as experimental support, so a self-hosted merchant node can negotiate inbound liquidity purchases from providers rather than bootstrapping channels manually. Payments use standard BOLT protocol invoices, including BOLT 12 offers, which allow reusable payment codes that suit recurring billing.
Self-hosting puts the merchant in full control of funds and fees, with no intermediary in the payment path. The cost is operational: the node must stay online, channels must be monitored and backed up, and someone has to own that responsibility.
Embedded Node Infrastructure With Greenlight
Between the two sits a model where the node runs on managed infrastructure but the keys stay with the business. Greenlight is Blockstream's hosted Core Lightning service: Blockstream provisions and operates the node in the cloud, while the signing keys remain on the user's own device, so Blockstream cannot move the funds. Nodes start on demand when a payment needs handling and sleep when idle, which suits businesses embedding Lightning into an app or platform without running node infrastructure. A Greenlight node can be migrated to self-hosted infrastructure at any time, so the model does not lock a growing business in.
This category, managed infrastructure with user-held keys, is worth understanding as a distinct option because it separates two things that hosted processors bundle: who runs the machine and who controls the money. The custody distinction is explained more broadly in Lightning Wallets: Custodial vs. Self-Custodial.
What Lightning Payments Cost a Business
The cost structure differs from card processing in both size and shape. Card costs scale with revenue forever, while Lightning costs are mostly fixed and front-loaded:
- Channel opens are on-chain transactions, so each one pays a base-layer network fee. A merchant setup might involve a handful of channels.
- Inbound liquidity purchased from an LSP carries a one-time fee per channel, typically a small percentage of the capacity provided.
- The sender covers routing fees on incoming payments. Outgoing payments (refunds, supplier payments) carry routing fees that are usually a fraction of a cent.
- Hosted processors add their service fee, typically around one percent, in exchange for absorbing all of the above.
For a self-hosted merchant, the marginal cost of the thousandth payment in a month is effectively zero.
Operational Caveats for Merchants
Lightning in production is reliable, but a merchant deployment has real operational edges that deserve planning rather than discovery:
- A receiving node holds hot keys. Funds in channels are controlled by keys on an online machine. Merchants should sweep revenue above a working float to cold storage or a treasury account on a schedule, exactly as they would not leave a month of cash in the register.
- Uptime is part of the product. A node that is offline cannot receive payments. Self-hosted merchants need monitoring; hosted and managed options absorb this.
- Channel state must be backed up correctly. Restoring a Lightning node from a stale backup can forfeit funds, so merchants should use the backup mechanisms their node software documents rather than improvising with file copies.
- Invoices expire. A Lightning invoice is valid for a limited window, and the quoted fiat conversion is locked for an even shorter one. Point-of-sale flows handle this automatically; custom integrations must handle it explicitly.
- Refunds need the customer's participation. There is no card number to credit. The customer supplies a fresh invoice and the merchant pays it, which means refund handling belongs in the support workflow.
- Very large payments may route poorly. A single payment much larger than typical channel capacity can fail to find a path, though multi-part payments, which split one payment across several routes, reduce this in practice. On-chain remains the better rail for invoice sizes in the tens of thousands of dollars; see the comparison in How Can a Business Accept Bitcoin Payments?
Accounting and Volatility
Lightning speeds up payments but does not change how they are accounted for. Each received payment is income at its fair market value on receipt, and a held balance carries price exposure until converted or spent. High payment counts make automation matter more: a cafe taking hundreds of Lightning payments a day wants its node or processor exporting records directly into the accounting system, not a bookkeeper reconciling sats by hand. Merchants who hold a bitcoin balance should treat that as a treasury decision and handle it under the policies described in How Do Companies Account for Bitcoin?
Checklist: Choosing a Lightning Setup
Before committing to a processor, a managed node, or self-hosted infrastructure, a merchant can score each option against the questions that actually differentiate them:
- Who holds the keys while a payment is in flight, and where do funds sit between payment and settlement?
- How is inbound liquidity provided and scaled when sales volume grows? Is there an LSP relationship, and what does added capacity cost?
- What happens during an outage, both the merchant's and the provider's? Can the business still take payments by another method?
- Does the option export per-payment records the accounting workflow can consume?
- Can the setup convert to fiat automatically, hold bitcoin, or split, and can that policy change later without re-platforming?
- If the business outgrows the option, is there a migration path that does not strand funds or history?
A merchant who can answer all six for a candidate setup understands it well enough to deploy it. For grounding on the protocol itself, start with What Is the Lightning Network?
Frequently Asked Questions
Does a merchant need to run a Lightning node?
No. A merchant can accept Lightning payments through a hosted processor with no node at all, run a node on managed infrastructure where the keys stay with the merchant, or operate a fully self-hosted node. Each step up the ladder trades convenience for more control over funds and fees.
What is inbound liquidity and why does it matter?
Inbound liquidity is the capacity on a merchant's payment channels available to receive funds. A new channel opened by the merchant starts with no inbound liquidity, so customers cannot pay until the merchant acquires inbound liquidity, typically by purchasing a channel from a Lightning service provider or by spending first.
Can a Lightning payment be reversed or charged back?
No. A completed Lightning payment is final. There is no bank or card network that can claw it back, which eliminates chargeback fraud for the merchant. Customers lose the dispute mechanism cards provide, so merchants should publish a clear refund policy and issue refunds against a fresh invoice from the customer.
What does it cost to accept Lightning payments?
Lightning routing fees are usually a fraction of a cent per payment. Self-hosted node software such as Core Lightning is free and open source, though merchants pay on-chain fees to open channels and may pay a Lightning service provider for inbound liquidity. Hosted processors add a service fee, typically around one percent.
Can a business accept Lightning payments without holding bitcoin?
Yes. Payment processors that support Lightning can convert each payment to fiat at the moment of sale and settle to a bank account, so the business never holds bitcoin. Businesses that want to keep the bitcoin can instead receive payments to a node whose keys they control.