界定钱包边界
仅观察钱包可以在不持有私有支出密钥的情况下检测付款。扩展公钥仍会泄露敏感的 wallet 活动，应加以保护。Lightning 集成可能需要在线钱包，并引入额外的运营风险。
为完整技术栈规划容量
Bitcoin 后端、数据库、Web 服务和可选的闪电节点具有不同的存储和内存需求。在选择小型机器前，请查看当前支持的部署说明和增长需求。
保护商户接口
使用专用主机名、HTTPS、强登录保护和受限的管理访问。保持服务器更新，并在接收应用程序中验证 webhook 签名或受支持的验证机制。不要仅凭浏览器重定向就发货。
备份并核对
根据相关文档保护商店配置、数据库、钱包恢复信息和 Lightning 专用材料。测试恢复流程，并将发票与支付系统核对，尤其要关注到期、少付和退款情况。
检查部署与链策略
使用当前受支持的部署说明、专用主机名和经过验证的 HTTPS 路由。在支持的情况下，修剪链可以减少持续的存储需求，但必须理解重新扫描和恢复需求。不要仅根据当前链大小选择磁盘；为完整堆栈和增长留出空间。
- 通过外部测试验证支付回调
- 在正式商店上线前使用测试支付
- 确认发票结算政策
官方文档：BTCPay部署选项
将支出密钥保存在你预期的位置
仅观察设置可以从扩展公钥检测付款，而无需将支出密钥交给服务器。xpub 是敏感的，因为它可能泄露钱包活动。热钱包通过将支出能力置于线上而改变了这一风险。分别审查钱包和 Lightning 托管，并遵循受支持的备份流程。
官方文档：BTCPay 钱包模型
围绕所选技术栈构建部署清单
首先准备专用域名、受支持的部署方式、预期的链模式，以及足以完成同步的磁盘空间。安装前请查看上游 Docker 生成器及其所选组件；保留非机密的部署选项，以便另一台机器能够一致地重建。向客户展示结账页面前，请检查域名解析、证书签发和管理账户所有权。通用的 Docker Compose 示例并不能证明每个可选 BTCPay 组件都已配置。
- 确定由哪个实例所有者控制更新、监控、备份和事件响应。
- 将反向代理暴露与私有 Bitcoin RPC、数据库和 Lightning 管理分开。
- 在连接具有历史付款的钱包之前，记录修剪后端的恢复/重新扫描限制。
- 在履行高价值订单前，为集成保留受支持的测试环境或小规模受控付款演练。
在不导入助记词的情况下排查缺失的钱包付款
商店可以使用钱包的 xpub/派生信息，而支出密钥保留在另一台设备上。请用所选钱包测试接收和恢复路径。如果 BTCPay 看到发票付款，但外部钱包未显示该笔款项，请先检查其派生方案和地址间隙限制行为，再假定资金已消失。长时间生成大量未付款地址可能影响钱包的发现过程。请使用受支持的钱包诊断功能，而不要将恢复词复制到服务器中。
履约前核对发票
记录发票标识符，并使履约操作具备幂等性。浏览器返回商店只是导航事件，不是结算证明。通过经过身份验证的服务器集成核实支付状态，明确处理已过期、延迟或支付不足的发票，并为未解决的结果保留复核路径。如果回调重复，返回成功确认不得导致订单重复发货或重复入账。
- 测试一笔临近到期时到达的付款，并验证订单仍与正确的发票关联。
- 将数据库、商店配置和钱包恢复材料保存在经过测试的独立备份中。
- Lightning 增加了独立的流动性和通道备份责任；恢复昨天的整个 VPS 并非安全的通用恢复流程。
- 托管 BTCPay 实例不会为 KoalaVPS 客户结账添加 Lightning 或 XMR；本托管网站上的支付方式仍为其七种已公布的路径。