unsubbed.co

BTCPay Server

BTCPay Server lets you run bitcoin and other cryptocurrencies payment processor entirely on your own server.

Self-hosted cryptocurrency payments, honestly reviewed. No marketing fluff — just what running your own Bitcoin payment processor actually looks like.

TL;DR

  • What it is: Free, open-source (MIT) Bitcoin payment processor — you run it on your own server, funds go straight to your wallet, no third party ever touches your money [4].
  • Who it’s for: Merchants, e-commerce store owners, and developers who want to accept Bitcoin (and Lightning) without paying fees to BitPay, Coinbase Commerce, or any other custodial gateway [1][4].
  • Cost savings: BitPay charges 1% per transaction plus fees. BTCPay Server charges exactly $0 in processing fees — you only pay standard Bitcoin network fees [2][4]. On $10K/month in Bitcoin revenue, that’s ~$100/month saved immediately.
  • Key strength: Non-custodial by design. Your private keys, your funds. No account freezes, no KYC, no company that can deplatform you [5].
  • Key weakness: Setup is genuinely technical. You need a server, a synced Bitcoin node (or a remote one), and comfort with the command line. Non-technical founders will hit walls [1][5].

What is BTCPay Server

BTCPay Server is a self-hosted invoicing and payment gateway for Bitcoin. A customer hits checkout, gets a Bitcoin or Lightning invoice, pays from their wallet, and the funds land directly in yours. There is no payment processor in the middle holding settlement, charging a percentage, or deciding whether your business category is allowed [4].

The project was started in 2017 by Nicolas Dorier after BitPay — the dominant Bitcoin payment processor at the time — made a controversial move to support a Bitcoin hard fork that much of the community opposed. Dorier’s public response was: “This is lies, my trust in you is broken, I will make you obsolete” — which appears verbatim in the GitHub README as the project’s founding motto [README]. That origin story matters. BTCPay Server is not a startup looking for a Series B. It is a principled FOSS project built specifically to remove the need to trust any company with your Bitcoin payments.

The project sits at 7,454 GitHub stars and is written in C# [3]. It is backed financially through the BTCPay Server Foundation, with sponsors including Spiral, OpenSats, Tether, and the Human Rights Foundation [4]. Development is maintained by a global network of volunteers and contributors, not a traditional SaaS company.

The practical scope is wider than “accept Bitcoin on your website.” BTCPay ships with a point-of-sale app, crowdfunding app, payment request system, invoice management, a built-in wallet with hardware wallet support, and a full Greenfield REST API [4][README]. It also maintains full compatibility with the legacy BitPay API, which means existing BitPay integrations can migrate without rewriting their code [4].


Why people choose it

The case for BTCPay Server comes down to three things that no custodial Bitcoin gateway can match: fee elimination, custody, and censorship resistance.

On fees. Every custodial Bitcoin processor — BitPay, Coinbase Commerce, Strike, OpenNode — takes a cut. BitPay’s standard rate is 1% plus settlement fees. At volume, that adds up fast. BTCPay charges nothing. The only transaction cost is the standard Bitcoin miner fee, which goes to network miners, not to any company [2][4]. The homepage case study is instructive: Namecheap processed $73M in BTC revenue with 1.1 million transactions through BTCPay [website]. At 1% that would have been $730,000 in fees to a custodial processor. With BTCPay, it was $0.

On custody. The word “non-custodial” gets thrown around loosely in crypto, but BTCPay Server means it literally. Your private keys never leave your infrastructure. No company can freeze your account because there is no account. No compliance team can flag your business category. The PayRam comparison article [5] makes this vivid with a scenario most merchants in regulated-adjacent industries will recognize: the automated email that says your funds are frozen for 180 days. BTCPay Server eliminates that risk entirely by eliminating the custodian.

On censorship resistance. The AlternativeTo listing [3] and the bitcoin-builder review [1] both emphasize this: BTCPay requires no KYC, runs over Tor, and operates independently of centralized infrastructure. For certain business types — adult content, gambling, firearms, political organizations, journalists in hostile jurisdictions — this is not a nice-to-have. It is the only option that works reliably [1][5].

Versus BitPay specifically. This is BTCPay’s origin story and strongest comparison. BitPay is custodial, charges 1%, requires KYC, and has a track record of account freezes. BTCPay is non-custodial, free, anonymous, and cannot freeze anything because it is software you run [1][4]. The AlternativeTo description puts it plainly: BTCPay was built specifically for merchants who “want to be in control of your own funds” or whose BitPay application was rejected [3].

Versus PayRam. PayRam is a newer commercial self-hosted gateway that supports multi-coin environments (USDT on Tron, ETH, etc.) more smoothly. The PayRam comparison [5] is honest about BTCPay’s limitation here: adding altcoin support requires community-maintained plugins that vary in reliability, and the configuration process “can be a total pain-in-the-ass” in their words. If your customers want to pay in USDT or ETH, PayRam is easier. If they’re paying in Bitcoin, BTCPay is the gold standard [5].


Features

Based on the official documentation, README, and third-party reviews:

Core payment processing:

  • Direct peer-to-peer Bitcoin payments — funds go to your wallet, not a gateway’s wallet [4]
  • No processing fees, no middleman, no KYC [4]
  • Lightning Network support via LND, Core Lightning (CLN), and Eclair implementations [README][4]
  • SegWit and Payjoin support [4][README]
  • Full compatibility with legacy BitPay API for easy migration [4]
  • Tor support for enhanced privacy [README]

Invoice and store management:

  • Automated invoicing with real-time exchange rate updates [1]
  • Invoice export for bookkeeping [website]
  • Multi-store management from a single instance [2]
  • Multi-user and multi-tenant support — share your instance with others [README]
  • Webhook and payment notification system [2]
  • Payment refund management [4]

Built-in apps:

  • Point of Sale app — for physical retail, supports tipping [README][website]
  • Crowdfunding app — public campaign pages [README][website]
  • Donation button — embeddable on any website [website]
  • Payment Requests — send a payment link to a client [website]

Wallet and security:

  • Built-in full-node reliant wallet [README][4]
  • Hardware wallet integration via BTCPay Vault [README]
  • 2FA support [2]
  • Non-custodial by design — private keys stay on your infrastructure [1][4]

Developer features:

  • Full Greenfield REST API with comprehensive documentation [README][4]
  • Webhooks for workflow automation [2]
  • Integrations with WooCommerce, Shopify, Magento, PrestaShop, OpenCart, Ghost, WooCommerce, and 20+ other platforms [website]
  • Zapier integration listed [website]

Altcoin support:

  • Bitcoin-only build available (recommended by core team) [README]
  • Separate community-maintained altcoin build supporting Litecoin, Monero, and others [README]
  • Stablecoin support via integrations (USDT on Liquid Network) [2]

Pricing: SaaS vs self-hosted math

BTCPay Server (self-hosted):

  • Software license: $0 (MIT) [3][4]
  • Processing fees: $0 [4]
  • VPS to run it: $6–20/month depending on provider
  • Note: requires a Bitcoin full node or a connection to a remote one — a full node adds storage requirements (~600GB+ for the full chain)

Third-party hosted BTCPay (if you don’t want to self-host):

  • Several providers offer hosted BTCPay instances (LunaNode, etc.) starting around $10–15/month [README docs mention third-party hosting]
  • You lose some sovereignty (the host could theoretically interfere) but gain managed deployment

BitPay for comparison:

  • Retail plan: 1% per transaction
  • Enterprise: custom pricing
  • Settlement: typically 1–2 business days, to fiat or Bitcoin
  • Account can be closed at any time, funds frozen pending review

Concrete math for a mid-volume merchant:

Say you run an e-commerce store doing $15,000/month in Bitcoin revenue across 150 transactions. On BitPay at 1%, that’s $150/month in fees — $1,800/year. On BTCPay self-hosted on a $10/month VPS, you pay $120/year in hosting plus miner fees (typically cents per transaction on-chain, effectively zero on Lightning). That’s roughly $1,680/year saved, and you retain full custody of every satoshi from the moment of payment [1][4].

The math gets more dramatic at higher volume. Namecheap’s case study — $73M in BTC revenue — is an extreme example, but even at a fraction of that scale, the fee elimination case is airtight [website].

The genuine cost is time and technical overhead, not money.


Deployment reality check

This is where BTCPay Server’s honest review diverges from the marketing. The project is not difficult for a developer. It is very difficult for a non-technical founder.

What you actually need:

  • A Linux VPS with at minimum 2GB RAM — the recommended Docker deployment is the most supported path [4][README]
  • A Bitcoin full node, or a connection to a trusted remote full node. Running a full node requires 600GB+ of storage and syncing time measured in days [1]
  • Docker and docker-compose installed
  • A domain name and SSL certificate (reverse proxy required)
  • Basic Linux command-line competence

Multiple deployment paths exist:

  • Docker deployment (recommended, most documented) [4]
  • Manual installation
  • Third-party hosting (hosted BTCPay instances, where someone else runs the server) [README]
  • Cloud marketplace options (AWS, Azure, Google Cloud one-click deploys mentioned in docs)

What can go sideways:

  • The full node requirement is the first wall most non-technical users hit. Syncing Bitcoin’s blockchain from scratch can take days and requires storage that a $6 VPS often doesn’t have. The workaround is connecting to someone else’s node, which reduces sovereignty [1].
  • Lightning Network is not plug-and-play. Enabling Lightning requires managing channel liquidity, understanding routing, and accepting that Lightning payments can fail if channels are underfunded. The bitcoin-builder review [1] flags this explicitly: Lightning speeds up payments but adds operational complexity.
  • Altcoin support is fragile. If you need to accept anything beyond Bitcoin, the community-maintained plugins vary in quality and maintenance status. The PayRam article [5] describes this configuration path as a “multi-hour battle with command lines.”
  • No central support. Help comes from Mattermost, Telegram, GitHub issues, and community forums. No support tickets, no SLA, no phone number [4][5]. This is fine if you’re comfortable with open-source communities. It’s a problem if you need guaranteed response times.
  • The AlternativeTo user review [3] notes deployment is “very well described and proposes multiple ways,” which is genuinely true — the documentation is thorough. One reviewer from 2020 called this out as a clear positive.

Realistic time estimates:

  • Developer comfortable with Docker and Linux: 1–3 hours to a working instance, longer if syncing a full node from scratch
  • Non-technical founder following a guide: full day to several days, including waiting for blockchain sync
  • Non-technical founder using a managed third-party host: 1–2 hours, at the cost of some sovereignty

The documentation at docs.btcpayserver.org is comprehensive and actively maintained. The community is active and generally helpful. But self-hosting a Bitcoin payment processor is not in the same complexity category as spinning up a Wordpress site. Be honest with yourself about your technical comfort level before committing.


Pros and Cons

Pros

  • Truly zero processing fees. No company takes a cut, ever. Only standard network miner fees [4]. For any meaningful Bitcoin revenue volume, this is financially significant.
  • Non-custodial by design. Your keys, your coins. No account freezes, no forced KYC, no business category restrictions [1][4][5]. This is not a feature of the software — it’s the foundational architecture.
  • Censorship resistant. Operates without depending on any company’s goodwill. Tor support included. Works for industries that custodial processors routinely reject [5].
  • MIT licensed and actually free. No paid tiers, no “community edition vs enterprise” split, no features gated behind a subscription [3][4]. The entire codebase is open under MIT.
  • Lightning Network support is first-class. LND, Core Lightning, and Eclair are all supported [README]. Lightning is the path to instant, near-zero-fee Bitcoin payments.
  • Broad e-commerce integrations. WooCommerce, Shopify, Magento, PrestaShop, Ghost, OpenCart, and 20+ others [website]. If you run a standard platform, a plugin exists.
  • Active, principled community. Maintained by genuine contributors, not a VC-backed startup optimizing for exit. Funded through foundations and donations [4].
  • Strong documentation. The docs are thorough and cover multiple deployment paths, hardware wallet setup, Lightning configuration, and API reference [4].

Cons

  • High setup complexity for non-technical users. Bitcoin full node sync, Lightning channel management, and server administration are real prerequisites [1][5]. Not a weekend project for someone who has never used a terminal.
  • Bitcoin-centric, not multi-coin. Core support is BTC and Lightning. Altcoins require community plugins of varying quality and maintenance. If your customers want to pay in ETH or USDT, you will have friction [5].
  • No central support or SLA. Community help via Mattermost, Telegram, and GitHub. Fine for developers, potentially inadequate if this runs your business-critical payment flow [4][5].
  • Full node storage requirement. Running a full node requires 600GB+ of disk, which rules out cheap VPS tiers. Connecting to a remote node is possible but reduces trustlessness [1].
  • Lightning complexity is real operational overhead. Channel liquidity management, routing fees, and payment failure handling add operational burden beyond “install and forget” [1].
  • Not beginner-friendly. The bitcoin-builder review [1] explicitly calls this out: “may not be ideal for non-technical users or small businesses without dedicated IT resources.” This is accurate, not FUD.
  • C# stack is less common in self-hosted hobbyist community. Most self-hosted tools are Go or Node. Debugging and extending BTCPay requires C# familiarity.

Who should use this / who shouldn’t

Use BTCPay Server if:

  • You accept Bitcoin payments and currently pay processing fees to any custodial gateway — the fee elimination case is immediate and compounding.
  • Your business operates in an industry that custodial processors flag as “high risk” (iGaming, adult, political donations, journalism, certain international merchants) — this is often the only reliable option [5].
  • You have a developer on staff, or you’re technical enough to manage Docker deployments and want to learn Bitcoin infrastructure.
  • You’re building a product that needs Bitcoin payment capability and want to embed a proven, free, MIT-licensed component rather than build from scratch.
  • Privacy and censorship resistance are requirements, not preferences.

Skip it (use a custodial gateway) if:

  • You need a phone number to call when payments break. BTCPay has no support contract to buy.
  • You have zero Linux experience and no technical help available. The complexity is real [1].
  • Your transaction volume is low enough that 1% fees are immaterial and your time is worth more than the savings.

Skip it (consider PayRam or similar) if:

  • Your customers want to pay in multiple cryptocurrencies, especially ETH and USDT stablecoins. BTCPay’s multi-coin support is fragile and community-maintained [5].
  • You want a managed self-hosted experience with commercial support rather than a community FOSS project.

Use the third-party hosted BTCPay option if:

  • You want BTCPay’s fee structure and non-custodial payments but can’t manage a server yourself. You give up some sovereignty but gain operational simplicity [README docs].

Alternatives worth considering

  • BitPay — the incumbent custodial processor. Easier setup, enterprise integrations, 1% fees, KYC required, account risk. The reason BTCPay exists [1].
  • Coinbase Commerce — simpler onboarding, multi-coin support, custodial, US-centric compliance posture.
  • OpenNode — Bitcoin and Lightning focused, custodial, developer-friendly API, fee-based.
  • PayRam — newer self-hosted gateway with better multi-coin support, commercial product rather than FOSS, suited for merchants who need ETH/USDT alongside Bitcoin [5].
  • Strike / Lightning-native processors — if your focus is pure Lightning payments at scale, specialist providers exist, all with trade-offs on custody.
  • LNbits — ultra-lightweight Lightning wallet and payment system, simpler than BTCPay, no on-chain focus, hobbyist to small merchant scale.

For a merchant who wants to accept Bitcoin on their WooCommerce store and keep 100% of revenue, the realistic choice is BTCPay Server (self-hosted or third-party hosted) or accepting the ongoing fee cost of a custodial gateway. There is no middle ground that gives you both fee elimination and zero technical overhead.


Bottom line

BTCPay Server does one thing with extraordinary conviction: it lets you accept Bitcoin without trusting anyone. No fees, no custody, no KYC, no terms of service that can strand your funds. The Namecheap case study — $73M processed, zero processing fees paid — is the argument in a single data point. If you’re running real Bitcoin volume, the economics are obvious.

The honest trade-off is that “self-hosted” here actually means something. This is not a Docker container you spin up in twenty minutes and forget about. Running BTCPay properly means managing a Bitcoin full node, understanding Lightning channel liquidity if you want fast payments, and accepting that community forums replace a support team. For a developer or technical founder, that’s a reasonable cost for complete financial sovereignty. For a non-technical founder, the managed third-party hosting route is the pragmatic entry point — you get most of the benefit (zero fees, non-custodial, no account risk) without the infrastructure burden. If deploying and maintaining the server is the blocker, that’s exactly what upready.dev sets up for clients.


Sources

  1. Nakamoto Builder, bitcoin-builder.com“BTCPay Server: A Self-Hosted Bitcoin Payment Processor” (Dec 14, 2025). https://www.bitcoin-builder.com/btcpay-serveur/
  2. OsclassPoint“BTCPay Server Plugin | Crypto Payments”. https://osclasspoint.com/osclass-plugins/payments-and-shopping/btcpay-server-payment-gateway-integration-plugin-i225
  3. AlternativeTo“BTCPay Server: A free and open source server for merchants wanting to accept Bitcoin”. https://alternativeto.net/software/btcpay-server/about/
  4. BTCPay Server Documentation“What is BTCPay Server?”. https://docs.btcpayserver.org/Guide/
  5. PayRam Blog“PayRam vs. BTCPay Server: Which Self-Hosted Gateway Is Right for You?” (Jul 4, 2025). https://payram.com/blog/payram-vs-btcpay-server-which-self-hosted-gateway-is-right-for-you

Primary sources: