#CLINK plugin for #BTCpayServer finally approved and listed in the plugin directory 🥳
Thank you @BTCPay Server team for your relentless feedback, I’ve learned so much more in the past two months 🙏
https://stacker.news/items/1559179/r/06bc1a977d
Woompa Loompa
06bc1a977d@stacker.news
npub1q67p...wh0q
just learning
New LNbits extension: #CLINK: Recurring #Lightning Payments, #Subscriptions Auto-Renew & Funding Source for #LNbits.
Nostr-native Lightning for LNbits: publish a `noffer1...` and get paid over Nostr, pay other offers, and run **subscriptions with Lightning auto-renew** via CLINK debits. No Lightning.Pub required. A list of CLINK-aware apps is available at `clinkme.dev/apps.html`
- Offers (receive), Pay Offers (send)
- Subscriptions auto-renewal (day/week/month plans)
- Wallet debits with per-period budgets & rules
- CLINK (e.g. Lightning.pub) as funding source
Announcement: https://stacker.news/items/1543884/r/06bc1a977d
Demo:
Repo: 
GPL-3.0, PRs, issues and any feedback welcome!
#bitcoin #nostr #asknostr
CLINK LNbits
GitHub
GitHub - WoompaLoompa/lnbits-clink: Bitcoin Lightning Payment Gateway, Subscriptions Auto-Renew & Funding Source for LNbits (via CLINK)
Bitcoin Lightning Payment Gateway, Subscriptions Auto-Renew & Funding Source for LNbits (via CLINK) - WoompaLoompa/lnbits-clink
# v1.0.9 — Security Hardening (BOLT11 validation + guest-order authorization)
### Summary
This release closes three security gaps identified in a plugin review: invoices were accepted without being validated against the order's network/amount/expiry, guest orders had no ownership check on the payment AJAX handlers, and `save_ndebit` trusted a client-supplied subscription ID.
Download and install from:
- GitHub 
- Wordpress
### Security fixes
- **Strict BOLT11 invoice validation** — the invoice is parsed server-side (bech32 checksum, HRP network, amount, expiry) before payment is confirmed. Invoices that are invalid, on the wrong network, for an amount that doesn't match the order total (within 1 sat), or that expire in under 60 seconds are rejected in the checkout UI.
- **Guest order-key authorization** — all four payment AJAX handlers (`check_payment`, `confirm_payment`, `mark_paid`, `save_ndebit`) now require the matching order key for guest orders; logged-in users must match the order's customer ID. Previously guests could confirm/mark any order.
- **Server-side subscription binding** — `save_ndebit` no longer accepts a client-supplied `subscription_id`; subscription IDs are derived server-side from the verified order.
### New
- **Network setting** (`mainnet` / `testnet` / `regtest`) added to the gateway configuration; invoices from a different network are rejected.
- Parsed invoice amount is recorded as `_clink_invoice_amount_sats` order meta.
### Install / Update
1. Upload/install `clink-gateway-for-woocommerce.zip` (attached) or update from the WordPress.org plugin page.
2. WordPress 5.8+ / WooCommerce 3.0+ / PHP 7.4+ (tested up to WP 7.0.2).
3. If you're on testnet or regtest, set **Bitcoin Network** in **WooCommerce → Settings → Payments → Lightning (CLINK)** so invoices are validated against the right chain.
GitHub
Release WooCLINK v1.0.9 · WoompaLoompa/woo-clink
v1.0.9 — Security Hardening (BOLT11 validation + guest-order authorization)
Summary
This release closes three security gaps identified in a plugi...
Bitcoin Lightning Payment Gateway for WooCommerce (via CLINK) – WordPress plugin | WordPress.org
# v1.0.2 update released in GH and npm
### Security Hardening
- BOLT11 invoice validation: mainnet bc prefix, amount match, reasonable expiry; payment_hash extracted and stored on the session
- Webhook HMAC-SHA256 signature verification via CLINK_WEBHOOK_SECRET env var or webhookSecret option
- Webhook correlation: session existence, amount, and payment_hash matched before confirming; idempotent handling
- SSRF protection: relay URLs restricted to wss://, rejecting localhost/.local, private/loopback/CGNAT/link-local IPs, and unsafe IPv6 ranges
- nDebit validation: decode and validate debit pointers (type, pubkey, relay); requires safe relay and valid merchantPubkey
- k1 correlation key on debit requests (<subscription_id>:<count>)
### Added
- webhookSecret and merchantPubkey configuration options
- payment_hash on payment sessions; debit_pubkey/debit_relay on subscription data
- bolt11 and nostr-tools dependencies
- Expanded test suite (130 tests, 5 suites) with coverage thresholds met
npm: https://www.npmjs.com/package/medusa-plugin-bitcoin-lightning-via-clink
GitHub: 
.
GitHub
GitHub - WoompaLoompa/medusa-clink: Bitcoin Lightning payment module for Medusa.js via CLINK
Bitcoin Lightning payment module for Medusa.js via CLINK - WoompaLoompa/medusa-clink
# vendure-plugin-bitcoin-lightning-via-clink v0.3.0 released
Bitcoin Lightning payments for Vendure via the CLINK protocol (Nostr-native payment codes). npm: https://www.npmjs.com/package/vendure-plugin-bitcoin-lightning-via-clink | GitHub: 
### What's new in v0.3.0
- Rewritten BOLT11 decoder — the previous implementation returned null/0 for payment hash and timestamp on valid invoices; now uses proper bech32 HRP/separator parsing and is verified against the official BOLT11 test vector
- Invoice network validation — new network option (mainnet/testnet/regtest, default mainnet); invoices from a different network are rejected on both webhook and relay paths
- Invoice expiry validation — already-expired invoices are refused
- SSRF protection for relay URLs — localhost, private/loopback/link-local addresses and non-wss schemes are rejected (applied to subscribe, publish, key generation, payment handler)
- Relay settlement now requires proof — preimage + bolt11 must be supplied and the payment hash verified; res:"ok" without proof is refused
- Atomic offer transitions — settlement/expiry only applies from pending state
- Event kind 21001 + p-tag correlation checks on relay receipts
- Testing: 66 unit tests passing (incl. the official BOLT11 test vector and SSRF relay filtering cases).
I have no production store behind this, it's a solo effort validated by unit tests. If you try it in a real shop, feedback and issues are very welcome:
#buildstr #bitcoin #lightning #commerce #vendure #nostr #clink
GitHub
GitHub - WoompaLoompa/vendure-clink: Bitcoin Lightning payments for Vendure via the CLINK protocol (Nostr-native static payment codes)
Bitcoin Lightning payments for Vendure via the CLINK protocol (Nostr-native static payment codes) - WoompaLoompa/vendure-clink
GitHub
Issues · WoompaLoompa/vendure-clink
Bitcoin Lightning payments for Vendure via the CLINK protocol (Nostr-native static payment codes) - Issues · WoompaLoompa/vendure-clink