BTCPay Server

Service Overview

BTCPay Server is not, strictly speaking, a payment provider but a set of software you deploy yourself to process Bitcoin payments. The code is published under the MIT license and the official site states plainly that "BTCPay Server is an open-source project, not a company" — there is no legal entity to sign with, no SLA, and no compensation if you lose funds. The provider_country of United States refers to where the project originated and where most maintainers, shared-hosting operators and integration consultants sit, not to an American company standing behind your account.

The problem it solves is narrow and concrete: let a merchant accept Bitcoin without any third party in the path. Conventional acquiring runs as "customer pays, acquirer custodies, acquirer settles to you", and each link can be frozen, censored or repriced. BTCPay removes the middle link entirely — customer payments land in your own wallet, and the server only generates invoices, watches for confirmations and calls back into your order system. The platform cut is therefore 0%, and the merchant keeps the paid amount minus on-chain miner fees, with no processing-fee line in the books.

The trade-off is equally concrete and entirely operational. A conventional acquirer sells "you sell goods, payment problems are our problem"; BTCPay sells "payments are now your system". Nodes need syncing, containers need upgrading, backups need verifying, hot-wallet balances need controlling, and during congestion someone must decide the fee rate. In a company without dedicated operations staff, that work usually has no owner. This is why a shared-hosting middle layer exists — hand the instance to an operator, or hire a community integration consultant — but both only outsource the operations; they do not change the fact that you are the operator.

Scale is not the question: Namecheap processed over 73 million USD and 1.1 million transactions through BTCPay, Bitcoin Jungle used it to bring 200+ Costa Rican physical stores onto Bitcoin, and the official ecosystem lists 12+ e-commerce integrations. Whether it fits comes down to two things: does anyone on your team want to own a server long term, and is "no one can freeze my money" a hard requirement rather than a bonus?

Key Strengths

• The 0% cut is structural, not promotional: with no third party in the money path there is no place for a percentage fee to attach. For high-ticket collection this matters far more than any rate negotiation — the fee saved on a single 50,000 USD payment covers years of server bills.
• Funds go straight to your own wallet: there is no platform balance, no withdrawal review, no frozen account holding your money. Censorship resistance is not a slogan here; it is a property of the money path.
• One instance, many stores: multi-brand, multi-site and multi-entity operations can share an instance with isolated wallets and permissions, which keeps back-office reporting and reconciliation consistent instead of splitting it across several merchant accounts.
• Collection without code: point of sale, donation button, pay link and crowdfunding are all built in and work once a wallet is configured. A small team can go live within 1 day with no front-end developer involved.
• Integration coverage beyond expectations: beyond WooCommerce, Shopify and Magento, official plugins cover OpenCart, Odoo, Wix, Pretix, BigCommerce, Drupal, Xenforo, PhocaCart and Joomla VirtueMart, so long-tail merchants do not have to write connectors themselves.
• Real high-volume references: the Namecheap numbers of 73 million USD and 1.1 million transactions are not lab figures; they show the architecture holds under sustained load and that the operating model has been market-tested.

Product Ecosystem

Collection Front Ends (Point of Sale / Pay Button / Pay Link / Crowdfund)

Point of sale suits physical stores and stalls once products and prices are entered; the donation button embeds in a site sidebar or article footer; pay links can be sent by email or chat; the crowdfunding page publishes a campaign and tracks progress. All four share zero development cost and differ only in presentation and scenario.

Invoices and Checkout

The invoice is the core object: every payment creates one with an amount, currency, expiry and rate source, and customers pay through an on-chain address or a Lightning invoice. Backend order flow is driven by invoice state, with defined handling for expiry, partial payment and overpayment, which keeps finance and support able to trace any payment.

Wallet and Node Management

An instance can connect to your own full node or a third-party node service, supports BTC and Lightning wallets, exposes balances, balance distribution and transaction history, and isolates wallets per store. How much to keep in a hot wallet is the single most consequential parameter in this system.

Greenfield API and E-commerce Integrations

Greenfield is the official REST API; combined with webhooks it syncs collection, refunds and invoice state into custom systems. E-commerce support ships as plugins covering WooCommerce, Shopify, Magento, OpenCart, Odoo, Wix, Pretix, BigCommerce, Drupal, Xenforo, PhocaCart and Joomla VirtueMart, each creating an invoice at checkout and writing the order state back.

Deployment and Operations

Two paths: a self-hosted node on a VPS, dedicated server or local hardware for maximum independence, or a shared server hosted by a third party for the lowest operational barrier. Both are functionally equivalent; they differ in who can touch the server, who can touch wallet keys, and who debugs an outage.

Accounting and Reporting

Export and reporting capabilities map on-chain flows onto accounting entries. Reporting only organizes data — revenue recognition timing, fair-value conversion and tax filing positions still require a finance or tax adviser.

Limitations

• Community support, not customer support: answers come from forums, chat groups and documentation, with no ticket queue and no response commitment. For a company whose collection runs on this rail, that is a risk to accept up front.
• The hot wallet is the biggest single point of risk: automatic confirmation requires the server to hold keys for some balance, and a compromised server exposes that balance directly. Cold-hot separation, limits and prompt sweeping demand real expertise, and a mistake here has no second chance.
• Bitcoin only: USDT and USDC are not natively supported and neither is the Ethereum ecosystem. Merchants whose customers mostly hold stablecoins will find the addressable share small and will still need a multi-asset acquirer alongside.
• Network fees are outside your control: miner fees multiply during congestion and small tickets may stop being economic at that moment. Lightning mitigates this but requires Lightning-capable customer wallets and channel liquidity managed on your side.
• Unavailable to mainland China entities: virtual-currency business activity is explicitly prohibited there, which is a prohibition rather than a difficulty. Overseas entities serving mainland customers must still assess technology and compliance separately.
• Compliance and bookkeeping sit entirely with the merchant: no licensed rail, no KYC workflow, no tax position. In tightening jurisdictions that means added compliance cost which does not disappear because the software is free.

Use Cases

• Merchants for whom censorship resistance is a hard requirement (★★★★★): politically sensitive sectors, businesses already risk-flagged by processors, and teams with a real concern that funds could be frozen. The only value proposition of this design is that no third party sits in the path.
• Technical companies with operations capacity (★★★★☆): with an existing DevOps or backend team able to own node maintenance and key management, marginal cost is lowest and payoff highest.
• High-ticket Bitcoin collection (★★★★☆): where a percentage cut is material per transaction the 0% saving dominates and miner fees become negligible in comparison.
• Physical merchants with multiple stores or currencies (★★★☆☆): POS and multi-store management work out of the box, though stores must accept the friction of customers unfamiliar with Lightning.
• Small shops that just want a crypto button (★★☆☆☆): fully capable, but the operational burden and lack of support make it poor value for a store adding one payment method; a hosted processor is less work.
• Mainland China operations (☆☆☆☆☆): virtual-currency business is prohibited domestically and neither entity nor business nature can be made compliant. Not worth evaluating.
• Stablecoin-centric businesses (★☆☆☆☆): the worst fit of all, since BTCPay does not process stablecoins at all and integration work would be wasted.

Pricing

The table reflects currently published BTCPay Server documentation and ecosystem provider pricing. The software is free; total cost is composed of server, miner fees, liquidity, hosting and labor, with actual amounts governed by your cloud bill and service contracts.

FAQ

• BTCPay Server is free, so why budget anything?
  Free software does not mean zero total cost. Servers, miner fees and Lightning liquidity all cost money, and the largest line is usually the labor to maintain it. A stable instance needs several upgrade and backup-verification cycles per year, work that a hosted processor absorbs and self-hosting turns into your fixed overhead.

• There is no company, so who is accountable?
  No one, by design. The project is maintained by the community and sponsors, with documentation and community help but no contractual service guarantee. The real hedge is redundancy: separate hot and cold wallets, keep only a limited balance hot, rehearse backup restores, and validate upgrades on a test instance first.

• Shared server or self-hosted node?
  If nobody on the team wants to maintain a server, take shared hosting: same features, outsourced operations. If wallet keys cannot be handed to a third party, self-host. The deciding factor is not cost but whether you accept that someone else can touch your wallet, and the larger the balance the more the answer points to self-hosting.

• Can it accept USDT or USDC?
  No, stablecoins are not natively supported. Stablecoin collection requires a separate acquirer and two sets of books. If your customers are mostly on stablecoins, do not use BTCPay as the primary rail.

• Can a mainland China company deploy it?
  No. Virtual-currency business activity is explicitly prohibited there and self-hosting does not change the nature of the business. Overseas entities with mainland customers still need an independent compliance review; software running is not the same as a business that can operate.

Source: original 16IDC content. Product capabilities, supported countries and fee definitions follow the official documentation and your contract.