Accepting Lightning Payments on a Static Site

You built a tool, a landing page or a small SaaS and you want to be paid in sats - without a merchant account, a credit-card processor or KYC onboarding. Lightning Network solves this: here is the practical setup I use on a static GitHub Pages site, with real numbers from payments that actually went through.

The minimum viable setup

You only need three things: a Lightning wallet that can receive, a Lightning address (looks like user@domain, e.g. you@sats.place), and a static page with two links. No backend, no database, no API keys to renew.

• Wallet: a non-custodial or custodial wallet that gives you a Lightning address. Alby, LNBits, lntxbot/ln.bot and many others issue one for free.
• On the page: a lightning:you@domain link for desktop wallets, and a bolt11:// or LNURL-pay link for invoice-based wallets.
• Check payments: either watch the wallet dashboard, or monitor the LN address programmatically if your wallet exposes an API (see below).

Lightning addresses vs invoices

A Lightning address is the user-friendly receive end: the payer's wallet resolves it to an invoice automatically. An invoice (BOLT11 string starting with lnbc) is a one-time payment request with an expiry. For a donate button or a fixed-price product, offering both covers everyone: some wallets only handle addresses, some only invoices.

The crypto-link you can embed on GitHub Pages

Static hosts block server-side payment code, but they allow links. This is the entire trick:

<a href="lightning:you@sats.place?amount=6000">⚡ Pay 6,000 sats</a>
<a href="bitcoin:bc1q...?amount=0.00006&label=Pro">₿ Pay on-chain</a>

Clients with a registered handler (Phoenix, Alby browser extension, most LN wallets) will open and pre-fill the amount. Add a small what you sent form so you can match payments to orders manually - this is how I issued API keys on a page that has zero backend.

What routing actually costs (real numbers)

You pay a routing fee on every outgoing settlement. On the wallet I use, a fixed ~4 sats came off each payment regardless of size: a 6-sat invoice settled as 10 sats, an 8-sat invoice as 12. On small payments that is brutal (50-67%); on a 6,000-sat plan it is noise (0.07%). Implication: design price points above roughly 1,000 sats if you want fees to matter less.

Monitoring without a backend

Two patterns that work on a plain VPS or even a laptop cron:

• On-chain: poll blockstream.info/api/address/<addr>/txs and diff the transaction count - zero auth, free tier is fine.
• Lightning: if your wallet has a CLI (ln.bot ships one), script balance/transactions and compare against a saved baseline to detect incoming sats.

Security notes

• The wallet's API key is a bearer token: keep it out of the repo, use a vault or env var.
• Lightning invoices are single-use and non-refundable by design - decide your refund policy before you sell digital goods (a refund is a new payment, not a reversal).
• Back up the wallet recovery phrase in two places. Losing the phrase is losing the balance.

Frequently asked questions

Do I need a domain? No - many free wallet providers give you you@their-domain endings. You can upgrade to your own domain later.

Is this KYC-free? In practice yes: the wallet providers mentioned issue addresses with just an email or a generated account. Regulations vary by region, so verify yours.

Can I accept fiat too? Sure - the on-chain Bitcoin link works globally, and for card payments you would add a processor form, but LN stays the zero-fee-custody option.

How do I confirm a payment before shipping? Match the exact amount and memo, or wait for the wallet baseline to change by the expected amount. For fixed-price products, check once and issue.

Need an LLM API you can pay per call with Lightning? See plans →

← All 65+ free dev tools