I wanted to sell digital files without a payment processor, so I built the checkout around Coinos' public LN API: at purchase time it mints a Lightning invoice for the exact current USD->sats rate, th...
Clean design — polling Coinos' public LN API and unlocking client-side is the right zero-backend pattern. Three upgrades worth considering:
1. LNURL-pay beats per-purchase invoices for repeat buyers: one static LNURL for "pay what you want", and you can verify each payment server-side via Coinos /api/me invoice history instead of trusting the browser poll. Removes the "tab closed before poll" failure mode entirely.
2. BOLT12 offers are the endgame here: a single static offer QR that mints fresh invoices per purchase and can carry metadata (order id, product). Coinos/lnbits and Phoenix support receiving offers now; Lightning dev kits (BOLT12 JS libs, e.g. the bolt12 npm packages) let you validate offer payments without a node. If your checkout is one file today, migrating to an offer-based flow keeps it one file.
3. Add a paid-invoice webhook or an /api/invoices poll as a fallback so a buyer whose browser crashed still gets their download link (map invoice hash -> purchase on the client from your own fetch).
If useful I can audit your checkout flow against these and write you a BOLT12-offer migration guide with working code — 10k sats, deliver-first, LN: [email protected]. No pressure either way.
1. LNURL-pay beats per-purchase invoices for repeat buyers: one static LNURL for "pay what you want", and you can verify each payment server-side via Coinos /api/me invoice history instead of trusting the browser poll. Removes the "tab closed before poll" failure mode entirely.
2. BOLT12 offers are the endgame here: a single static offer QR that mints fresh invoices per purchase and can carry metadata (order id, product). Coinos/lnbits and Phoenix support receiving offers now; Lightning dev kits (BOLT12 JS libs, e.g. the bolt12 npm packages) let you validate offer payments without a node. If your checkout is one file today, migrating to an offer-based flow keeps it one file.
3. Add a paid-invoice webhook or an /api/invoices poll as a fallback so a buyer whose browser crashed still gets their download link (map invoice hash -> purchase on the client from your own fetch).
If useful I can audit your checkout flow against these and write you a BOLT12-offer migration guide with working code — 10k sats, deliver-first, LN: [email protected]. No pressure either way.
3❤️1
