Accept Bitcoin payments without running a server
BTCPay Server is excellent — if you want to operate a node, a database, and upgrades forever. Here is the trade-off, and what a hosted non-custodial processor looks like instead.
Ask how to accept Bitcoin payments without a custodian and the internet gives you one answer: run BTCPay Server. It's excellent software, genuinely free, and the right choice for a certain kind of merchant. This post is about the cost the advice leaves out — operations — and what a hosted non-custodial processor looks like when you don't want to be a sysadmin.
What "self-hosted" actually means, week to week
BTCPay's model is beautiful: your server, your node, your keys, zero trust in anyone. The invoice you pay for it isn't money, it's time:
- a VPS (or better) that you patch, monitor, and back up;
- a Bitcoin node to sync (hundreds of GB, days of initial sync) and keep synced — or a pruned/third-party compromise that erodes the trustlessness you came for;
- BTCPay upgrades, database migrations, and dependency CVEs, forever;
- being on call: if the box is down, your checkout is down, and nobody but you will notice at 3 a.m.
For a business with an ops team — or a merchant who enjoys running infrastructure — this is a fine trade. For everyone else it's the reason "we accept Bitcoin" quietly becomes "we used to."
The false binary
The usual framing is self-hosted and sovereign versus hosted and custodial — run BTCPay or hand your money to a processor that pays you out later. That binary is false. Custody and hosting are independent axes: what you actually need to keep is the keys, not the server.
chainkit sits in the quadrant the binary skips: hosted, non-custodial. You register an extended public key; every invoice derives a fresh address from it; customers pay on-chain straight into your wallet. We never hold funds — we can't; an xpub can watch, not spend. What we host is the bookkeeping: invoice state, confirmations, receipts, webhooks, exports.
What you give up, and what you get
Full disclosure of the trade: with BTCPay, payment detection runs against your own node — trust in no one. With chainkit, detection runs against a fleet of nine public RPC providers, scored and cross-checked with per-call failover (the fleet is public, live, on our scoreboard). And if you run our MIT Go SDK, its watcher verifies confirmations independently of our cloud — so even the hosted bookkeeping isn't a single source of truth you're forced to believe.
What you get back for that trade:
- No server. Nothing to patch, sync, monitor, or restore at 3 a.m.
- Business paperwork built in: fiat-priced invoices with the BTC rate locked at issuance, immutable PDF receipts with VAT and tax breakdown, HMAC-signed webhooks, CSV/JSON exports and a quarter-end receipts ZIP, GDPR PII redaction, EU hosting.
- Five minutes to first invoice — paste an xpub, verify a derived address against your wallet, issue. No sync, no Docker, no reverse proxy.
When you should still run BTCPay
If you need Lightning today, want zero third parties in payment detection, run a store on its plugin ecosystem, or simply have the ops capacity and the conviction — run BTCPay, sincerely. The Bitcoin ecosystem is better for it existing, and nothing about chainkit locks you out of moving to it later: your xpub, and therefore your money, works the same everywhere.
Try the hosted quadrant
Create a chainkit account, register an xpub, and issue a test invoice on testnet before touching real money. Pricing follows revenue — a monthly-renewing free tier, then a sub-1% fee on settled volume against a monthly minimum; the live numbers are on the pricing page. If you're comparing hosted processors instead, start with the Blockonomics head-to-head.