BTCPay Server

服务商概述

BTCPay Server 严格说不是一个支付服务商，而是一套可以自己部署的比特币支付处理器软件。项目以 MIT 许可证公开全部代码，官网明确写着 "BTCPay Server is an open-source project, not a company"——也就是说，没有一个法人主体跟你签合同、给你 SLA、在你丢币时赔偿。frontmatter 里写的 provider_country 是美国，指的是项目发起地以及主要维护者、共享服务器托管商、集成顾问所在的北美生态，而不是说存在一家美国公司为你兜底。

它要解决的问题很具体：让商户在不经过任何第三方的情况下收比特币。传统收单的链路是"客户付币、收单商托管、收单商再结算给你"，每一环都可能被冻结、被审查、被涨价；BTCPay 把中间那一环整个删掉——客户付的币直接进入你自己的钱包，服务器只负责生成发票、监听链上确认、回调你的订单系统。所以它的抽成是 0%，商户拿到的是客户支付的金额减去链上矿工费，账上不留任何"平台处理费"科目。

代价同样具体，而且是运维层面的。传统收单商卖的是"你只管卖货，支付出问题找我"；BTCPay 卖的是"支付这件事从今以后是你的系统"。节点要同步、容器要升级、备份要验证、热钱包余额要控制、链上拥堵时要判断加多少手续费，这些工作在一家没有专职运维的公司里通常没有归属人。这就是为什么它产生了共享服务器托管这个中间形态——把实例交给第三方运维，社区里也能找到按小时计费的集成顾问，但这两者都只是把运维外包，不改变"你才是运营方"这个事实。

项目本身的体量与案例说明它并非玩票：Namecheap 通过 BTCPay 处理了超过 7,300 万美元的 BTC 收款与 110 万笔交易，Bitcoin Jungle 借助它让哥斯达黎加 200 多家线下门店接受比特币，官方生态里另有 12 类以上的电商与建站系统官方集成。判断它是否适合你，关键不在功能清单，而在两件事：你的团队里有没有人愿意长期维护一台服务器，以及"没有中间人可以冻结我的钱"是不是你的硬需求而不是加分项。

核心优势

• 0% 抽成是结构性的，不是促销价：没有第三方在资金链路里，就不存在按比例收处理费的位置。对大额收款业务，这一条的价值远大于任何费率谈判——一笔 5 万美元的收款省下的处理费，足够支付几年的服务器账单。
• 资金直达自己的钱包：客户付款进入商户自己的钱包地址，不存在平台托管余额、不存在提现审核、不存在账户被冻结后钱取不出来的场景。抗审查不是宣传语，而是链路结构决定的。
• 一个实例管多个门店：多品牌、多站点、多法人可以共用一个实例并各自隔离钱包与权限，运营后台和账务口径统一，比给每个站点单独开一个收单账户更容易做集中对账。
• 不写代码也能收钱：销售点、打赏按钮、支付链接、众筹四种前端都是内置的，配好钱包地址就能用。小型团队最快 1 天可以上线，不需要前端开发介入。
• 官方集成覆盖面超出预期：除了 WooCommerce、Shopify、Magento 这些主流系统，还覆盖 OpenCart、Odoo、Wix、Pretix、BigCommerce、Drupal、Xenforo、PhocaCart、Joomla VirtueMart 等相对小众的建站与活动票务系统，长尾商户不必自己做插件。
• 有真实的高流水案例背书：Namecheap 的 7,300 万美元与 110 万笔交易不是实验室数据，说明这套架构在高并发与长期运行下是可用的，运维模式的成熟度也经过了市场验证。

产品生态

收款前端（Point of Sale / Pay Button / Pay Link / Crowdfund）

销售点适合线下门店与摊位，把商品与价格预先录入即可扫码收款；打赏按钮嵌入网站侧栏或文章末尾；支付链接可以发在邮件与聊天里；众筹页面用于公开募资并展示进度。四者的共同点是零开发成本，差异只在展示形态与使用场景。

发票与结账（Invoices and Checkout）

发票是核心对象：每笔收款生成一张带金额、币种、过期时间与汇率来源的发票，客户通过链上地址或闪电网络发票付款。后端按发票状态驱动订单流转，过期未付自动关闭，部分支付与超额支付都有明确状态定义，便于财务与客服追溯。

钱包与节点管理

实例可以连接自己的全节点，也可以接入第三方节点服务；支持 BTC 与闪电网络两种钱包，能查看余额、余额分布、历史交易，并把钱包与门店做权限隔离。是否启用热钱包、热钱包留多少余额，是使用这套系统时最需要谨慎设置的参数。

Greenfield API 与电商集成

Greenfield 是官方 REST API，配合 webhook 可以把收款、退款、发票状态同步进自有系统。电商集成以插件形式提供，覆盖 WooCommerce、Shopify、Magento、OpenCart、Odoo、Wix、Pretix、BigCommerce、Drupal、Xenforo、PhocaCart、Joomla VirtueMart 等 12 类以上系统，插件负责在结账页创建发票并回写订单状态。

部署与运维形态

两种路径：自建节点（VPS、独立服务器或本地硬件，隐私与独立性最强）与共享服务器（由第三方托管实例，运维门槛最低但需要信任托管方）。两种形态在功能上等价，差别在谁能接触服务器、谁能接触钱包密钥，以及出故障时谁来排查。

会计与报表

提供收款与结算相关的导出与报表能力，方便把链上流水映射到会计科目。但报表只解决数据整理，收入确认时点、公允价值折算与税务申报口径仍需财务或税务顾问判断。

不足之处

• 没有客服，只有社区：遇到问题去论坛、聊天群或文档里找答案，没有工单系统也没有响应时限。对一家把收款当作核心链路的公司，这是需要提前接受的风险。
• 热钱包是最大的单点风险：为了自动确认收款必须让服务器持有一定余额的私钥，一旦服务器被入侵，这部分资金直接暴露。风险敞口的控制方式（冷热分离、限额、及时归集）需要专业知识，做错没有第二次机会。
• 只支持比特币：USDT、USDC 不原生支持，以太坊生态资产也不在其中。客户群体以稳定币为主的业务，接入后会发现可用客户比例很低，最终还是要再挂一家多资产收单商。
• 网络费不可控：链上拥堵时矿工费会成倍上升，小额收款在这一刻可能不划算。闪电网络能缓解，但要求客户钱包支持闪电，且商户侧要管理通道流动性。
• 中国大陆主体不可用：境内虚拟货币相关业务活动属明确禁止范围，这是"不能办"而不是"难办"。海外主体若客户主要在大陆，技术与合规要分开评估。
• 合规与记账责任全在商户侧：没有持牌通道、没有 KYC 流程、没有税务口径，全部自己承担。这在监管趋严的市场意味着额外的合规成本，且这部分成本不会因为软件免费而消失。

适用场景

• 把抗审查当硬需求的商户（★★★★★）：政治敏感行业、已被支付机构风控过的业务、以及对"资金随时可能被冻结"有实际担忧的团队。这套方案的唯一价值主张就是链路上没有第三方。
• 有运维能力的技术型公司（★★★★☆）：已有 DevOps 或后端团队、能承担节点维护与密钥管理的公司，边际成本最低，收益最大。
• 大额比特币收款（★★★★☆）：单笔金额大、抽成百分比影响显著的场景，0% 处理费的节省最明显，矿工费占比反而可忽略。
• 需要多门店、多币种展示的线下商户（★★★☆☆）：POS 与多门店管理开箱可用，但线下场景要接受客户不熟悉闪电网络带来的收银摩擦。
• 只想简单接个收币入口的电商（★★☆☆☆）：功能上完全能做，但运维负担与"没有客服"这两点，对只想加一个支付方式的小店来说性价比不高，用托管型收单商更省事。
• 中国大陆业务（☆☆☆☆☆）：境内虚拟货币业务禁止，主体与业务性质都无法合规，不建议评估。
• 稳定币为主收付的业务（★☆☆☆☆）：这是最不适合的场景，BTCPay 根本不处理稳定币，接入等于白做。

价格参考

上表按 BTCPay Server 官方文档与生态服务商当前公开口径整理。软件本身免费，实际总成本由服务器、矿工费、流动性、托管与人力构成，具体金额以你的云账单与服务合同为准。

常见问题

• BTCPay Server 免费，为什么还需要预算？
  软件免费不等于总成本为零。服务器要钱、矿工费要钱、闪电网络流动性要钱，而最大的一块通常是维护它的人力。一个稳定运行的实例每年需要若干次升级与备份验证，这部分工作在托管型收单商那里是由平台承担的，在自托管模式下变成了你的固定支出。

• 没有公司主体，出问题找谁？
  找不到人负责，这是产品形态决定的。项目由社区与赞助方维护，提供文档与社区支持，但不提供合同意义上的服务保障。真正的风险对冲手段是冗余设计：冷热钱包分离、只让热钱包保留有限余额、备份定期做恢复演练、关键升级先在测试实例验证。

• 共享服务器和自建节点该选哪个？
  团队里没有人愿意长期维护服务器，就选共享服务器，功能一致、运维外包；如果钱包密钥不能交给第三方，就必须自建节点。判断标准不是成本，而是"你能不能接受别人能接触你的钱包"。资金量越大，这个问题的答案越倾向于自建。

• 能收 USDT 或 USDC 吗？
  不能，原生不支持稳定币。需要稳定币收款要另接一家稳定币收单商，两套账并行。如果客户群体以稳定币为主，不建议用 BTCPay 作为主通道。

• 中国大陆公司能部署吗？
  不能。境内虚拟货币相关业务活动属明确禁止范围，技术自建不改变业务性质。海外主体若客户主要在大陆，同样需要独立评估合规风险，软件能跑通不等于业务可落地。

来源：16IDC 原创，产品能力、支持国家与费率口径以 btcpayserver.org 官网文档及合同为准。