A bitcoin payment on the base chain waits for blocks. During congestion the fee for a small transfer can exceed the transfer, which makes anything under a certain size pointless. The Lightning Network moves the payment off that chain into a channel between two parties, settles it in seconds, and only touches the base chain when the channel is opened or closed. For small, frequent payments the improvement is not marginal, it is the difference between workable and not.
The catch sits in the word channel. A Lightning payment travels through a path of funded channels between sender and receiver, and each hop needs capacity pointing the right way. That constraint is invisible when it works and completely opaque when it does not.
Channels, capacity and the direction problem
A channel holds a balance split between two sides. Sending pushes balance towards the other side, and when your side is empty you cannot send further through that channel regardless of how much total capacity it shows. Receiving has the mirror problem: a node that has only ever sent has no inbound capacity and cannot be paid at all until someone opens a channel towards it or it rebalances.
For a business that mostly receives, inbound liquidity is the whole operational concern. It is bought, arranged with a liquidity provider, or acquired by using the node in both directions. None of that is difficult once understood, but it is a form of treasury management that no card rail asks of you, and it is the reason many firms use a custodial Lightning service rather than running a node.
Custodial or your own node
| Custodial service | Self-hosted node | |
|---|---|---|
| Liquidity management | Handled by the provider | Yours, ongoing |
| Uptime requirement | Provider's problem | Continuous, a node offline cannot be paid |
| Custody of funds | Provider holds them | You hold them, with the key handling that implies |
| Counterparty exposure | Full exposure to the provider | None beyond channel partners |
| Setup effort | An account and an API key | Infrastructure, monitoring, backups |
The custody trade-off here is the same one that runs through every crypto rail decision, and it is worth reading against custodial and non-custodial arrangements generally. A custodial Lightning provider is a counterparty holding your money, which is precisely the risk bitcoin payments were meant to avoid, and firms should size the balance held there accordingly.
Where Lightning actually fits in a trading business
Honest answer: narrowly. Client deposits at brokers and prop firms are dominated by cards, bank transfers and stablecoins, and a client who wants to deposit in crypto almost always holds a dollar-pegged token rather than bitcoin. Depositing bitcoin to trade a dollar-denominated account means taking a currency view on the way in, which most clients do not want. That is why stablecoin deposits took the volume.
Lightning earns its place in three narrower cases. Small recurring payments where card fees dominate, such as a low-priced subscription. Payouts to recipients in markets where card and bank rails are unreliable and the recipient already runs a Lightning wallet. And products sold to a bitcoin-native audience, where offering it is a signal as much as a rail. Outside those, adding Lightning to a checkout that already carries cards and stablecoins adds an option almost nobody selects.
A Lightning payment is a bitcoin payment. The amount received is denominated in bitcoin and its fiat value moves, so a business quoting in fiat needs conversion at receipt exactly as it would for any other coin. Speed does not remove price exposure.
Invoices, expiry and refunds
A Lightning invoice encodes an amount and a payment hash and carries an expiry, commonly minutes rather than hours. That expiry is short by design and it interacts badly with the way people pay invoices, so any checkout using Lightning needs an obvious regenerate action rather than an error page. Amountless invoices exist and are convenient for donations, but for a business they remove the amount check, which is a reconciliation problem you do not want.
Refunds are the sharper operational issue. There is no reversal on a Lightning payment, so a refund is a new payment in the opposite direction, and it requires the customer to supply an invoice. That is the same constraint as any chain payment and it means the refund flow has to be built rather than assumed, which is covered generally in refund handling. The upside is the other side of the same coin: there are no chargebacks, which for firms in high-risk categories is a real commercial argument.
What would change the picture
Reach is the limiting factor, and reach is a wallet question. Lightning support in the wallets and exchanges most retail users hold has grown, but it is still far from universal, and a payment rail that a client cannot use is not a rail. Firms evaluating it should check the practical number rather than the ecosystem narrative: of clients who deposit in crypto today, how many hold bitcoin at all, and how many hold it somewhere that can send over Lightning.
For most brokers and prop firms the answer today points at keeping stablecoin rails as the crypto default, comparing them against the alternatives in payout rails, and revisiting Lightning when the wallet question changes. Adding it early costs little if a processor already supports it. Building it in-house for a client base that will not use it is effort spent on the wrong problem.
"Lightning is genuinely fast and genuinely cheap. The question a firm has to answer is what share of its clients can actually send one, and for most firms that number is small."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Lightning settles bitcoin payments in seconds at very low fees by routing them through funded channels instead of the base chain.
- Receiving requires inbound channel capacity, which is an ongoing liquidity task for a self-hosted node and the main reason firms choose custodial providers.
- Client demand for crypto deposits is dominated by dollar-pegged tokens, so Lightning fits narrow cases rather than general checkout.
- There are no chargebacks and no reversals, so refunds have to be built as new outbound payments against an invoice the customer supplies.
Frequently Asked Questions
Is a Lightning payment final?
Once settled it is final and cannot be reversed by the sender or the network. A refund is a separate payment in the other direction, which needs an invoice from the recipient.
Why can a Lightning payment fail even when the sender has funds?
Routing. The payment needs a path of channels with capacity in the right direction between sender and receiver, and if no such path is found the payment fails rather than partially settling.
Does accepting Lightning avoid the exchange rate problem?
No. The amount received is bitcoin, so the fiat value moves the same way. Businesses quoting in fiat still need conversion at receipt or a processor that settles to them in fiat.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.