亲自收下这笔款项。
已经没有谁能冻结它了。

区块链上的一笔付款，不需要中间有一家公司。客户签署一笔交易，网络对其进行确认，钱就是您的了——这中间没有收单机构，没有结算周期，也没有谁的批准是这笔付款所依赖的。这正是这项技术的全部意义所在，也是它存在的理由。

然后，一个店铺需要真正能收到款，而一堆现实的要求也随之一拥而上。每张发票都需要自己专属的地址，这样才能把不同的付款区分开。得有人监视链上动态，判断一张发票何时算作已付。金额得用客户习惯的货币报出来，而且汇率得保持足够长的时间，好让对方按下发送。订单状态得回流到店铺里。而且这一切还得在凌晨两点、没人盯着的时候照常运作。把这些都搭起来是一个项目；不去搭建它，正是几乎所有人转而注册一个托管网关的原因——而这样做，也就在一张表单的篇幅之内，把一个本来设计成不需要中间人的系统，重新塞进了一个中间人。

这个中间方到底握着什么，值得说清楚，因为远不止手续费这一项。它握着您的币，至少在提现完成之前是这样，这意味着它可以拖延一次提现。它握着那份名单：每一位客户、每一笔金额、每一个时间戳、每一件商品，全都存在一个您既读不到也删不掉的数据库里。它握着您的身份文件，因为一家经手他人资金的公司被要求收集这些信息。它还握着那个开关，因为服务条款保留了随时认定您的生意不再受欢迎的权利——这个决定会通过邮件通知您，既影响账户也影响余额，而且实际上根本无法申诉。

BTCPay Server 正是针对这一个问题、而且仅仅针对这一个问题的答案。它是一款免费、开源的支付处理器，运行在您自己的机器上：为每张发票派生一个地址，监视链上动态，报出法币价格，对外提供一个结账页面和一个 API，并且支持 Lightning。它从不持有您的币，因为它监视的钱包本来就是您自己的。接受加密货币付款有四种方式，各自的实际代价如下：

第二列也不是在开玩笑——作为一个捐款链接，页脚里放一个地址真的完全没问题，假装并非如此只会把没人需要的软件卖给别人。但一旦有两个人在同一天付了同样的金额，或者一旦您不希望自己的年收入变成任何人都能加总出来的公开数字，这种做法就不再没问题了。

下单购买服务器。在控制面板中：Order → VPS → Garrison，镜像选 Debian 12，机房选您希望店铺数据所在的那一个——赫尔辛基、斯德哥尔摩、奥斯陆或雷克雅未克。Garrison 是正确的默认选择，因为它能装下一个 100 GB 的裁剪链、一个 Lightning 节点和数据库，让您未来多年都不用再操心磁盘。Sentinel 配合更紧的裁剪也能用；Bulwark 则是归档节点该选的套餐。开户不需要邮箱地址，账单可以用 Monero、Bitcoin、Lightning 或其他支持的资产结算——这正是这个项目讨人喜欢的地方：您在搭建一台用来收加密货币的机器，而付款用的也正是加密货币。

然后，在做任何其他事情之前，先跑一遍首小时加固清单——把 SSH 换到一个新端口并且只用密钥登录、开启无人值守升级、配置默认拒绝的防火墙。这台服务器早晚会保存您每一位客户的记录，以及一个持有真实资金的 Lightning 节点的密钥材料。这不是一台可以留着密码登录、放上一周不管的服务器。

接下来是 DNS 记录，请务必在运行安装程序之前完成，而不是之后。选一个结账页面要用的主机名——shop.example.com、pay.example.com，怎么合适怎么来——然后把一条 A 记录指向这台 VPS 的地址；如果希望通过 IPv6 访问，再加一条 AAAA 记录。让它完成传播。安装程序配置的反向代理，会在第一次启动时尝试为这个确切的名字获取证书，使用的是一种要求该名字已经解析到这台机器的 HTTP 验证方式。一条尚未生效的记录，是首次安装以一个令人困惑的错误收场的最常见原因，没有之一。

然后，趁现在还没有任何服务在监听，先把防火墙规则写好。四个端口，只有四个。结账页面出于必要必须是一个公开的 HTTPS 端点——客户的浏览器得能访问到它——而 80 端口也得保持开放，因为证书续期要用到它。Lightning 的点对点端口，只有在您希望其他节点能向您开通道时才需要，而步骤 05 会论证您确实需要这样做。Bitcoin 的点对点端口则完全不需要开放：您的节点自己发起出站连接就运作得很好，把它对内开放，只会让别人更容易找到它。

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved off 22
ufw allow 80/tcp                     # ACME HTTP-01 challenge and the redirect
ufw allow 443/tcp                    # the checkout
ufw allow 9735/tcp                   # Lightning peer-to-peer, only if you want inbound channels
ufw enable
ufw status numbered

在继续之前，还有两条关于资源的提醒。如果服务器没有交换空间，先给它加一个——初始区块下载是这个项目里最吃内存的一段时间，4 GB 内存搭配 2 GB 交换空间，表现会比单独 4 GB 内存好得多。另外，请把步骤 01 里算出来的磁盘需求，和您实际购买的套餐对一遍，因为一个在同步过程中写满卷的节点不会体面地失败；它会直接把自己的索引弄坏，然后从头再来。

fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
df -h /                              # confirm the volume matches step 01

创建一个店铺，然后在这个页面上做出唯一真正重要的决定。BTCPay 会提供两种接入 Bitcoin 钱包的方式：连接一个已有的钱包，或者让它生成一个新钱包并把种子留在服务器上。前者是只读的，也正是您想要的。后者会把一台公开暴露在互联网上的机器，变成一个持有您全部营收的热钱包——不管做多少加固，对一台唯一任务就是要能被陌生人访问到的服务器来说，这都不是一笔划算的交易。

这项建议背后的机制足够精妙，值得弄懂。现代钱包是分层结构的：一个种子派生出一整棵密钥树，其中有一个扩展公钥——一个 xpub，或者面向原生 segwit 的 zpub 变体——账户里的每一个收款地址都可以由它计算得出，却完全没有签名能力。把它交给店铺，店铺就能为每张发票生成一个全新地址，监视每个地址上的付款，并显示余额给您看。它无法转移哪怕一枚聪。私钥那一半，始终留在您的钱包或硬件设备里，从不外传。

所以：打开 Sparrow、Electrum，或者您硬件钱包的桌面应用，创建一个专门用于这家店铺的新账户，并导出它的扩展公钥。在店铺的钱包设置里选择连接一个已有钱包，粘贴这把密钥，然后把 BTCPay 派生出的头几个地址和您钱包里显示的地址对一遍。如果能对上，说明派生路径正确，连接就完成了。如果对不上，说明您选错了脚本类型——xpub 和 zpub 之间的差别，就是两组完全不同地址之间的差别。

接下来是发票设置，这才是真正调校一家店铺的地方。有效期默认大约十五分钟，锁定的是汇率而不是什么技术上限：它代表您愿意为一项以法币计价的价格、对抗一种波动资产，锁定多长时间。市场波动大就调短，客户手脚慢就调长。确认数决定一张发票何时算作已结算——零确认是即时的，适合一杯咖啡这种场景；一个确认是通常的默认值；六个确认则用于那些金额较大、多等一个小时比冒险划算的场景。少付容差让您可以接受一张金额差一点点的发票，这种情况其实很常见，因为有些客户的钱包会从金额里扣手续费，而不是额外加上去；在这里设一个小百分比，就能省掉一整类支持邮件。

然后用真钱测试它，而不是测试网。开一张金额微不足道的付款请求，用手机钱包付款，看着这张发票从「新建」变成「处理中」再变成「已结算」。这一笔交易就能同时证明：节点已经同步完毕，派生路径正确，汇率来源正常工作，证书在手机浏览器上有效，而且钱确实落进了您掌控的钱包。没有别的办法能一次性证明这五件事。

挑一个和您现有条件相匹配、尽可能简单的收款界面。付款请求是一个可以发给别人的链接——不需要网站，是给客户开发票最快的方式。收银台应用能把同一个实例变成一台带商品列表的收银机，在集市摊位上用手机就能操作。支付按钮是给静态网站用的一段 HTML 代码。店铺插件能把 Bitcoin 添加为真正店面结账时的一种支付方式，并自动回写订单状态。而 REST API 可以开具发票、报告其状态，并在结算时调用 webhook——这是最经得起时间考验的集成方式，因为它只依赖 HTTP 和一个共享密钥，别无其他。

不管选哪一种，都要把 webhook 接好，并测试它确实会触发。一张已经结算、却从未通知您应用程序的发票，是那种没人会发现的故障模式，因为从两边分别看，一切都显得正常：钱到账了，客户也看到了确认页面，而订单就那么悬在那里没人处理。请故意给自己发一个「发票已结算」的 webhook，确认您的端点收到了它，并且验证签名，而不是直接相信收到的内容——毕竟这个端点是公开的，任何人都能向它发送数据。

理解了这一点之后，日常流程其实很简短。这套部署自带一个备份脚本，会归档各个卷、导出数据库，同时跳过区块链数据本身，并且接受一个密码短语，让归档在离开服务器之前就完成加密。请定时运行它，然后按照备份指南里说的方法，把结果推送到位于另一个司法辖区的机器上——这里多花十分钟配置一个仅追加式的仓库是值得的，因为一台被攻破的支付服务器，不应该有能力抹去它处理过的记录。

cd ~/BTCPayServer/btcpayserver-docker
export BTCPAY_BACKUP_PASSPHRASE="a long passphrase you keep elsewhere"
./btcpay-backup.sh                   # archives volumes + database, skips the chain
# then ship the archive offsite, and keep the channel backup separately

接下来是升级，而支付服务器正是那种「以后再更新，但要刻意为之」才是正确策略的机器。这套部署自带更新脚本，能重新生成 compose 文件并拉取新镜像；请在读完发布说明之后再运行它，而不是等某个定时任务觉得该更新了就跑。先做归档。一次只升一个版本。并且把上一个版本号记下来，因为一分钟就能完成的回滚，才是让整件事风险可控的关键。

./btcpay-update.sh                   # deliberate, after reading the release notes
df -h /                              # the check that should be an alert, not a habit

最后，设置一个警报和一个提醒。警报针对磁盘用量——区块链节点是机器上唯一会自行不断膨胀的进程，一旦卷写满，结账系统就会瘫痪，而且因为其他任何东西都没变，这种故障往往很难诊断。请把阈值设在 80%，而不是 95%。提醒则是按月的，用来打开店铺检查两件事：发票是否仍在正常结算，以及您开设的 Lightning 通道是否仍然存活。支付处理器出故障时是悄无声息的，您发现的方式，往往是某个客户告诉您他付不了款。