be-BOP now has CLINK as a built-in payment option. This means your be-BOP shop can now accept Lightning payments from any wallet and transmit them as Nostr-native payments from CLINK-compatible wallets like ShockWallet.app and ZEUS wallet.
How it works for customers:
- Scan the bolt11 QR with any Lightning wallet → pay directly
- Scan the merchant's nOffer with a CLINK wallet → receive the same bolt11 via Nostr relay → pay
- Payment is confirmed automatically when Lightning.Pub sends a receipt
How it works for merchants:
- Add your nOffer string and relay URL in Admin > CLINK
- Set CLINK as your default Lightning processor
- Everything else is handled — bolt11 creation, receipt monitoring, order confirmation
What makes this different:
CLINK is a transport layer, not a Lightning backend. Your existing setup (Blink, LND, Phoenixd, etc.) handles settlement. No new accounts, no new infrastructure — just a Nostr-based way for wallets to discover your invoices.
The implementation was reviewed against other CLINK implementations to include relay SSRF protection, BOLT11 validation, and MongoDB session persistence.
Links:
- PR to be-BOP repo: https://github.com/be-BOP-io-SA/be-BOP/pull/2732
- CLINK config: https://github.com/WoompaLoompa/be-BOP/blob/main/docs/en/clink-configuration.md
- CLINK spec: https://github.com/shocknet/CLINK
Feedback welcome, especially from merchants who want to try this in production.
What interests me most here is that the
nofferbecomes a long-lived payment endpoint rather than just another way to encode an invoice.Since it contains the service pubkey, relay hint and offer identifier, how do you handle rotation in practice? If a merchant needs to change the service key or relay, can an already distributed
nofferkeep working, or does the merchant need to redistribute a new one?That seems especially important for physical QR codes or links that may stay in circulation for a long time.
deleted by author
Offer can contain multiple relays, so you can have redundancy on those in case a relay dies.
Key, pointer, and relays are encoded in the string, so if any changes it's a new string/QR... Old one will work if it's just an update to the array of relays and the old contains a working one
Best to think of them like a URL with parameters
If a pointer or key changes you can still listen for the old one and respond with a 403-like error code to direct clients to the updated one
That URL-with-parameters analogy makes it much clearer.
Multiple relays solve the redundancy concern nicely, and keeping the old endpoint alive long enough to redirect clients when the key or pointer changes seems like a practical migration path.
I was initially thinking of the nOffer more like a permanent payment address, but it makes more sense to think of it as a portable service endpoint with an explicit lifecycle.
Thanks, that answers exactly what I was trying to understand.
deleted by author