Bitcoin Payment Processor

假设顾客在网上买了一本书。商店向处理器申请 invoice，也就是注明金额和币种的付款请求，再把请求标识符与订单号一起保存。顾客打开支付页面或扫描二维码付款，商店便能根据保存的关联判断钱属于哪次购买。如果没有这种关联，只知道某处收到比特币还不够。顾客返回“感谢购买”页面，也不能证明商店已经收款。 [1]

BTCPay Server 可以根据已有钱包的公开数据生成收款地址，无须取得能支配资金的私钥。这与把密钥保存在服务器上的热钱包不同，也不同于获得处理快速付款的 Lightning 节点资金的访问权限。采用服务时，提供商可能在拨款前控制资金。因此，仅看 non-custodial，也就是不把密钥交由提供商保管的标签，并不足够。还要确认实际权限、谁能转走钱，以及取回资金是否需要别人批准。 [2] [6]

书价可能以普通货币标注，而顾客发送的是比特币。BTCPay Server 因此会在付款请求中限时确定金额和汇率。过期不会阻止迟来的转账到账，商店仍须正确处理；少付和多付也一样需要处理。原始金额与汇率应保留用于核对账目。即使书价未变，汇率变动后创建的新请求，也可能要求不同数量的聪，即比特币的最小单位。 [3]

在 BTCPay Server 中，Processing 表示要求的金额已付足，但完成条件尚未满足，例如交易仍在等待区块确认。Settled 表示条件已经满足；Lightning 支付通常不需要等待区块确认。其他服务对状态有自己的定义。BitPay 明确提醒，paid 并不是付款保证。因此，发货规则应依据所选服务的文档和支付方式制定。手动把订单改成“已支付”，不能代替核实实际付款。 [3] [5]

处理器通过 webhook，也就是服务器之间的自动消息，报告状态变化。商店需要验证来源和内容。BTCPay 使用共享秘密，对消息的原始字节计算 HMAC-SHA256；这是认证码，并非比特币网络确认。BitPay 不为 IPN 通知签名，通知只应触发通过 API 查询真实状态；API 是程序之间通信的接口。消息可能重复送达，所以商店必须记录订单已处理，避免再次发货。故障恢复后，还应把保存的状态与处理器核对。 [4] [5]

收到顾客付款与收到服务商拨款，是不同事件。BitPay 允许设置受支持的结算币种，以及银行账户或加密货币地址；变更可能需要批准。商家还应了解时间、限额、费用，以及拨款前由谁控制资金。如果直接收进自己的钱包，可能没有这个中间环节。销售系统需要区分这些模式，避免“已支付”让人误以为资金已经可以使用。 [6] [2]

退款不会抹掉原来的比特币交易。商店先处理顾客请求，确定退还金额和币种，核实收款人，再安排一笔新付款。用于申请退款的链接，并不代表钱已发出。记录中应保留订单、付款请求、收款、汇率、费用和退款。导出报告有助于记账，但不能独自满足所有当地义务。网络确认也不会裁定交货纠纷，更不会取消处理投诉时的合同或法定义务。 [7] [8] [10]

上线前只做一次成功的试购不够，还应测试少付、迟付、重复通知和故障恢复。API 密钥是程序的访问凭证，只应授予对应商店所需的权限。附带信息不应包含多余的客户个人资料。自行运行需要承担托管、更新和支持工作；Lightning 还涉及流动性管理，即支付所需的资金和通道可用空间。免费软件并不等于免费运营。可用性、密钥保护和商店集成是否正确，应分别检查。 [1] [9]