在 VPS 上自建 BTCPay Server：无需支付处理商即可接受 Bitcoin 和 Lightning

BTCPay Server 究竟是什么，它替代的又是什么

BTCPay Server 既不是钱包，也不是一家支付公司。它是一层软件，架在你的网站和你自己的 Bitcoin 节点之间，替你完成处理商平常替你做的那些枯燥却必要的工作：为每笔订单生成一个新地址或 Lightning 发票，按一个在发票有效期内锁定的汇率报出法币金额，监视链上的付款情况，判断付款何时算作已结算，并通知你的店铺。资金在到达你手上的路上，从不经过任何人的账户，因为压根没有账户——这些地址属于一个由你掌控的钱包，软件只是在旁观察它们。

这个架构上的单一差异，就是运行它的全部理由。一家托管处理商是一家有合规部门、有银行账户、有服务条款文件的公司，条款保留在审核你期间扣留你结算款项的权利。它会要求你提供身份证明文件，因为它在替你转移资金，而它自己的监管机构要求它知道自己转移的是谁的钱。自建去掉的是中间方，而不是去和它谈判：没有开户流程，没有月度交易量审查，没有结算周期，也没有任何东西可供第三方冻结，因为资金从始至终都不曾经过第三方手中。

你为这些工作换来的，是一套真正完整的结账系统。带有效期、锁定汇率的发票。同一张发票里同时支持链上和 Lightning，这样一位只需付 2 美元的顾客，就不会被要求再付 3 美元的网络手续费。一个 POS 页面、一个捐款按钮、一个众筹页面，以及一个可以粘贴进任意 HTML 的支付按钮。面向主流店铺平台的插件；如果你的店铺是自己写的，还有一整套 REST API。退款、pull payment 提现申请、打款。如果你在意打破接收端的共同输入所有权假设，还有 Payjoin 可用。

有必要说清楚哪些不包含在内，因为对自建支付最常见的失望，都是源于把它当成了一款产品去期待，而它实际上是一套协议。没有人会替你把 Bitcoin 换成欧元、再电汇进银行账户；如果你需要这个，你依然需要一家交易所，而交易所依然会问你是谁。没有人替你承保拒付，不过这里本来也没有拒付可承保。凌晨两点，节点掉出链的时候，也没有人替你接电话——这现在是你自己的工作，也是这篇指南里人们最容易跳过的部分。

这台机器：它到底需要什么，便宜套餐的极限又在哪里

应用本身很小，它底下的技术栈可不小。一次默认部署会运行 Bitcoin Core、一个名为 NBXplorer 的地址索引器、一个 PostgreSQL 数据库、BTCPay 的 Web 应用、一个负责证书的反向代理，如果你启用了它，还有一个 Lightning 节点——每一个都在自己的容器里运行。Web 应用放在树莓派上都会很开心，Bitcoin Core 可不会。

内存是人们最容易买少的地方。2 GB 在技术上能把这套技术栈跑起来，但会让初始同步过程一直在用交换分区，而在共享 NVMe 上，这是把一天拖成三天的好办法。仅做链上支付时，4 GB 是一个还算靠谱的底线。一旦用上 Lightning，8 GB 才是现实中的底线，因为你现在多跑了一个守护进程，它有自己的数据库、自己对网络图的一份认知，而且 bitcoind 在初始下载期间，如果你能给它一个较大的 dbcache 而不是保守的默认值，性能会好上非常多。Bitcoin Core 里的内存精简说明是查询该用哪些旋钮、拿内存换时间的参考资料。

磁盘是第二个要考虑的因素，也是真正决定你套餐选择的那个。未修剪的链已经超过 700 GB，并且每年还在以大约 60 GB 的速度增长，所以归档节点已经不再适合我们出售的任何一档 VPS，它属于独立服务器，在那里就算做一对镜像，也依然能留给你一整个 TB 的空间。修剪彻底改变了这一点——节点只保留一个滚动窗口内的近期区块，其余全部丢弃，而对一个支付端点来说，这完全算不上什么妥协，因为商家从来不需要向任何人提供历史区块。再加上索引器的数据库、PostgreSQL、Docker 镜像和数据卷、Lightning 节点自己的存储，以及日志，一个修剪过的部署，妥妥地落在 100 GB 级别的机器里，还留有增长空间。

CPU 的重要性，主要集中在你人生中的某一周。初始区块下载期间的签名验证，是这台服务器一生中要做的最重的活；在那之后，每十分钟验证一个区块、再回应少量的发票请求，接近于空闲状态。为同步这件事去买核心数，而不是为稳定运行状态去买——或者干脆买更小的套餐，接受同步会更久一些，只要你不赶时间，这是一笔完全合理的取舍。

修剪省的是磁盘，不是时间——同步才是真正的瓶颈

关于运行节点，最常见的一个误解，就是以为修剪能让它变快。并不能。一个修剪节点，会像归档节点一样，从创世区块开始下载每一个区块，并验证其中每一笔签名；唯一的区别在于，一个区块一旦验证完毕、不再需要，就会被删除，而不是保留下来。你省下的是磁盘。带宽上你什么都省不了，时间上也什么都省不了。如果有人指望一个修剪节点一小时就能就绪，他会用那一个小时说服自己肯定是哪里出了问题。

它实际要花多长时间，几乎完全取决于你给了它多大的缓存、磁盘有多快。在 NVMe 上，配上几 GB 的 dbcache 和四个独占核心，一天是一个合理的预期。在一个默认缓存的小套餐上，如果邻居又比较吵闹，两三天也很正常，而且这个过程大部分时间都花在把 UTXO 集反复写入磁盘上，因为它没法把整个集合都放进内存。这是唯一一个值得花真金白银临时升级套餐的时刻：为了同步升一档，之后再降回来。按月计费、没有合同，正是让这个操作变得便宜的原因。

等链同步完之后，还有第二次几乎没人会提前计划的等待。当你连接一个已经有历史记录的钱包——比如你用了一年的硬件钱包的扩展公钥——索引器就得扫描整条链，找出从这个密钥派生出来的地址。在一个修剪节点上，这次扫描会受限于磁盘上还留着什么，这正是安装顺序为什么重要：如果你需要历史交易显示出来，就要在旧区块被丢弃之前把钱包指向节点；否则就接受存储会从今天开始记录，并把这当作它通常本来就该有的、干净的起点。

实际排期上的原则是：这台机器必须提前投入使用、并且早早开始同步，赶在店铺真正需要它之前。开通它，启动下载，然后把这段中间的等待时间，用来做那些不依赖于链的部分：DNS、证书、店铺插件、钱包、备份流程。如果你把节点这件事拖到最后才做，你会发现自己已经把上线日期，绑定在了一个谁也没法加速的过程上。

密钥：你只需要做一次的架构决定

决定你最糟糕的一天能有多糟糕的问题很简单：这台服务器能不能花掉这笔钱？对链上支付而言，答案应该是不能，而 BTCPay 的设计，正是让你可以说不能。你导入一个扩展公钥——一个 xpub，或者它的现代等价物——它派生自一个硬件钱包或一台离线签名设备。服务器会为每一张发票，从这个密钥派生出一个全新的收款地址，监视链上有没有付款打到这些地址，并把结果报告给你。它没法构造出一笔有效的花费交易，因为它从来没见过私钥。这时哪怕机器被彻底攻陷，你付出的代价也只是这台机器和顾客的订单数据——这已经很糟了，但你损失不了收款本身。

另一种选择——让 BTCPay 生成并持有一个热钱包，图个方便——这个选项是存在的，对于非常小的交易量偶尔也是正确的选择，但它应该是一个刻意做出的决定，而不是因为它是默认按钮才发生的事。如果你选了它，就要把这台服务器上的余额，当成店铺收银台里的现金来对待：按计划定期清空，只留下一天交易所需的量，并且清楚地知道，这份助记词就存在数据中心某块磁盘上。

Lightning 是唯一没法回避的例外。一个 Lightning 节点必须实时对交易签名，才能更新通道状态，所以它的密钥必然是热的，也不存在一种仅观察模式还能让你收款。这不是 BTCPay 的设计缺陷，而是协议本身的要求。正确的应对方式，是把 Lightning 里的余额，按实际需要的规模来配置——留够接收一天或一周订单所需的入站容量就行，而不是把你的全部资金放进去——并且定期把积累下来的收款转移到冷存储中，这和任何店铺对待收银台现金的纪律是一样的。

这个决定里还有一件事同样重要，因为它正是人们通常要等到出事之后才会想起来的部分：把助记词放在哪里写下来，写成你的继任者能够照着操作的形式，并且存放在既不是这台服务器、也不和这台服务器在同一栋楼里的地方。VPS 上的全盘加密能保护静止状态下的磁盘，防止被离线复制；但它对一台正在运行的机器毫无帮助，如果你的助记词唯一的副本就在这台机器上，全盘加密更是完全帮不上忙。

Lightning 是一个披着软件外衣的流动性问题

安装一个 Lightning 节点很容易。在上面收到第一笔付款却不容易，而且这个原因几乎会难住每一个人。一个 Lightning 通道，是一份双边余额：当你开通并注资一个通道时，全部容量都在你这一侧，这意味着你能付钱给别人，却没有人能付钱给你。接收需要入站容量——资金要坐在通道的另一端，随时准备向你这边移动。一个刚装好、有三条资金充裕的出站通道的全新节点，依然可能收不到顾客的一聪，而结账页面也就干脆不会把 Lightning 作为一个选项提供出来。

有三种诚实的办法能解决这个问题。你可以向流动性提供商购买入站容量，这是最快的办法，代价是一笔与金额和时长成比例的费用。你可以做一次 submarine swap——通过 Lightning 付出、在链上收进来，这会把你自己的余额转移到通道的另一端，把出站容量换成入站容量，代价是这次 swap 的手续费。或者你可以请一个人脉广的对端主动向你开一条通道，如果你们本身有交情，这是免费的，没有的话就会很慢。不管你选哪一种，都要在上线之前就把它编入预算，并按你预期的订单流量来定规模，而不是随便挑一个整数。

通道还需要一种链上支付不需要的维护。入站容量会随着顾客付款而被消耗：每一笔收到的付款，都会把余额从对方那一侧的通道，移到你这一侧，所以一个只收款的店铺，接收能力会不断被耗尽，迟早需要重新平衡或者换出容量。通道会关闭，有时是对端消失后单方面关闭的，而一次强制关闭，会让你的资金在一段时间内被锁定在时间锁后面，还要付一笔链上手续费。节点需要保持在线，才能接受付款、才能监视作弊的交易对手。这些都不难，但全都是持续不断的，这也是为什么很多店铺只用 Lightning 处理小额订单，超过某个门槛的一律安静地转去链上结算。

这份麻烦换来的回报是实打实的。链上手续费不管付款金额大小都一视同仁，这让一笔 5 美元的订单，在内存池繁忙时贵得离谱，在内存池空闲时又完全没问题——而你没法控制，你上线那天赶上的会是哪一种情况。Lightning 付款不到一秒就能结算，不管网络有多拥堵，费用都只有几分之一美分，对于定价像一杯咖啡、一次下载、一笔 API 充值或者一份月度订阅这类东西来说，这就是一个能用的结账系统和一个悄悄丢单的结账系统之间的差别。

会让你变砖的备份：Lightning 节点绝不能回滚

就算你已经了解这篇指南里的其他所有内容，这一节也是你必须读下去的理由。用旧数据副本恢复一个 Lightning 节点，绝不是一个中性的操作，在错误的情况下，它会摧毁你的通道余额。运维人员的本能——打一个快照，出问题时就恢复这个快照——恰恰就是造成这种损失的那个本能。

背后的机制，是这个协议对作弊的惩罚机制。每一次通道更新，都会取代前一个状态，而且双方都会把惩罚对方的手段，交到对方手里，前提是对方胆敢公布一个已经被取代的状态。正是这一点，让一个双方通道无需裁判也能保持安全。但这也意味着，一个从昨天的副本恢复回来的节点，会真心相信一个旧状态就是当前状态，如果它照着这个信念行动——不管是主动强制关闭，还是仅仅被要求这么做——交易对手就有权拿走整条通道的全部余额，而对方的软件会自动完成这一切。你并不是故意想作弊。但协议分辨不出两者的区别，它压根就不是为分辨这个而设计的。

所以这条规则是绝对的，值得写在墙上：绝不能把 Lightning 节点恢复到更早的状态。不能用文件系统快照，不能用数据库转储，不能用你上周做的那份数据目录副本，也不能用服务器自带的每小时快照。快照对机器上其余的部分堪称优秀，唯独对这一个目录很危险，而且这种危险是无声的——节点会正常启动，看起来很健康，代价会在之后才找上你。

取而代之，你要保留的是一份静态通道备份：一个小文件，每当通道开通或关闭时都会更新，里面包含的信息刚好够用来请求每个交易对手协作关闭通道、把你的资金还给你。LND 把它叫作 channel.backup，并在自己的恢复指南里记录了它的具体语义；Core Lightning 也提供了等价的机制，外加一个能持续保持数据库副本同步的插件。恢复这类备份，并不会让你的通道继续运作——它会把所有通道强制关闭，并把余额收回来，这正是彻底丢失数据之后唯一正确、也是唯一安全的结果。把它存放在这台机器之外，保持更新，并且明白它是一份保险单，不是一个续玩按钮。

至于其他一切，正常而且大方地备份就好。BTCPay 的部署自带一个备份脚本，会先停掉整套技术栈，一致性地转储数据库和配置，然后再重新启动；按计划运行它，并把输出复制到别处，最好是另一个司法管辖区的第二台服务器。数据库里存的是你的发票、店铺、用户、API 密钥和各项设置——不是你的钱，但却是你全部的历史记录，而这才是你真正会怀念的东西。

服务器坐落在哪里，本身就是支付技术栈的一部分

人们很容易把主机服务，当成藏在有趣部分底下的一种大宗商品。但对一个支付端点来说并非如此，因为结账系统是唯一一个可用性直接等于收入的组件，而且服务器是一个存在于某个法律司法管辖区里的实体物件，背后有一个可以被联系到的服务商。当你的支付基础设施是一家托管处理商时，那家服务商的合规姿态，就是你的合规姿态。当你自建时，你的主机服务商的姿态，就取代了这个角色——如果你自建的初衷，恰恰是为了摆脱一家支付公司的自由裁量权，那么把同样的自由裁量权交给运营这台机器的公司，就是一种粗心大意。

有三项属性值得你认真对待。第一项，是主机商掌握着什么身份信息：一个用邮箱地址开通、用加密货币付款的账户，没有什么可以交出去，也没有什么可以被冻结，这正是当初促使你走上自建这条路的同一套逻辑。无 KYC 主机服务说明了这在实践中意味着什么、又不意味着什么，包括它那个不太舒服的推论——一个从未知道过你是谁的服务商，在你自己丢失访问权限时，也没法把账户还给你。

第二项，是司法管辖区。一个服务着许多国家顾客的结账端点，本身却只坐落在一个地方，而那一个地方的法律，决定了谁能够强制这家服务商、基于什么理由、以多快的速度。我们的四个地区——冰岛、荷兰、罗马尼亚和瑞士——在这方面存在实质性差异，对不同客户群体的延迟表现也不一样，选择司法管辖区这篇文章妥善梳理了这些取舍。这里也有一个平实的运维角度：如果结账延迟对你很重要，就把节点放在离顾客近的地方；如果不重要，就把它放在离你其他基础设施近的地方。

第三项，是主机服务本身的付款方式，而这正是大多数人留下的那个漏洞。用你自己名下的信用卡为一台服务器付费，却在上面运行一个匿名、非托管的结账系统，恰恰会造出你搭建这整套技术栈原本就是为了避免的那种关联。用 Monero 或 Bitcoin 为这台机器付款，就能补上这个漏洞——同样的逻辑，只是往下应用了一层。这也意味着，这笔基础设施账单不会被发卡行自己的风控模型突然中断，而这确实是一种曾经真真切切让店铺下线过的失效模式。

最后，枯燥的可靠性要求，在这里也比一个博客要严格得多。一个离线的 Lightning 节点收不了款，没法监视作弊的交易对手，还可能被联系不上它的对端强制关闭通道。一个掉出链的 Bitcoin 节点，会给顾客展示一些永远没法结算的发票。不限流量的带宽，重要程度超出表面看起来的样子，因为一个真正参与网络的节点，会向其他对端提供区块数据，而一个按流量计费的套餐，会给你一张和你店铺流量毫无关系的账单。

能避免二次同步的安装顺序

几乎所有人都在用的部署方式，是官方的 Docker 发行版：一个你克隆到全新服务器上的仓库、一组描述你想要什么的环境变量，以及一个会生成 compose 文件并把整套技术栈启动起来的安装脚本。它是真正意义上的开箱即用，而安装出问题的原因，几乎从来都不是脚本本身——而是操作顺序，逼着你返工那个代价高昂的步骤。

从一台干净的机器和 DNS 记录开始。安装程序会为你提供的主机名申请一张证书，这个请求会发到一家证书颁发机构，它会通过 80 端口连回你的地址进行验证。如果记录还没解析好，或者端口是关闭的，这套技术栈就会在没有 TLS 的情况下起来，然后你就得自己去排查，三件可能出错的事到底是哪一件。先建好 A 记录，确认它能从一个不是你自己笔记本电脑的地方得到解析结果，打开 80 和 443 端口，然后才运行安装程序。

在第一次运行之前就把片段定下来，而不是等到之后。环境变量会告诉生成器：要启用哪些链、用哪种 Lightning 实现、是否修剪以及修剪的力度、要不要在明网主机之外再暴露一个洋葱服务、要配置哪种反向代理。其中好几项之后改起来代价很小；但凡碰到节点本身的那些——启用一条链、开关修剪、切换 Lightning 实现——就意味着要重新下载或者重新建索引，而重新下载正是那个会耗掉你一整天的东西。把片段列表通读一遍，慎重地做出选择，然后再运行它。

在链下载的同时，把剩下的事情都做完。创建你的商店，设置好它的货币、发票有效期，以及在一张发票被算作已结算之前你想要多少次确认——这是一个值得刻意做出的决定，因为零确认接受快，却偶尔会出错，而六次确认安全，却要花上一个小时。导入仅观察钱包。安装店铺插件，用一个限定权限范围的 API 密钥、而不是管理员账户，把它指向服务器。配置好汇率来源。给自己开一张金额微不足道的测试发票，然后用一个不在同一台机器上的钱包，分别通过链上和 Lightning 把它付掉——从来没有用真实资金测试过的部署数量，比任何人愿意承认的都要多。

然后把更新流程写下来，因为它确实存在，而且只是一条命令。这个发行版自带一个更新程序，会拉取新镜像，并按正确的顺序重启整套技术栈，而一个还在跑一年前版本的支付端点，背负着自那以后修复过的每一个 bug。把它放进日历里，运行之前先读一遍发行说明，并且先做好备份。

给一台存着钱的机器做加固

通用的建议完全适用，都写在加固清单里：用密钥而不是密码、SSH 禁止 root 登录、默认拒绝的防火墙、无人值守的安全更新，以及一份你真的会去看的日志。接下来要讲的，是专属于这台机器的部分，主题是：一个支付端点的攻击面，形状和一台普通 Web 服务器并不一样。

如果可以，就把管理界面挡在公共互联网之外。BTCPay 的管理面板，是掌控你资金的控制面——它能创建 pull payment 提现申请、更换钱包、签发 API 密钥——它没有理由要像发票页面那样，向全世界开放。把管理路径绑定在 VPN 或洋葱服务之后，或者放在一份白名单之前，能够整整去掉一类风险，代价只是你自己的操作流程里多一步。一条通往服务器的 WireGuard 隧道，是这么做里侵入性最小的一种方式。

把 API 密钥当成主要凭证来对待，而不是事后才想起来的东西，因为实际上，店铺就是靠它和结账系统对话的，攻击者也一样。每个集成发一把独立的密钥，把它的权限范围限定在对应商店、只给它真正需要的权限，把它存放在店铺的密钥配置里，而不是代码仓库中，并且在有人离职时轮换它。一把权限没有收窄的密钥，落在一台被攻陷的 Web 主机上，实际效果和直接交出管理面板没有区别。

留意这套技术栈特有的两种失效状态，因为它们看起来都不像是宕机。一个已经掉出链的节点，会继续对外提供网站服务，也会继续给顾客展示那些永远没法结算的发票。一个和自己的对端失去连接的 Lightning 节点，会继续接受链上订单，同时悄悄拒绝掉每一笔 Lightning 付款。要对照一个公开参考源监控区块高度，监控通道数量和入站余额，并且对这两者都设置告警——这正是那种没人会提前配置、直到第一次因此损失掉一整天订单才会去补上的监控。

在其他各方面，都让这台机器保持无聊。一个支付端点不适合同时用来跑你的邮件服务器、你的开发沙盒，或者给朋友们开的游戏服务器，不是因为软件之间会冲突，而是因为每多一个服务，就多一条进入的路径，也多一样升级时可能把结账系统一起拖下水的东西。如果你想要这些其他功能，再开一台小型服务器，花的钱也比你正在省下的那些交易手续费要少。

Monero，以及 BTCPay 自己不懂得说的那些币种

Bitcoin 和 Lightning 在 BTCPay 里是一等公民，还有少数几条与 Bitcoin 关系密切的链得到了直接支持。其余的一切，都要通过第二个主版本引入的插件系统才能实现，在你打算在结账页面上承诺某种支付方式之前，值得先弄清楚这中间成熟度上的差异。

Monero 是人们问得最多的一个，而它确实能用——通过一个插件实现，背后是你自己的 monerod 和一个钱包 RPC 守护进程，与 Bitcoin 技术栈并排运行。在真正要紧的地方，它的设计思路和 Bitcoin 是一样的：你运行节点，你持有密钥，软件负责监视付款。不一样的是运维成本。这是要多下载并保持同步的第二条区块链，是要多监控和更新的第二个守护进程，而且这个插件由社区维护，而不是核心团队，这意味着它的发布节奏由自己说了算。如果 Monero 对你来说只是锦上添花，就要老实权衡这一点；但如果结账时的隐私，正是顾客选择你的全部原因，那么这份麻烦就值得，这两条链之间的对比讲清楚了它们各自到底隐藏了什么。

对任何一条额外的链，通用的原则都是问自己：它出问题时，会让你付出什么代价。你启用的每一条链，都是一个可能掉队的节点、一个需要备份的钱包、一个可能过期失效的汇率来源，以及一场和付款卡住的顾客之间的支持对话。两种维护得当的支付方式，胜过六种疏于打理的方式，一个提供了某种币种、但其节点已经失步一周的结账系统，比压根没提供过这种币种还要糟糕。

还有一条人们容易忘记的正当中间路线：接受一条链，不代表你必须自己运行它。没有什么能阻止你为一条你打算低频、手动结算的链列出一个固定地址，也没有什么能阻止你把第二条链放到一台单独的机器上运行，让它的资源占用和它的故障，都和真正要紧的那个结账系统隔离开来。自建不是一个全有或全无的承诺，务实的搭建方式，通常是把一条链做扎实，其余的走人工兜底。

它的成本，对比一家处理商收取的费用

这笔账算起来出奇地简单，因为一套自建的结账系统，成本是固定的，也没有百分比抽成。一个带 Lightning 的修剪版 Bitcoin 节点，能塞进一个月租几十美元出头的套餐里；一个想要更多余量、流量更大的店铺，会用高出一到两档的套餐。链上付款的成本是网络手续费，由顾客承担；Lightning 付款的成本是一笔以几分之一美分计的路由费。没有按笔交易抽成，没有月度最低消费，没有结算延迟，也没有交易量分级。

相比之下，一家托管的加密货币处理商，通常会从每笔交易里抽走大约 1%，而一家银行卡处理商，则会抽走大约 2.5% 到 3%，外加每笔交易一笔固定金额。月交易额 1,000 美元时，1% 就是 10 美元——和服务器成本相当接近，这时自建更多是出于原则、而不是出于经济账上划算，两者大致打平。月交易额 20,000 美元时，处理商会抽走 200 美元，而服务器成本依然是那 20 美元，该怎么选，答案自己就出来了。对大多数店铺来说，这个交叉点落在几千美元这个区间的低端，超过它的部分，都是净赚的利润。

账单上不会出现的那部分成本，是你的精力投入。安装大概要花一个下午，等链同步要花一天，之后每个月，更新、备份、扫一眼监控大概要花一个小时左右——外加每年总有那么一个不太愉快的下午，赶上东西偏偏在不凑巧的时候出问题。如果按你的时薪算下来，这比手续费还贵，那诚实的答案就是去付那笔手续费。没有人应该出于意识形态就去自建一套支付技术栈，却让自己真正的生意在一旁干等着。

这张表旁边还得加一条提醒，因为不说出来就是不诚实。这个对比的前提，是你乐意持有你收到的东西。如果每一笔款项都必须在当天变成银行账户里的法币，你就等于把一家交易所重新引入了这个流程，而交易所有它自己的手续费、自己的身份要求、自己的自由裁量权。自建结账系统去掉的是处理商。它去不掉银行，而从这套方案里获益最多的店铺，往往是那些至少把一部分收入，继续以收到时的那种币种保留下来的店铺。

什么时候你不该自建这一套

有些情况下，正确答案就是压根不要做这些事，而一篇从不这么说的指南，其实是在卖东西。如果你的月交易量小到，处理商抽走的百分比，还比不上服务器本身的成本，这笔账就算不过来——先用托管方案起步，等数字发生交叉时再迁移。如果你团队里没有人能自在地面对一个 shell 提示符，就别把结账系统，当成学这门手艺的地方；一个你没法排查的支付端点，比一笔让你不甘心的手续费还要糟糕。

如果你真的需要当天就把法币结算进银行账户，自建解决的是你问题里错的那一半。你想去掉的那个处理商，同时也是负责做货币兑换和银行转账的那个东西，替换掉它，就意味着要加入一家交易所，而它会索要那些你本来就想避开的身份证明文件。为了托管保障，这可能依然值得，但要清醒地认识到：KYC 只是转移了地方，并没有消失。

如果你的负载是那种波峰式的、一旦停机就是灾难的类型——一次上线、一次抢购、一场有截止日期的众筹——那就要仔细想清楚，是否值得赶在那个截止日期之前，去做你人生中第一次自建部署。先让它和别的方案并行跑一个周期，用小额真实付款去检验它，等它证明了自己，再让它去扛那个真正要紧的日子。以后再迁移，是一个已经有解的问题；在你最忙的那个小时才发现它的失效模式，可不是。

对其他所有人来说——交易量稳定的店铺、一个能自在使用终端的运维者、一家宁可自己持有密钥、也不想和风控部门扯皮的企业——这是少数几个能真正靠省下的现金、而不是靠原则来回本的自建基础设施项目之一。这套技术栈已经成熟，部署就是一个脚本，失效模式已知且都写了下来，唯一一个真正毫不留情的，就是这篇文章开头那条 Lightning 回滚规则。把那一条做对，剩下的就都是寻常的系统运维工作。

如果你想开始动手，开通一台服务器大约只需要一分钟，在你读完剩下的文档时，链也会一直在忙着同步。如果你的计划里有 Lightning，就选一个内存有 8 GB 的套餐，把它放在有人问起刁钻问题时，你真正希望它所在的那个司法管辖区，并且用你即将开始接受的那同一种币种，为它付款。