BTCPAY
A BTCPay Server alternative, not a takeover.
BTCPay Server does more than SatBooth, on purpose. SatBooth is a narrower checkout for Lightning, on-chain bitcoin and Monero that keeps no on-chain or Monero spend key on its server.
Which one fits
Stay with BTCPay Server if you need stores, point-of-sale apps, payment requests or pull payments, or Lightning on LND or Core Lightning. SatBooth has none of these.
Consider SatBooth if you are one merchant who needs a checkout for Lightning, on-chain bitcoin and Monero, and you want the public server to hold no spendable keys. SatBooth is new: a release candidate, tested on regtest.
The differences, plainly
| Topic | BTCPay Server | SatBooth |
|---|---|---|
| Scope | Stores and multi-tenancy, apps (point of sale, crowdfunding, pay button), payment requests and pull payments. | One merchant, with no stores. A checkout page, a private merchant API and signed webhooks. |
| Payment methods | Lightning and on-chain bitcoin, with Monero through a plugin. | Lightning, on-chain bitcoin and Monero, built in. |
| Keys on the server | A wallet inside the server is among its features. | No spend key, ever: on-chain is watch-only and Monero is view-only. Hot Lightning money is bounded and budgeted. |
| Lightning | Runs on LND or Core Lightning. | A dedicated Alby Hub on its own host, reached over scoped, budgeted NWC connections. |
| Refunds | Pull payments, which the merchant approves and sends from a wallet. | Lightning refunds for orders paid over Lightning, each approved by a person with a signed approval. A person pays on-chain and Monero refunds from their own wallet. |
| API | The Greenfield API, with an invoice per store. | POST /v1/orders on a private listener. There is no list call, so keep each order’s id. |
| Webhooks | Events such as InvoiceSettled, InvoiceExpired and InvoiceInvalid, signed with BTCPay-Sig. | Six events (order.paid, order.expired, order.underpaid, order.late, order.reverted, order.paid_again), signed with SatBooth-Signature. |
If you switch
There is no migration tool and no BTCPay API compatibility layer. You set SatBooth up beside BTCPay, change your application to call SatBooth’s API, switch new orders over, and then retire BTCPay.
What moves
- Taking payments over Lightning, on-chain bitcoin and Monero.
- Your application’s integration: it creates orders, sends customers to the checkout page and reacts to webhooks.
- Refunds over Lightning.
What does not
- Invoice history. SatBooth starts empty, so export what you need from BTCPay first.
- BTCPay’s apps, payment requests and pull payments, and stores.
- Lightning channels and their funds, which stay in the old node until you close or drain them.
Do not point SatBooth at BTCPay’s bitcoind or at its store’s extended public key.SatBooth runs its own bitcoind, and your on-chain account for it is a new one in your wallet.
The guide lists what moves, what does not, and maps BTCPay’s invoice API and webhooks onto SatBooth’s.
