Overview
Accepting Bitcoin online is straightforward when you design for clear order states, verifiable receipts, and robust callbacks. Below is a vendor‑neutral checklist you can apply to any gateway or self‑hosted stack.
Implementation checklist
Decide pricing model: fiat‑denominated vs. sats‑denominated. For commerce, fiat‑denominated with live FX is typical.
Create orders before invoices: generate an internal order id and amount before requesting a payment invoice.
Use modern invoice formats: prefer bech32 on‑chain addresses and BOLT11/12 for Lightning.
Display timeouts and refresh: show countdowns and auto‑refresh expired invoices.
Verify payment via webhook + poll: accept a signed webhook and confirm via one additional trusted read.
Reconcile to a receipt: produce a human‑readable receipt with order id, amount, and proof link (txid or payment hash).
Handle under/over‑pays: define rules for partials and over‑payments (top‑ups or refunds).
Refunds & reversals: collect return addresses securely; issue proof‑linked refunds.
Accounting exports: map orders, payments, fees, and refunds to your ERP/GL.
Monitoring & alerts: track invoice lifecycle and webhook delivery (see Bitcoin Flux).
UX tips
- Always show the original fiat amount alongside sats paid.
- Offer both on‑chain and Lightning options; default to Lightning for small purchases.
- Provide a clear Order → Invoice → Paid → Fulfilled progress UI.
- Give customers a printable receipt with a proof link.
Security & reliability
- Verify webhooks with HMAC signatures and rotate secrets periodically.
- Store minimal PII; tie receipts to orders, not to raw addresses.
- Implement idempotency on your fulfillment endpoint.
- Back up keys/seeds if you self‑host; use Plan B Vault for governance.