BTCPay Server

Imagine an online bookshop. A customer selects bitcoin and BTCPay Server creates an invoice, a request to pay a particular amount. The payment page shows an address or a Lightning request according to the shop’s settings. The software monitors receipt and notifies the connected shop when the status changes. You no longer have to identify each payment manually. It can also serve a checkout counter or collect donations. Open source code lets people inspect and modify the program; it does not by itself establish that a particular installation is secure. [1]

For an existing wallet, the server can receive an extended public key, information from which its receiving addresses can be derived. The private keys that authorize spending can stay elsewhere, for example in a hardware wallet. A hot wallet is different: its secrets are stored directly on an internet-connected device. Access to a Lightning node handling fast payments may also allow spending. Running the server and controlling the money are therefore separate questions. The label self-hosted does not answer them by itself. [2] [3]

Using somebody else’s server can spare you installation and maintenance. Even when payments go to your own wallet, though, you rely on its operator. A modified or compromised server can display an attacker’s addresses instead of yours. Obtaining a public key alone does not let the attacker spend previously received coins, but a tampered checkout can divert future payments. Verify receipts in an independent wallet too. A compromised self-hosted server has the same exposure; an outside host also affects availability and payment privacy. [4]

The book may be priced in Czech crowns while the customer pays in bitcoin. An invoice fixes the rate and amount for a limited period. Processing means the full requested amount was paid but settlement conditions, such as block confirmations, remain outstanding. Settled means those conditions were met; Lightning payments normally do not wait for a block. The shop must also handle partial, excess and late payments. Manually changing a status does not create a network confirmation. Nor does converting the displayed price send crowns to your bank account: conversion through a plugin or provider is another service with its own terms and costs. [5] [6] [3]

Programs connect through the Greenfield API, an interface for communicating with each other. The shop saves the invoice identifier alongside the order. A webhook, an automatic server message, reports changes; its authenticity must be checked as documented. Give the API access key only the permissions that this store needs. If the same message arrives twice, the shop must not send another book. A customer’s return to a thank-you page is not payment evidence either. After an outage, reconcile local records with invoices and actual payments. [7]

Lightning Network uses payment channels so that every payment need not be recorded separately in a block. Your own node must be available and have inbound liquidity: room in the channels through which funds can reach you. It therefore needs ongoing management. You can use help with liquidity, a swap between payment networks or a custodial service controlling funds on a customer’s behalf. These options have different permissions, fees and risks. The BTCPay Server name on a checkout page does not tell you which one the shop uses or guarantee that every payment succeeds. [8]

Wallet recovery information is not a backup of the entire shop. Alongside keys, you need invoice records, settings and other data appropriate to the setup. With Lightning, starting a node from an outdated channel state is particularly dangerous: incorrect recovery can put funds at risk. A planned move to a new server differs from disaster recovery. During migration, the original node must neither keep changing nor run alongside the restored copy. Follow the procedure for the particular implementation. Test Lightning restores in isolation from the network and peers so the test cannot affect live channels. The guide for Docker, an environment that runs application components in separate containers, applies to that deployment method. [9]

The advantage is being able to make decisions about your payment infrastructure. Somebody still has to handle updates, administrator access, internet-facing services and restorable backups. The software takes no percentage of each payment, but hosting, hardware, network fees and Lightning assistance can cost money. Avoid storing unnecessary personal customer data. If the book is lost or returned, the merchant handles the complaint and refund; BTCPay Server’s developers do not adjudicate the sale. Invoice records help with bookkeeping without replacing every accounting obligation. [10] [3] [7]