We added Lightning Network as a payment option for ASH services in early 2023. The motivation was straightforward: Bitcoin on-chain payments take 10-60 minutes to confirm, which is operationally awkward for customer service activation. Lightning offers instant settlement at minimal fees.

After a full year of Lightning in production, the operational characteristics are clearer than they were at the start. Customer adoption has been meaningful. The operational complexity is bounded but real. The case for Lightning continues to make sense for our specific use case.

This post documents what we built, what the customer adoption looks like, what the operational reality is, and what we learned about running a Lightning node for hosting invoice payments.

Why we added Lightning

The customer experience friction with Bitcoin on-chain payments was real.

The confirmation timeline problem

Bitcoin on-chain payments produce blockchain transactions that confirm over 10-60 minutes typically. The first confirmation arrives in approximately 10 minutes. Subsequent confirmations arrive every 10 minutes on average.

For our service activation:

1 confirmation required for small amounts (under €50): ~10 minutes wait
3 confirmations for medium amounts (€50-500): ~30 minutes wait
6+ confirmations for large amounts: 60+ minutes wait

The wait times were causing customer frustration. Customers paid, then waited, then sometimes thought the payment failed and contacted support.

The fee problem

Bitcoin on-chain transactions include network fees. The fees vary by network congestion but typically €1-€8 per transaction. For small payments (€20-€50 services), the fees represent meaningful percentage cost.

Lightning fees are typically fractions of a cent. The fee structure is much better for small payments.

The capacity scaling

As our customer base grew, the number of Bitcoin transactions per day grew. Each transaction required on-chain space. Lightning offloads many transactions from on-chain to layer 2, which is more scalable.

What Lightning Network is

For readers less familiar with the technology:

Lightning Network is a layer-2 protocol built on top of Bitcoin. It enables payments between parties through payment channels that hold balances. Payments through the network move balances through chains of channels rather than recording each payment on the Bitcoin blockchain.

The technical implementation involves cryptographic constructions that ensure security without requiring trust between intermediate parties. Payments are atomic across the chain (either complete fully or fail fully).

The benefits:

Instant payment confirmation (seconds rather than minutes)
Minimal fees (fractions of a cent typically)
Scalability through off-chain transactions
Privacy improvements (less on-chain visibility)

The trade-offs:

Requires running a Lightning node alongside Bitcoin
Channel management complexity
Liquidity considerations
More operational moving parts

What we deployed

Our Lightning infrastructure:

LND (Lightning Network Daemon)

We chose LND as our Lightning implementation. Other implementations exist (Core Lightning, Eclair) but LND has the broadest ecosystem and tooling.

LND runs alongside our Bitcoin Core node on the same dedicated server.

Channel topology

We opened channels with several well-connected Lightning nodes to provide routing capability for our outbound payments. Initial channel count: 12. Current channel count: approximately 30 after a year of growth.

Channel sizes range from 1M satoshis (about €450) to 10M satoshis (about €4,500). The mix provides flexibility for various payment sizes.

BTCPay Server integration

Lightning is integrated through BTCPay Server’s native LND support. The integration is bounded; BTCPay handles invoice generation and payment monitoring transparently.

Customers see Lightning payment options on the BTCPay checkout pages. The integration is invisible from the customer perspective.

Inbound liquidity

Inbound liquidity (capacity to receive Lightning payments) requires explicit management. We have purchased inbound liquidity from liquidity providers periodically to maintain capacity for customer payments.

Inbound liquidity costs vary but typically 0.1-0.5% of the channel capacity for one-year capacity.

Customer adoption patterns

Over the first year, customer adoption of Lightning has been meaningful.

Adoption rate over time

Month 1 (after launch): 8% of cryptocurrency payments through Lightning. Month 3: 22% of cryptocurrency payments through Lightning. Month 6: 38% of cryptocurrency payments through Lightning. Month 12: 51% of cryptocurrency payments through Lightning.

The adoption rate continues growing slowly. We expect it to plateau around 60-70% as users with strong on-chain preferences continue using on-chain.

Customer profile differences

Customers paying through Lightning differ from customers paying on-chain:

Lightning customers tend to be more technically sophisticated. They have Lightning wallets configured. They understand the operational differences.

Lightning customers tend to pay smaller amounts on average. The fee structure favors smaller payments. Larger payments still often go on-chain for various reasons.

Lightning customers tend to be more privacy-aligned. The on-chain visibility differences matter to them.

Lightning customers tend to be repeat customers more often. The Lightning workflow is faster for repeat purchases.

Payment size distribution

Lightning payments cluster in specific ranges:

Under €20: 35% of Lightning payments
€20-€50: 30% of Lightning payments
€50-€200: 25% of Lightning payments
€200-€500: 8% of Lightning payments
Over €500: 2% of Lightning payments

On-chain payments have different distribution, weighted toward larger amounts:

Under €20: 5% of on-chain payments
€20-€50: 20% of on-chain payments
€50-€200: 35% of on-chain payments
€200-€500: 25% of on-chain payments
Over €500: 15% of on-chain payments

The payment size correlation with method is consistent with what we expected based on fee differences.

Geographic distribution

Lightning customers come from various geographies. European customers slightly over-represented relative to overall customer base. Latin American customers under-represented (Lightning adoption is lower in these regions still).

The distribution reflects general Lightning adoption rather than our specific customer dynamics.

Operational characteristics

After a year of production operation:

Reliability

Lightning payment success rate: approximately 98-99%. The 1-2% failures are typically:

Customer wallet issues (insufficient balance, channel problems on customer side)
Routing failures (no route between customer and our node)
Liquidity issues (channels insufficient for the specific payment amount)

The failure rate is acceptable. Failed payments are visible immediately (unlike on-chain where confirmation delay produces ambiguity).

Node uptime

Our LND node uptime over the year: approximately 99.7%. The downtime breakdown:

Planned maintenance: approximately 8 hours total
Bitcoin node sync issues: approximately 6 hours
LND-specific issues: approximately 10 hours
Network/hosting issues: approximately 4 hours

Total approximately 28 hours of degraded operation across the year. Most degradation was brief and bounded.

Channel management work

Channel management has been more operational work than expected. Specific activities:

Initial channel opening: bounded work over the first few weeks
Channel balancing: periodic activity to maintain bidirectional capacity
Channel closure: occasional when channels are no longer useful
New channel opening: as the network evolves and we identify good peer nodes

The cumulative channel management time: approximately 4-6 hours per month average.

Routing income

We have earned routing fees from being an intermediary for payments routing through our channels. The income is modest but covers a portion of our Lightning operational costs.

Routing income over the year: approximately €420. The income partially offsets the cost of inbound liquidity purchases.

Backup and recovery

Lightning node backup has been more complex than expected. The Static Channel Backup (SCB) provides emergency recovery capability but with caveats. The backup discipline:

SCB files backed up daily
Backups stored in multiple locations
Periodic verification of backup integrity
Documented recovery procedures

We have not needed to use the recovery procedures (no catastrophic node failure). The backup discipline is precaution that we hope continues being unnecessary.

Security considerations

Lightning has specific security considerations:

Hot wallet pattern. Lightning channels require online keys, which means hot wallet exposure. We mitigate through limiting channel capacity (channels are bounded by their funding amount).

Watchtower setup. Watchtowers monitor for channel breach attempts when the node is offline. We have basic watchtower setup though have not needed it.

Channel monitoring. Active monitoring for unusual channel activity. The monitoring is part of our broader operational practice.

The Lightning-specific security work is bounded but real. The hot wallet exposure is the most significant concern.

What worked better than expected

Several aspects exceeded our expectations.

Customer experience

The instant payment confirmation has been a significant customer experience improvement. The faster service activation produces better customer satisfaction.

Customer support questions related to “where is my payment” have decreased substantially since adding Lightning. Customers using Lightning see immediate confirmation.

Integration complexity

BTCPay’s Lightning integration is mature. Adding Lightning as a payment option required minimal integration work beyond the underlying Lightning node setup.

The integration just worked once the node was operational.

Fee predictability

Lightning fees have been very stable and very low. The fee predictability is operationally favorable.

Reliability over time

The reliability has been better than our initial concerns suggested. The maturity of the Lightning ecosystem produced fewer operational issues than we anticipated.

What was harder than expected

Some aspects required more attention than we initially planned.

Channel management complexity

Channel management is operationally more demanding than we expected. Balancing channels, opening new channels, closing inefficient channels, monitoring channel health all require ongoing attention.

The work is bounded but does not disappear. Plan for it explicitly.

Inbound liquidity costs

Inbound liquidity costs add up. The periodic purchases of inbound capacity from liquidity providers represent meaningful ongoing cost.

For high-volume operations, the cost is justified. For smaller operations, the cost may not be.

Lightning wallet ecosystem variability

Customer Lightning wallets vary significantly in quality. Some wallets work flawlessly with our setup. Others have issues with specific payment patterns.

The variability affects payment success rate. We cannot control customer wallet choice but have to handle the variability.

Smaller node coverage

Some Lightning routes through smaller nodes have higher failure rates. The Lightning network is not yet at a maturity level where all routes work consistently.

The failure rate during routing produces some payment attempts that fail. Customers retry; payments eventually succeed. The friction is bounded but real.

What we have learned

Specific operational insights from the year:

Lightning is not a Bitcoin replacement

Lightning complements on-chain Bitcoin rather than replacing it. Different payment scenarios fit different methods.

For our use case, on-chain handles larger payments and recurring patterns; Lightning handles smaller payments and one-time purchases. The combination serves different customer needs.

Channel topology matters

The selection of channel peers significantly affects routing success and routing income. Some peers are well-connected; others are less so. The topology decisions accumulate value or accumulate friction.

Liquidity is operational concern

Inbound and outbound liquidity both require management. Operations using Lightning at meaningful scale need explicit liquidity strategies.

For very small operations, liquidity is not a major concern. For our scale (modest but real), it requires attention.

Backup discipline matters

The backup discipline for Lightning is more critical than for Bitcoin on-chain. Channel state changes frequently; backup currency matters.

Customer education varies

Customers vary in their Lightning understanding. Some customers are sophisticated; some are not. The customer-facing documentation needs to serve both.

We have invested in customer documentation about Lightning. The documentation reduces support load.

For operators considering adding Lightning Network for customer payments:

Honest assessment of fit

Lightning is most valuable for operations with:

Frequent small payments (under €100)
Customer base with Lightning-friendly profiles
Operational capability to manage the additional infrastructure
Strategic alignment with cryptocurrency operations

Operations without these characteristics may not benefit from Lightning.

BTCPay-based approach

For operations already running BTCPay Server, adding Lightning is bounded work. The BTCPay integration handles most complexity.

For operations not running BTCPay, the additional complexity of Lightning may not be worth the benefit compared to on-chain only.

Channel topology research

Before opening channels, research channel partners. Well-connected reliable nodes produce better routing outcomes than randomly-selected partners.

The research investment pays off in long-term Lightning operation.

Liquidity strategy

Plan for liquidity. Inbound liquidity from purchases or routing income. Outbound liquidity from channel funding. The liquidity should match expected payment patterns.

Operational time investment

Plan for ongoing operational time. The “set it and forget it” approach does not work well for Lightning.

Approximately 5-10 hours per month for moderate operations is realistic.

Monitoring infrastructure

Set up Lightning-specific monitoring. The standard infrastructure monitoring does not catch Lightning-specific issues.

Channel health, routing success, liquidity status all need explicit monitoring.

Documentation

Document Lightning-specific operational procedures. Channel management, backup recovery, incident response all need documented procedures.

What we expect over time

Looking forward at Lightning Network operations:

The Lightning Network ecosystem continues maturing. Better tools, better wallets, better routing produce sustained improvement in operational characteristics.

Customer adoption continues growing. As Lightning becomes more accessible to mainstream users, our Lightning adoption rate should continue growing.

Fee structures continue being favorable. Lightning fees remain dramatically lower than on-chain alternatives.

Integration improvements continue. BTCPay continues developing. Other tools continue improving. The barrier to Lightning operations continues lowering.

The customer experience improvements compound. As we accumulate operational experience, our Lightning operation becomes more reliable.

The broader payment landscape

Looking at how Lightning fits in our broader payment infrastructure:

On-chain Bitcoin: handles larger payments, payments where confirmation timing is not critical
Lightning Network: handles smaller payments, payments where instant confirmation matters
Monero: handles privacy-sensitive payments
Traditional payment methods (fiat, cards): for customers not using cryptocurrency
Atomic swaps for conversion between Bitcoin and Monero (covered in another post)

Each payment method serves specific customer preferences. The combination serves diverse customer needs.

The strategic positioning

Lightning Network operation aligns with our broader strategic positioning.

Self-hosted infrastructure including Lightning. We are not dependent on Lightning Service Providers for our customer-facing payments.

Direct settlement without intermediaries. The non-custodial pattern continues through Lightning.

Privacy-aligned (with caveats). Lightning provides certain privacy improvements over on-chain.

Cost-efficient. The Lightning fees are minimal compared to traditional payment processing.

Aligned with cryptocurrency-positioned brand. The Lightning capability reinforces our cryptocurrency-friendly positioning.

What we are not doing

Some Lightning capabilities we have not pursued:

Lightning service provider operation

We are not operating as a Lightning service provider for other operators. The complexity and operational requirements exceed our current focus.

Lightning-only operations

We continue offering on-chain Bitcoin alongside Lightning. Some customers prefer on-chain; we serve their preference.

Lightning swaps to other cryptocurrencies

We do not directly support Lightning to Monero swaps or similar conversions. Our atomic swap infrastructure handles BTC to XMR; Lightning capability for cross-currency swaps is a future possibility.

Channel-based marketing or partnerships

Some Lightning operations promote themselves through channel relationships. We have not pursued this approach. Our customer acquisition happens through other channels.

The honest summary

Lightning Network has been a successful addition to our payment infrastructure. The customer experience improvement is real. The operational complexity is bounded. The economics work for our specific use case.

For operators considering Lightning: the technology has matured to production-ready state. The operational requirements are bounded but real. The fit depends on specific operational characteristics.

For our customer base: Lightning continues serving customers well. The adoption continues growing. The operational reliability continues being acceptable.

For our team: the operational learning over the year has been valuable. The capability we have built supports our broader strategic positioning. The relationships built with customers preferring Lightning have been positive.

The year of Lightning in production has been net positive. The investment in setup and ongoing operations is justified by the benefits. The trajectory continues.

For other operators reading this with similar use cases: Lightning Network is worth considering. The work is bounded. The benefits accumulate. The customer experience improvements compound. The strategic alignment with cryptocurrency-positioned operations is real.

Lightning continues evolving. The tools continue improving. The ecosystem continues maturing. The operators who invest in Lightning capability now will benefit from ongoing improvements over coming years. The investment is durable.