Bitcoin onchain and the Lightning Network can both carry bitcoin-denominated payments, but they create different checkout and operational experiences. Onchain payments are broadcast to the Bitcoin network and recorded in blocks. Lightning payments use invoices and payment channels to route value offchain, with channel balances ultimately anchored to Bitcoin. A merchant should treat them as distinct rails rather than presenting one generic Bitcoin option.
Compare the payment request
An onchain checkout usually provides a Bitcoin address, requested amount, and optional URI. The request can remain valid for a defined period, but the underlying address can receive funds later. The merchant watches the network for a matching transaction and applies a confirmation policy before fulfillment.
A Lightning checkout generates an invoice with an amount, destination information, expiry, and other payment data. The invoice is designed for a specific payment and generally should not be reused. The Lightning payment lifecycle guide explains that Lightning uses invoices rather than ordinary addresses. The user interface should label “Bitcoin” and “Bitcoin Lightning” clearly, because scanning the wrong request may fail or confuse the customer.
Match the rail to value and urgency
Onchain payments can fit higher-value transfers where the customer and merchant are comfortable waiting for the merchant’s confirmation threshold. Lightning can fit low-value or time-sensitive checkout where a routed payment can complete quickly. These are tendencies, not absolute rules. Actual success depends on fees, liquidity, wallet support, and merchant policy.
A merchant can set different minimums and maximums for each rail. Very small onchain payments may be uneconomic during high-fee periods, while a large Lightning payment may fail if the route lacks liquidity. The checkout can recommend a method based on amount without hiding the choice. It should not promise a fixed completion time, because onchain inclusion varies and Lightning routing can require a retry.
Model the fees correctly
For onchain Bitcoin, the sender normally selects a transaction fee based on transaction size and desired inclusion. The merchant may also incur later consolidation or withdrawal fees. A business that receives many small outputs should consider the future cost of spending them, not only the fee the customer pays today.
Lightning senders typically pay routing fees, while merchants or service providers manage channel liquidity and node costs. A processor may charge a service fee or spread. Compare the total operating cost rather than one fee field. Display the invoice amount separately from estimated fees. The customer should send the requested amount; the wallet or provider handles the fee. If an exchange deducts a withdrawal fee, the merchant needs a short-payment policy.
Keep confirmation policies rail-specific
An onchain transaction can be detected before it is included in a block. Some merchants accept unconfirmed transactions for low-risk cases, while others wait for one or more confirmations. The policy should depend on amount, product, and risk rather than one universal number.
Lightning uses a different acceptance model. A successfully settled invoice provides payment evidence within the Lightning system, but the merchant still needs reliable node or provider reporting and a durable record. The payment state machine can normalize final business states while preserving rail-specific details. An onchain transfer may move from detected to confirming to accepted; a Lightning invoice may move from open to settled or failed.
Plan Lightning liquidity
Lightning payments require a route with enough capacity and a merchant endpoint able to receive. A self-hosted merchant may need inbound liquidity, channel management, monitoring, backups, and node security. A service provider can abstract much of that work, but it introduces custody, availability, and account dependencies.
Test the actual amounts customers will pay. A demonstration payment of a few sats does not prove that a typical order can route. Monitor route success, failure reasons, and invoice expiration. If the merchant uses several providers or nodes, each invoice must map to the correct order and settlement account. Liquidity also affects refunds: a Lightning refund may require the customer to create a new invoice.
Design for wallet compatibility
Some wallets support onchain only, some Lightning only, and some both. The checkout cannot reliably infer capability from the browser, so it should provide explicit choices and human-readable labels. On mobile, test deep links and the return path from wallet to merchant browser.
QR codes should encode the correct request type. Provide copyable text for accessibility and recovery, but avoid encouraging users to edit payment strings manually. Store the payment intent server-side so the customer can reopen the status page after the wallet closes or a redirect fails. A wallet’s return signal is not proof of payment; the merchant should observe the rail independently.
Handle partial and duplicate payments
Onchain customers can send an amount that does not match the request or can send several transactions to the same address. Decide whether the order accepts cumulative payments and how long it remains open. Reused addresses can make attribution and privacy more difficult, so dedicated addresses or robust mapping are preferable.
Lightning invoices are amount-specific and single-use in common flows, which can reduce ambiguity. Still, the gateway must handle expired invoices, failed attempts, and a customer who generates a new invoice after the first one settles. Idempotent order logic prevents duplicate fulfillment. Support staff should see all attempts without needing node administrator access.
Separate payment from settlement
A merchant may receive bitcoin directly, use a custodial processor, or convert to another asset or local currency. Onchain and Lightning balances may reside in different systems before settlement. The finance record should connect the checkout to the provider or wallet balance and then to any conversion and withdrawal.
For self-hosted Lightning, channel balances and onchain wallet balances are related but not identical. Treasury procedures should distinguish spendable Lightning liquidity, onchain funds, pending channel operations, and provider balances. Accounting exports need the order ID, rail, bitcoin amount, pricing-currency value, time, fees, provider, settlement, and transaction or invoice references.
Build rail-specific refund procedures
An onchain refund requires a verified Bitcoin address. A Lightning refund commonly requires a fresh invoice or another agreed payment method. Do not automatically send funds back to the address that funded the original transaction, because it may belong to an exchange or custodial service.
The refund record should identify the original order, rail, approved amount, destination, approvers, fees, and resulting transaction or invoice. Explain to customers that a refund is a new payment rather than a reversal. Test refund workflows before launch so support teams are not improvising with live funds.
Use both rails only when operations support both
Offering onchain and Lightning can serve more customers, but it doubles testing and exception handling. Launching Lightning simply because it is fast can disappoint users if liquidity is weak. Launching onchain for tiny purchases can create poor fee economics. Match the rail to the order profile and customer wallets.
Pilot with real transaction sizes, multiple wallet categories, and failure scenarios. Test expired invoices, delayed onchain inclusion, short payments, route failures, refunds, provider outages, and settlement reconciliation. Bitcoin and Lightning are complementary tools: onchain offers the base network’s settlement model, while Lightning offers a payment-channel network optimized for interactive payments. A dependable checkout preserves that distinction and communicates status precisely.
A merchant can also route methods by order characteristics instead of forcing one default. Lightning may suit smaller, time-sensitive purchases when wallet support is strong, while onchain Bitcoin may suit other customer preferences or higher-value workflows under a different confirmation policy. The checkout should explain the distinction without asking customers to understand internal treasury architecture.
