How Does a Lightning Network Invoice Differ from an On-Chain Invoice?
A Lightning Network invoice is a payment request for a specific amount on a separate, faster layer of Bitcoin, settled instantly once the payer's node finds a path of open channels to your node. An on-chain invoice is a Bitcoin address that records the transaction on the main blockchain, requiring confirmations that can take minutes to hours. The key difference is that a Lightning invoice is a one-time, pre-generated request that must be paid exactly as specified, while an on-chain invoice is a reusable address that can receive any amount at any time, with settlement depending on network congestion and miner fees.
What an on-chain invoice actually is
When a business generates an on-chain invoice, it is simply a Bitcoin address - usually a new one per invoice, as covered in our guide to BTCPay Server address generation. The address is a public key hash that anyone can send Bitcoin to. The transaction is broadcast to the Bitcoin network, where miners include it in a block. Settlement is probabilistic: after one confirmation (about 10 minutes on average), the payment is considered likely final, though many businesses wait for three to six confirmations for larger amounts.
The on-chain invoice has no expiry by default. The same address can receive multiple payments, though best practice is to generate a fresh one per invoice to simplify reconciliation by transaction hash and amount. If a customer sends the wrong amount, the transaction still goes through; you then have to refund or adjust, as explained in our article on wrong-amount payments.
What a lightning network invoice is
A Lightning invoice (also called a payment request) is a string of data, typically shown as a QR code or a "bolt11" text string. It contains:
- The recipient's node public key
- An amount in millisatoshis (the smallest unit on Lightning)
- A description or hash of the goods
- An expiry time (usually one hour, but configurable)
- A payment secret and other routing hints
The invoice is generated once and must be paid exactly as specified. The payer's Lightning node finds a path of channels from their node to yours. If a path exists with sufficient liquidity, the payment is forwarded instantly through a series of hash time-locked contracts (HTLCs). Settlement is atomic: either the entire payment succeeds in seconds, or it fails and nothing moves.
No transaction appears on the Bitcoin blockchain during a Lightning payment. Only when you later close a channel (or someone force-closes it) does an on-chain transaction occur. This means Lightning payments have zero block confirmation delay for the merchant.
Key differences in practice
1. Amount Flexibility
On-chain: The customer can send any amount to the address. You must verify the amount matches the invoice, or handle discrepancies. Lightning: The invoice specifies the exact amount. If the customer tries to pay a different amount, their wallet will refuse. This eliminates "wrong amount" problems entirely.
2. Expiry and Reusability
On-chain: An address does not expire. A customer could pay a month-old invoice, and the transaction would still confirm. This creates reconciliation headaches. Lightning: An invoice expires (default one hour). After expiry, nodes will reject payment attempts. You must generate a new invoice for a new payment request.
3. Settlement Speed
On-chain: The payment is "pending" until the transaction gets at least one confirmation. During high fee periods, a low-fee transaction might sit unconfirmed for hours or days. Lightning: Settlement is sub-second. The merchant sees the payment succeed immediately. No waiting for blocks.
4. Fees
On-chain: The sender pays a miner fee, which varies with network congestion. The merchant pays nothing to receive, but may pay fees later when spending. Lightning: The sender pays routing fees to intermediate nodes. The merchant typically pays a small fee (often zero) to open or close channels, but not per payment. For a high volume of small payments, Lightning fees are almost always lower.
5. Receiving Capacity
On-chain: Anyone can send to your address regardless of how much Bitcoin you hold. Lightning: You can only receive payments up to the inbound liquidity of your channels. If all your channel capacity is outbound (you have sent money to others), you cannot receive. You must manage channel balances or use services like Lightning Service Providers (LSPs) to obtain inbound liquidity.
6. Privacy
On-chain: The address, amount, and transaction are visible on the public blockchain. Anyone can trace payments. Lightning: Payments are routed through multiple nodes. Only the sender and receiver know the amount and purpose, though routing nodes see that a payment passed through. The public blockchain sees only channel open and close transactions, not individual payments.
7. Customer Experience
On-chain: The customer scans a QR code, sends Bitcoin, and waits. They must check the block explorer or their wallet for confirmation. Lightning: The customer scans the invoice, and payment completes in a second or two. Their wallet shows success immediately. This reduces cart abandonment for small purchases.
When to use each
Use on-chain invoices for: - Large payments where you want the security of Bitcoin's full proof-of-work - Payments that will be held long-term or moved to cold storage - Situations where the customer may need to pay from an exchange or wallet that does not support Lightning - Regulatory or accounting requirements that demand a public blockchain record
Use Lightning invoices for: - Small, frequent payments (coffee, digital content, subscriptions) - Time-sensitive purchases where waiting for confirmations is unacceptable - Reducing customer friction and abandonment - Lowering transaction fees on high-volume, low-value sales
Practical implications for your business
If you accept both, you will need separate invoicing flows. BTCPay Server, for example, can present both options to the customer. The merchant must monitor both on-chain addresses and Lightning invoices for incoming payments. Reconciliation is simpler for Lightning because the invoice amount is exact and payment is immediate. For on-chain, you rely on transaction hash matching and amount verification.
You also need to manage Lightning node uptime. If your node goes offline, you cannot receive Lightning payments. On-chain payments work regardless of your node's status, since they go to the blockchain, not to your node directly.
In summary: a Lightning invoice is a precise, instant, one-time payment request that requires inbound liquidity and node uptime. An on-chain invoice is a flexible, slower, publicly recorded address that works without node management but introduces confirmation delays and amount-matching complexity. Choose based on your payment size, speed requirements, and operational capacity.
Not financial advice. unidexai.xyz publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.