BTCPay Server

以网上书店为例：顾客选择比特币后，BTCPay Server 创建一张 invoice，也就是要求支付指定金额的付款单。付款页面根据商店配置显示比特币地址或 Lightning 付款请求。软件跟踪到账情况，并将状态变化通知接入的网店。店主不必再手工辨认每笔钱对应哪个订单。它也可用于实体收银台或募捐。开放源代码让人们能够检查和修改程序，但仅凭代码公开，不能证明某个实际部署是安全的。 [1]

对于已有钱包，服务器可以取得扩展公钥，用它推导收款地址。允许转出资金的私钥则可以留在服务器之外，例如保存在硬件钱包里。热钱包的安排不同：秘密数据直接存放在联网设备上。用于快速付款的 Lightning 节点访问权限，也可能允许花费节点资金。因此，管理服务器和控制资金是两个不同的问题。self-hosted，也就是自行部署，并不能自动回答这两个问题。 [2] [3]

使用他人的服务器可以省去安装和维护工作。不过，即使款项直接进入自己的钱包，你仍依赖服务器管理员。被篡改或入侵的服务器可能展示攻击者的地址，而不是你的地址。仅取得公钥并不能花掉先前已到账的币，但被替换的收银页面可能把未来付款导向别处。因此，也要在独立的钱包中核实收款。自己的服务器遭入侵时同样存在这种风险；外部托管方还会影响服务可用性和付款隐私。 [4]

书价可以用捷克克朗标示，而顾客用比特币支付。Invoice 在有限时间内锁定汇率和应付金额。Processing 表示要求的金额已全部支付，但仍在等待结算条件，例如区块确认。Settled 表示条件已满足；Lightning 付款通常不必等待区块。商家还要处理少付、多付和迟付。手工修改状态不会产生网络确认。同样，把显示的价格换算为比特币，不会向你的银行账户汇入克朗。通过插件或服务商兑换，是另一个有自身条件和费用的服务。 [5] [6] [3]

程序通过 Greenfield API 相连，这是供程序交换信息的接口。网店把 invoice 标识与订单一起保存。Webhook 是服务器自动发送的消息，用来报告状态变化；网店必须按文档验证其真实性。API 访问密钥只应获得该商店实际需要的权限。同一条消息重复到达，不能导致再寄一本书。顾客返回感谢购买页面，也不等于商店确实收到付款。发生故障后，应将本地记录与付款单状态及实际到账情况核对。 [7]

Lightning Network 使用支付通道，因此不必将每笔付款单独写入区块。自己的节点需要保持可用，并拥有入站流动性，也就是通道中允许资金流向你的空间。这需要持续管理。你可以购买流动性服务、使用不同支付网络之间的兑换，或者采用由服务商控制客户资金的托管服务。这些选择的权限、费用和风险并不相同。付款页面上的 BTCPay Server 名称，既不能说明商家采用哪种方案，也不能保证每笔付款都成功。 [8]

钱包恢复信息不是整个商店的备份。除了密钥，还需要付款单记录、配置以及具体部署所需的其他数据。对于 Lightning，使用旧通道状态启动节点尤其危险：错误恢复可能危及资金。有计划地迁移服务器，与故障后的恢复不同。迁移过程中，原节点不能继续改变状态，也不能与恢复后的副本同时运行。应遵循所用实现的具体流程。测试 Lightning 恢复时，要隔离网络和对等节点，避免测试影响正在使用的通道。 Docker 是把应用组件放在独立容器中运行的环境；相应的备份指南适用于这种部署方式。 [9]

好处是可以决定如何构建自己的支付基础设施。但仍要有人负责更新、管理员访问、暴露在互联网上的服务以及可以实际恢复的备份。软件不从每笔付款中抽成，但托管、硬件、网络手续费或 Lightning 支持可能收费。不要保存不必要的顾客个人信息。如果书丢失或被退回，应由商家处理投诉和退款，BTCPay Server 开发者不负责裁决这笔交易。付款单记录有助于记账，却不能替代所有会计义务。 [10] [3] [7]