BTCPay Server Hosting and Support Agreements for Businesses

By Hank FasthoffSeptember 18, 2026

Suppose your store accepts a bitcoin payment, but the order never advances to fulfillment. The hosting company reports that its server is online, and the developer confirms that BTCPay recorded the payment. Each has completed the task it understood it was hired to perform, while your customer waits for an order that your store treats as unpaid. A contract that identifies responsibility for the connection between those systems can prevent that dispute over scope.

BTCPay Server supports several deployment arrangements, including installations your business controls and services hosted by another company. Hiring a provider introduces contractual questions about what it will operate, which credentials it will possess, and how you will continue accepting payments when the relationship ends. Those questions depend on the proposed installation and the services you purchase.

Define the Installation and Continuing Services

An installation fee may cover delivery of a functioning checkout on the acceptance date. Updates, monitoring, and repairs during the following year involve continuing obligations that the parties should address separately. You should identify which company is responsible for the server, the connection to your store, and ongoing maintenance, including any services it delegates to another provider.

The project’s MIT license permits commercial use and modification subject to its notice condition and supplies the software with warranty and liability disclaimers. Your paid provider’s promises belong in its agreement with you. A promise to configure an installation, maintain specified functions, or correct implementation defects should identify the performance you are purchasing and the circumstances in which the provider will charge additional fees.

Account ownership also affects your ability to enforce those arrangements in practice. A cloud account in the provider’s name may leave you dependent on its cooperation to obtain the installation or data when the contract ends. The agreement should address account ownership, administrative access, software modifications, and the documents a replacement provider will receive.

Identify Who Can Authorize Payments

BTCPay Server supports different signing arrangements. Its wallet documentation describes a hot wallet configuration that uses a recovery seed stored on the server to sign transactions. The project’s third party hosting guidance warns that enabling a hot wallet on a host’s server permits the host to access and spend the funds in that wallet, and it recommends against that arrangement.

You should have the proposed configuration documented before granting access. The description should identify where signing credentials will be stored, who can obtain them, and which actions the provider is authorized to perform. A provider’s ability to perform an action through its administrative access and its contractual permission to perform that action are separate questions.

Keeping signing credentials outside the server does not eliminate every risk associated with hosting. BTCPay’s guidance on third party hosting warns that a maliciously modified server could substitute payment destinations so that future customers send funds elsewhere. The same concern can arise if an attacker compromises a server your business operates. Contract provisions governing changes to payment settings, notice of suspected compromise, and preservation of activity records address responsibilities that a statement about possession of private keys leaves unresolved.

Connections between your store and BTCPay also use credentials. The project’s integration guidance recommends limiting API keys, which authorize software to perform specified actions, to the permissions those actions require. Your agreement should identify who approves those permissions, who retains access, and who revokes credentials when an employee or provider stops participating.

Specify When the Store Treats an Order as Paid

A successful demonstration of one payment leaves several commercial decisions unanswered. You should specify how the installation handles an incomplete payment, a payment received after an invoice expires, and a payment exceeding the amount due. Acceptance testing can establish whether the developer delivered the behavior your business approved before the final installation payment becomes due.

BTCPay’s invoice documentation distinguishes a payment recorded as processing from one recorded as settled after sufficient confirmations under the configured policy. It also describes manually marked statuses. Your integration therefore should identify which events permit fulfillment and who can override the normal process. An employee’s manual status change should not silently become the business’s only record of why an order shipped.

The connection can also fail after BTCPay records a payment. Acceptance criteria should address lost notifications, repeated notifications, and reconciliation between the payment record and the store’s order record. Someone should have an assigned duty to investigate discrepancies, with access to the records needed to resolve them. The customer terms and refund policy your business uses should correspond to the payment and fulfillment behavior the developer implements.

Define Support and the Consequences of an Outage

An availability commitment depends on what the provider measures. A server may respond to a monitoring request while checkout fails, so an agreement measuring only server availability may provide no remedy for the outage your customers experience. You should identify the functions covered by the commitment, the monitoring method, and the exclusions for maintenance or failures involving other systems.

Response time and restoration time also describe different obligations. A provider can acknowledge a support request within an hour and take several days to restore service. The agreement should identify the hours when support is available, which failures qualify for urgent treatment, and what the provider must do after acknowledging a request. Any deadline for restoration should account for the dependencies the parties have identified.

Maintenance provisions should address the software versions and plugins the provider supports, who approves updates, and who repairs an integration affected by an update. Emergency changes may warrant a different approval procedure, with notice and a record of what changed. Leaving maintenance undefined can produce an additional fee dispute while payments are unavailable.

You should compare the promised service with the available remedies. A credit against the next hosting bill may be the exclusive remedy for an outage, while a separate liability cap limits recovery for other failures. The agreement should distinguish those provisions and address claims involving unauthorized changes to payment settings, lost records, or exposure of credentials. Whether a proposed limitation is enforceable requires analysis of its wording and applicable law.

Address Lightning Operations Separately

An installation offering Lightning payments introduces responsibilities involving the payment channels used to send and receive bitcoin. BTCPay’s Lightning documentation describes several arrangements, including connections to external nodes and services that supply inbound liquidity, the channel capacity available for receiving payments. The operator of the payment server, the operator of the Lightning node, and the provider of that capacity may be different parties.

The agreement should identify which party monitors receiving capacity and who pays for the services or transactions needed to maintain it. A provider hired to keep a server online may have no obligation to manage Lightning capacity unless its scope includes that service. Custody and withdrawal arrangements also depend on the selected configuration, so the parties should document them alongside the operating responsibilities.

On a shared server, your chosen payment arrangement may depend on a plugin that only the administrator can enable. BTCPay’s Lightning documentation identifies that condition for certain shared hosting options, so the agreement should identify the required plugins and who will enable and maintain them.

Contract for Recovery of Funds and Business Records

Recovering access to bitcoin and restoring an operating store involve different information. Your business may regain access to funds and lack the invoice history needed to associate payments with orders, resolve refunds, or answer customer complaints. A backup obligation should identify the data covered, how frequently the provider copies it, and how much recent transaction information the business could lose after a failure.

BTCPay’s backup and restoration guidance for Docker deployments warns that Lightning recovery requires special care because using outdated channel information can result in lost funds. That warning supports requiring a recovery procedure suited to the particular installation and Lightning implementation. A generic promise to restore the most recent server image does not establish that the provider has addressed those requirements.

You should specify who maintains protected backup copies, who holds any credentials needed to use them, and how the provider tests restoration. BTCPay’s backup guidance states that the project accepts no responsibility for backups and directs operators to test restoration before relying on their backup strategy. Your provider’s agreement should assign that responsibility and specify the testing records and restoration targets it will deliver.

Preserve the Ability to Change Providers

Termination provisions should address the transition while both parties are willing to negotiate it. Your business should have an agreed period to obtain records and transfer operations, together with defined charges for transition assistance. Suspension rights deserve the same treatment because an invoice dispute can interrupt access before either party terminates the relationship.

BTCPay supports exporting invoices in CSV or JSON formats, but an invoice export represents only part of a transition. A replacement provider may also need configuration information, integration code, account access, and documents explaining authorized payment settings. The handover should account for unresolved payments and refunds, revoke the departing provider’s access, and address retention or deletion of customer information.

Before signing, you should be able to identify who will correct a failed checkout, who can change the destination of a payment, and what your business will receive when the provider leaves. The agreement should name those obligations and the remedies for failing to perform them. That specificity allows your business to purchase support for the payment operation it intends to use.