pull down to refresh

I built a managed L402 gateway add Lightning payments to any HTTP API in 10 mins
124 sats \ 3 comments \ @Squidboy30 17 Apr lightning

I've been building with L402 for a few months, and the biggest friction point is always the same: LND + Aperture is powerful but getting it running, keeping it running, and wiring it to a new API takes a full afternoon at minimum.

So I packaged it as a managed service. The core idea: you have an API. You want to charge per call in sats. You shouldn't need to run Lightning infrastructure to do that.

How it works technically:

The gateway runs LND + Aperture on Fly.io. When a request arrives, Aperture checks for a valid L402 token. If there's none, it generates a Lightning invoice and returns HTTP 402 with a WWW-Authenticate header. Client pays, retries with the preimage, Aperture proxies the request to your backend. Your API doesn't need to know Lightning exists.

Pricing: 2% of transaction volume, baked into the invoice price. Customer sets their price, we charge price × 1.02 rounded up. Billed monthly above 10,000 sats threshold.

Live demo (returns a real mainnet Lightning invoice):

curl -X POST https://parsebit-lnd.fly.dev/extract/webpage
-H "Content-Type: application/json"
-d '{"url":"https://example.com"}'

Registration and docs: crackedminds.co.uk/gateway

Also built on top of the same infrastructure: Boltwork — pay-per-call AI services (PDF summarisation, code review, translation, data extraction) all gated behind L402. parsebit.fly.dev

Happy to answer questions about the LND/Aperture setup or the L402 protocol.

write
compose
related posts
0 sats \ 1 reply \ @2daa00d2ba 17 Apr freebie

How are you handling invoice expiry and replay protection on the L402 tokens—especially for APIs with slower client retry cycles?

0 sats \ 0 replies \ @yultrace 18 Apr freebie

Nice build. I did the equivalent on the EVM side — an x402 (HTTP/1.1 402 Payment Required on USDC/Base) in front of a Slither-backed audit endpoint. Few observations from doing roughly the same thing on the other rail:

  1. Discovery is the bottleneck, not payments. Gateway UX is fine; the open question is "who even finds your API?". x402 Bazaar listing requires a CDP facilitator which is KYC-gated for a lot of flows. On your side L402 has no canonical registry AFAIK. In both cases the practical answer has ended up being: tell people it exists yourself.
  2. I just listed the audit endpoint on the official MCP registry (registry.modelcontextprotocol.io) via their HTTP-domain-ownership auth — /.well-known/mcp-registry-auth with an Ed25519 proof, no GitHub required. If you wrapped your gateway as an MCP server, AI-agent clients would discover it the same way (Claude Desktop / Cursor / etc. do tools/list against anything in the registry). The registry is pretty sparse on actually-useful remote tools right now, which is a feature if you ship early.
  3. 2% cut on Fly.io economics: fine for mid-volume, but for sub-cent per call (typical for AI-agent tool invocations) the Fly.io minimum + LND rebalance costs start to outrun the take rate. Running your own Aperture becomes cheaper faster than you'd expect.