BTCPay Server is free payment-processing software under the MIT licence that can run on your own instance or through a third-party host. The project provides software, not a universal custodial account or arbitration service for merchant disputes. Trust depends on how the server, wallet and payment services are actually connected.
A merchant connects a point of sale or online shop to an invoice and the chosen receiving method. BTCPay Server creates on-chain payment addresses and Lightning requests, monitors payments and provides an invoice overview. It also includes point-of-sale and donation applications and integration interfaces. Open source enables inspection and modification but does not itself establish the security of a particular installation. [BTCPay Server — Source repository]
An existing on-chain wallet can be connected using an extended public key: the server derives receiving addresses without needing its private key. A hot wallet created on the server has a different risk model. Lightning node permissions may also allow control over its funds. Separate keys for receiving, signing and administration; the word self-hosted alone does not determine who can spend the money. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
A third-party host operates the server while the user may receive directly into their own wallet. This does not remove trust: a malicious or compromised server can substitute a public key and redirect future payments. Coins already received in your wallet and newly displayed payment details are separate matters. Check receipt independently of the checkout as well. The same attack can affect a compromised self-hosted instance; the host also influences availability and privacy. [BTCPay Server — Third-party hosting risks]
The shop configures the currency, rate source, expiry and required confirmations. Processing for an on-chain payment awaits the configured condition; Settled indicates that it has been met. A successful Lightning payment need not wait for a block. Handle underpayments, overpayments, late receipt and manual status changes, which do not create network confirmations. Converting a price into bitcoin is not selling into fiat: a conversion plugin or provider introduces its own fees and trust requirements. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
The online shop should retain the link between an order and its invoice identifier. Greenfield API allows permissions to be scoped to the store; give the key no more access than the integration needs. Verify webhooks according to the documentation and process repeated events without a second shipment. A customer’s return to a thank-you page does not itself prove payment. After an outage, reconcile local records with the actual invoice and payment states. [BTCPay Server — eCommerce integration]
Your own node requires availability, channel management and inbound liquidity. A liquidity service, a swap or a custodial wallet addresses different parts of the problem and is not the same model. With a custodial service, control of funds remains with the provider; for other arrangements, check the actual permissions and risks. The BTCPay Server logo does not guarantee that every payment succeeds or that fees are zero. [BTCPay Server — Lightning options]
Back up store information, invoices, configuration and required wallet data according to the deployment; a seed does not replace the order database. The Docker documentation requires checking that a backup can be restored. An old Lightning channel state can cause loss of funds if restored incorrectly. A planned migration with the original node cleanly stopped differs from disaster recovery; once the replacement is running, do not start the original copy of the same node. Follow the procedure for the backend in use. [BTCPay Server — Backup and restore]
Plan updates, administrator-access protection, network exposure, availability monitoring and verified backups. Hosting, hardware, network fees, liquidity and support can cost money even when the software takes no percentage of each payment. Minimise stored customer data. The merchant handles refunds and delivery disputes, not the project’s developers; exporting invoices does not guarantee fulfilment of every accounting obligation. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
A checkout outage does not mean losing coins already received
In a hypothetical shop, the server knows only the public data of an external wallet. If hosting fails, on-chain coins already received remain under the control of that wallet’s keys, but the checkout may be unable to create new invoices or report payments. The operator restores the service, checks the receiving configuration and reconciles orders with the wallet. This example cannot be applied to a hot wallet stored on a lost server or to an outdated Lightning channel state.
For the clearest picture, read this entry together with Bitcoin Payment Processor, Bitcoin Point of Sale, Self-custody, Lightning Network, Merchant Adoption, Bitcoin. The reverse links also lead from Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01Does BTCPay Server automatically mean self-custody?+
No. The connected wallet, Lightning service and actual permissions determine that. Receiving into an external wallet using only a public key differs from a hot wallet on someone else’s server or a custodial backend. You must also trust the correctness of the payment details displayed.
02Is a seed backup sufficient for recovery?+
A seed may restore the corresponding on-chain wallet, but not automatically the invoices, store settings or Lightning channel state. Those parts have their own backups and procedures. Recovery must be tested; an outdated copy of an active Lightning node cannot safely be treated as an ordinary file backup.