
Why we support 5 different Lightning implementations, and how an external developer added Blink alongside the one we integrated ourselves?
I'm on the product side of be-BOP, an open source (AGPL-3.0) commerce platform covering e-commerce, POS, ticketing, subscriptions, donations, and peerfunding. Not a dev, so I'll stay at the product/philosophy level here.
We never wanted to pick a winner among Lightning implementations, and while we started with a local LND node, the more we thought about it, the more that felt like the wrong instinct for a payments feature. A merchant already running a full node doesn't have the same setup as one who's had BTCPay Server humming along for two years. Someone opening their first online shop might not want to run any node at all, and would rather have something closer to a custodial wallet like Swiss Bitcoin Pay just to get paid without thinking about channel liquidity. None of these people are wrong about what they want. They're just solving different problems, and every existing implementation makes different tradeoffs to solve them. Forcing all of them through one integration would have meant quietly telling some of our users their setup doesn't count.
So instead we treat "which Lightning implementation" as the merchant's call, not ours. Right now that's Swiss Bitcoin Pay, BTCPay Server, PhoenixD, LND and since today Blink. We were the first project to integrate PhoenixD. Here is a comparison:
| Implementation | Sovereignty | Difficulty | Liquidity Management | Fiat Conversion |
|---|---|---|---|---|
| BTCPay Server | Maximum | Technical | Manual 🔧 | No ❌ (or with plugins) |
| Phoenixd | Medium | Easy | Automatic ✅ | No ❌ |
| Swiss Bitcoin Pay | Medium | Easy | Automatic ✅ | Possible ✅ |
| LND Node | Maximum | Technical | Manual 🔧 | No ❌ |
| Blink | Low to Medium (custodial or non-custodial) | Easy | Automatic ✅ | Possible ✅ |
Like I said Blink got merged as a Lightning provider, and we didn't write the integration. An external contributor, pretyflaco, opened the PR. It went through our internal testing and code review like anything else, and got merged. I think that's the part worth sitting with more than the merge itself: this is what AGPL and Free and Open Source Software actually buys you. Someone whose merchants want custodial simplicity didn't have to wait for it to reach our roadmap. They read the code, saw where a new provider plugs in, and added the one they needed.
The project is self-hosted by default, or there's be-BOP Cloud if you'd rather not run your own instance. Either way, no commission on sales from us. Your PSP or your node keeps its own fees, that's not something we touch.
Repo's here if you want to look: github.com/be-BOP-io-SA/be-BOP
Curious what Lightning implementation you'd want to see in more projects but never see supported. What keeps getting left out?