Why we support 5 different Lightning implementations, and how an external developer added Blink alongside the one we integrated ourselves?

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?

u/be-BOP_community — 1 day ago
▲ 7 r/POS

Our POS is open source (AGPL) has no sales commission and no hardware lock-in. Two Swiss businesses have been running it for over a year, wanted to share how.

I'm part of the small team that builds be-BOP, so take this as "here's what our users are actually doing with it" rather than a neutral review.

Some history

The whole thing started almost by accident. A small French-Swiss publishing house (PVH éditions) with a strong love for Free Software, Open Source and let's be honest Copyleft needed to sell books at fairs and online without the usual mess: plugin ecosystems that break on every update (hi WordPress/PrestaShop), crowdfunding platforms that take a significant cut with little discovery to counter it and that can freeze your campaign mid-way, no good or native Bitcoin support anywhere (they are really into Free Software). So they built their own checkout. Then it needed inventory. Then a POS mode for the fair booth. Then ticketing, subscriptions, donations, peerfunding. At some point the POS got bigger as we got money to improve it and bring more features tailored for bars and restaurants. It changed so much that we quickly stopped calling it "La bookinerie" (the bookshop tool) and it turned into a bigger open source project, AGPL-3.0, code's public on GitHub. You can self-host it or run it on our Cloud for a flat monthly fee (in a few jurisdiction for now), we don't take a cut of your sales either way. Whatever payment processor you pick still charges its own fees though, that part's out of our hands. Also as it's a WebApp, there is no hardware required beside: screen, web browser, internet connection.

Real world stories

Le Coffice, a café in Neuchâtel on the ground floor of a coworking space, has self-hosted for over a year now and paid us for a bit of custom dev along the way. Owner's happy, their accountant's very happy, which might honestly be the best review we've gotten. The bar owner is also fairly happy with the solution but let's be honest we still have to improve a few things to be really competitive feature-wise and UX-wise to the giants such as lightspeed. But they are making good feedback to us and we have improvements planned, for now ressources are more towards the legal aspect for France and UE for our SaaS and the online e-commerces feature set.

Their payment setup is a decent showcase of the "no single built-in gateway" approach: cards through SumUp (we also currently support stripe, PayPal and PayZen by OSB), Bitcoin Lightning Network through Swiss Bitcoin Pay (we also support other solution for LN and BTC), they also even set up GNU Taler. For cash (still fairly popular in Switzerland) and Twint (a popular swiss mobile payment app, kind of like our local Venmo) they use be-BOP's own "PoS Payment Subtypes" feature, which lets you define more or less unlimited manual payment methods (asynchronous confirmation) that each show up distinctly in the accounting instead of piling into one "other" bucket, cash being a default option. Coworker members get 20% off soft drinks through the discount feature.

Their is also board game bar and restaurant that made extensive tests and reviews of our early versions. They uses something I didn't expect to matter this much: instead of tracking only tables, they also needed track cups. That's because people can mix between tables and just change groups frequently over their stays. A group's order pools onto one running tab, and at the end the waiter can splits it however the table actually wants, by share, by item, or just closes it as one ticket. Waiters can also if needed transfer products from a pool to another (before any payments being initialised).

Actual limitations

Where we're honestly still behind: the French self-certification requirements for POS anti-fraud rules aren't done yet, so it's not available for VAT businesses in that country. And on the POS side for our Cloud customers we don't want to promote it by default to avoid our support ressources being monopolised, we focus on e-commerce for the moment and we are looking into partnership to have POS support and cloud service more official let's say. We'll make exceptions case by case but we're not pretending that our Cloud Services are for PoS users yet.

Looking to learn more about be-BOP?

What we want out of this post: more businesses willing to run it (self-hosting), contributors submitting PR or correcting translation, software engineer breaking it, and business telling us what's missing for them to adopt it.

It's AGPL, the code's right there to read or fork: https://github.com/be-BOP-io-SA/be-BOP. There's also a 2-hour sandbox if you want to poke at it without signing up for anything: https://sandbox.be-bop.dev/product/be-bop-sandbox-2h

Happy to get into the stack, the payment-methods architecture, or why we went AGPL instead of something more permissive. If you have any other questions feel free to ask!

be-BOP's POS feature list
There is more of course but here is a digest glimpse of our solution

Selling & the touch screen

  • Tap-to-add product grid with photos and live prices
  • Favorites shortcut and custom categories, built from your own product tags
  • Per-item notes ("no onions", "gift wrap") that carry through to the kitchen ticket and receipt
  • Same interface on a full-size terminal or a small tablet, responsive design for mobile UX too

Restaurant & bar service

  • Unlimited open tabs, tables, bar tabs, takeaway. Running at once, grouped and named by area
  • Move or merge items between tables: split a group, combine tables, shift a round
  • Kitchen tickets auto-routed by station (kitchen vs. bar, based on your Tags)
  • Reprint-safe: send only newly added items, so nothing already fired gets remade
  • Tables clear themselves once fully paid

Payments & splitting the bill

  • Cash (with a change-due calculator), integrated card terminals (Stripe/SumUp), PayPal, GNU Taler, Bitcoin/Lightning every method is optional
  • Add your own payment types for anything else accepted locally
  • Split a bill evenly (2–9 ways, or custom) or by specific item
  • Each split portion can be paid a different way, with a live running balance
  • One consolidated receipt once the whole bill is settled

Cash drawer & shift management

  • Opening float suggested from the previous shift's closing balance
  • Guided close-out: count the till, see any discrepancy instantly, log a reason if there's a gap
  • Closing is blocked while any table still has an unpaid balance
  • Read-only sales snapshot mid-shift (X-ticket) any time, full end-of-day report (Z-ticket) on close
  • Every past shift logged and searchable: amounts, staff, duration

Tax, discounts & receipts

  • VAT calculated and itemized by rate automatically, with support for multiple regimes
  • Reduced VAT rates settable per product
  • Register-level discounts always paired with a logged reason
  • Itemized receipts (or a full invoice) with VAT breakdown, emailable to the customer

Behind the scenes

  • One catalog powers your online store and every register, no duplicate entry
  • Per-product control over what sells online vs. in-store vs. elsewhere
  • Real-time stock shared across every channel
  • Cashier accounts scoped to just the register; granular permissions for every other role
  • Built-in sales/payment reporting with CSV export, 150+ currencies, 7 interface languages
reddit.com
u/be-BOP_community — 2 days ago

Pourquoi on supporte plusieurs implémentations des réseaux Bitcoin et Lightning plutôt qu'une seule, sur notre plateforme e-commerce et logiciel de caisse open source

Je fais partie de l'équipe be-BOP, une solution polyvalente pour la e-commerce et les magasins physique avec un large panel de fonctionnalités (PoS, billetterie, abonnements, dons et financement participatif) publié en open source sous licence AGPL-3.0. Je suis côté produit, pas dev, je le précise tout de suite.

On supporte nativement le Bitcoin depuis le début, en on-chain et en Lightning, à égalité avec les moyens de paiement fiat plus classiques. On a commencé avec uniquement le support par noeud complet Core et LND pour les paiements en Bitcoin (optionnel comme toutes les méthodes sur notre solution).

Côté Lightning on ne s'est jamais dit qu'il fallait choisir une seule implémentation à la place de nos utilisateurs. Un bitcoiner qui fait tourner un full node n'a pas les mêmes besoins que quelqu'un qui a déjà son BTCPay Server, ou que quelqu'un qui ne veut ni l'un ni l'autre et cherche juste quelque chose de simple. Au fil des mise à jours nous avons étoffé un large choix d'implémentations. Les solutions existantes ont toutes des compromis différents, donc on en supporte plusieurs : Swiss Bitcoin Pay, BTCPay Server, phoenixd et LND. On a été les premiers à intégrer phoenixd, je suis curieux de savoir si certains ici l'utilisent en prod pour du commerce, tous les retours sont bons à prendre.

Une cinquième, Blink, est en route : une PR externe qui a passé nos tests internes et attend sa review de code. Pas encore mergée, mais un bon exemple de ce que permet une licence AGPL avec des contributeurs qui ne sont pas dans l'équipe.

Le projet existe en auto-hébergeable (code public, tu héberges toi-même) sur une petite machine (VPS ou bare-metal) Ubuntu ou Debian, le guide d'installation sur notre site vous dit ce qui est requis, et en SaaS be-BOP Cloud (hébergé par nous en Europe, essai gratuit de 7 jours puis abonnement à tarif fixe). Dans les deux cas, aucune commission sur les ventes de notre côté. Les PSP ou ton nœud Lightning gardent leurs propres frais, ça reste hors de notre contrôle.

Une limite honnête à mentionner : côté France, les fonctionnalités de caisse physique ne sont pas encore disponibles pour les commerces assujettis à la TVA, en attendant l'auto-certification requise, prévue plus tard cette année. Les structures non assujetties, associations notamment, peuvent déjà les utiliser sans restriction. Pour le service Cloud, il n'est pas encore disponible pour la France car nous devons assurer pleins d'aspect légaux pour ce marché, nous devrions être prêt d'ici un mois ou deux maximum et phoenixd ne sera pas disponible aussi pour des raisons légales (disponible uniquement si hébergé par vous).

be-BOP est né chez PVH éditions, une maison d'édition franco-suisse qui voulait le Bitcoin et le Lightning à la fois pour la vente de livres en ligne et pour le financement participatif.

Leur première campagne de peerfunding (la toute première aussi pour be-BOP) a plutôt bien marché : grossièrement un quart des paiements en on-chain, un quart en Lightning, le reste réparti entre carte et PayPal. Tout ça atterrit dans la même comptabilité, avec ce qu'il faut pour un comptable, et l'affichage peut se faire en une ou deux devises à la fois, sats ou bitcoin inclus. PVH a même une collection de livres sur le Bitcoin en français si ça vous intéresse : pvh-editions.com/bitcoin

Le dépôt GitHub est encore petit, moins de 200 étoiles. https://github.com/be-BOP-io-SA/be-BOP si vous voulez fouiller le code, lire des Issues ou en rédiger.

Nous avons aussi mis en place un bac à sable éphémères sans inscription si vous voulez juste tester : sandbox.be-bop.dev/product/be-bop-sandbox-2h

reddit.com
u/be-BOP_community — 7 days ago
▲ 1 r/FrenchPolynesia+1 crossposts

be-BOP Cloud arrive en Polynésie française : e-commerce avec paiements locaux, XPF natif, zéro commission

Je fais partie de l'équipe be-BOP (boîte suisse), donc oui ce post est intéressé, autant le dire tout de suite.

Vendre en ligne en Polynésie française reste compliqué côté paiement : Shopify Payments n'est toujours pas disponible ici, et Wix devient vite cher surtout dès qu'on sort des fonctionnalités de base. Rien de nouveau pour beaucoup d'entre vous, je présume.

On n'a pas construit be-BOP en pensant au Fuena à la base. C'est un logiciel e-commerce et de caisse open source et libre (AGPL-3.0), né en Suisse, pensé pour ne pas dépendre d'un seul gros acteur. Mais cette architecture-là (self-hostable, résiliente, sans lock-in) colle plutôt bien aux problèmes qu'on voit ici, et ça s'est concrétisé avec du concret et de formidable rencontres: avec DinoVox à la dernière édition du Polynesian Islands Crypto Summit (PICS2) en mai, intégration native avec OSB, XPF géré nativement avec un double affichage (par example XPF/EUR) pour la clientèle touristique. Il paraît que notre stand n'a pas désempli pendant les 3 jours du salon, ce qui en dit long sur l'attente côté commerçants locaux.

Côté fonctionnalités, le logiciel gère la vente en ligne et la caisse physique avec le même système : même inventaire, même admin, que vous vendiez sur un site ou sur un marché ou un salon. Il y a aussi de la billetterie et des abonnements intégrés nativement, utile si vous organisez un événement à côté de la vente. Côté paiement, OSB n'est pas la seule option : Stripe, PayPal, SumUp, virement bancaire et espèces sont dispo aussi, donc pas besoin de tout changer si vous avez déjà un compte ailleurs. Et côté client, pas besoin de créer un compte pour commander, un simple lien magique par email suffit.

Concrètement côté tarif : 7 jours d'essai gratuit, tarif de lancement à 1.999 XPF/mois pendant les 6 premiers mois (2.499 XPF ensuite), et zéro commission sur vos ventes, seuls les frais du prestataire de paiement s'appliquent comme partout. Le logiciel reste open source si vous préférez l'héberger vous-même, mais pour la plupart des commerçants le Cloud reste plus simple.

Je ne suis pas sur place, donc si quelque chose ne colle pas avec la réalité du terrain, ou s'il manque un truc évident, dites-le en commentaire, ça nous sert directement.

https://pf.be-bop.io

Vous pouvez aussi vous tourner vers l'équipe de DinoVox pour plus de proximité.

reddit.com
u/be-BOP_community — 2 days ago