交易检测、链上确认、订单关联和服务交付是相互独立的步骤。请核实正确的链、资产、收款方和金额；应用有据可查的受理策略；并确保对账具有幂等性。仅凭交易参考号、截图或浏览器按钮，无法证明某一特定订单已付款。
将链上事件与订单事件分开
钱包报告已发送转账，只是关于其自身操作的证据，而非完整的付款判定。接收方后端必须观测预期网络、核实实际转账并将其与订单关联。只有到那时，订单才能应用其受理策略。基础设施交付是付款受理之后的另一个运营步骤。
请在代码和面向客户的语言中明确这些状态转换。界面可以显示等待、已检测或确认中，而不将订单称为已付款。不要让浏览器提供已受理金额或覆盖权威状态。请存储服务器创建的报价及其说明，以便后续对账时能够依据原始订单而非不断变化的购物车进行评估。
使用特定于链的置信规则
不同网络对交易置信度的描述方式各不相同。Bitcoin 的开发者指南解释了节点如何选择累计工作量证明最多的链，以及竞争区块如何产生。因此，对于近期观测到的交易，需要制定确认深度和可能链变更的策略。并不存在适用于所有资产和商业风险的单一确认数。
Ethereum 的权益证明文档解释了检查点最终性，而 Solana 记录了已处理、已确认和已最终确定的承诺状态。不要草率地将这些术语统一翻译成一个通用的区块数。请记录特定于网络的规则、信息来源以及不确定期间的行为。运营方应根据付款和交付风险确定受理阈值，而不是照搬无关结账流程中的数字。
验证实际转账负载
请在正确的链上识别收款方、资产和金额。代币付款需要确认预期的代币身份，而不仅仅是向某地址成功发起了一笔交易。请根据该链的模型核实相关执行是否成功以及转账证据。请按资产应有的精度解析整数金额，而不要信任浏览器提供的格式化小数。
付款指令必须始终绑定其原始路径。在其他网络上的转账、符号相同但实际不同的代币，或无关的交易参考号，都不应满足该指令。核实记录应说明检查了什么，并保留复核该决定所需的证据。本指南描述的是通用付款对账原则，而非某一特定服务的实现。
使订单关联无歧义
固定收款地址可能收到多笔金额相近的订单。存在一笔匹配的转账，并不能证明应记入哪位客户或哪个订单。请在受理真实付款前定义关联方法，并纳入冲突处理。用户提供的交易参考号仍需验证，确认同一笔转账尚未被分配到其他地方。
设想在重叠时间窗口内，同一路径上有两张金额相同的发票。监视器看到了一笔转账。自动将两者都标记为已付款是错误的；在证据不足的情况下选择其中一个同样不安全。请将该笔转账保持为未分配或待审核，直到运营方策略能够建立有效关联。模糊匹配是一种需要处理的状态，而不是凭空制造确定性的理由。
定义能容忍延迟和变化证据的状态
付款流程受益于少量清晰的状态，并将链上证据与受理订单的决定分开。此示意表解释的是可能存在的阶段，而非描述某一特定服务的状态名称。每次状态转换都应有经过核实的原因，且付款受理应与基础设施交付保持区分。
请纳入延迟、部分和超额转账、报价过期以及链上数据暂时不可用的情况。过期并不会让真实转账消失。延迟付款可能需要审核，而不是自动受理或拒绝。如果先前观测到的链上事件发生变化，请根据有据可查的策略重新评估状态，而不是将每条监视器通知都视为不可逆的事实。
| 示意状态 | 含义 | 下一步决定 |
|---|---|---|
| 等待中 | 未核实到符合条件的转账 | 继续观测有效发票 |
| 已检测 | 观测到相关转账 | 检查链上置信度和关联 |
| 确认中 | 尚未满足受理规则 | 持续观测，直到策略允许作出决定 |
| 审核 | 延迟、部分或模糊证据 | 根据运营方策略解决 |
| 已受理 | 已核实并对账的付款 | 进入独立的交付工作流 |
使重试安全且可观察
监视器和对账任务会在连接中断或进程重启后重试。请使用稳定的转账标识，例如链和相应的交易或转账标识符，以防止重复入账。请持久化进度和决定，以便同一事件可以再次处理，而不会重复开通服务或更改已受理的报价。
请区分未知结果与操作失败。如果下游请求超时，请在重新提交前检查其权威结果。请保留已受理和不确定操作的持久记录。请限制对订单令牌和内部证据的访问，同时保留足够信息以调查有争议的付款。这里的可靠性指的是可重复的决定，而不是结账流程中流畅的动画。
了解待处理订单仍需要什么
订单可能仍处于待处理状态，因为尚未观测到转账、尚未达到所需的链上置信度，或其与发票的关联需要审核。请保留发票和公开交易参考号，检查所述受理规则，并使用该订单指定的协助流程。状态更新延迟本身并不是再次付款的理由。
请遵循实际订单的说明和已核实状态。付款确认应表明已受理对账后的转账，而服务交付有单独的状态。请勿在求助请求中泄露私有访问令牌和钱包密钥。
您的实用清单。
- 持久化服务器创建的不可变报价。
- 核实链、收款方、资产和整数金额。
- 记录特定于链的受理规则。
- 处理固定地址冲突时不要猜测。
- 防止重复入账和不安全的重新提交。
- 测试延迟、部分、错误路径和证据变化的情况。
重要细节。
交易哈希足以确认付款吗？+
不能。请在预期链上核实转账、其载荷和置信度，然后确认它属于该订单且尚未被入账。
每个网络都能使用相同的确认阈值吗？+
不能。各网络提供不同的置信度和最终性模型。运营方必须为每条路径定义并测试适当的受理策略。
确认付款就意味着服务器已开通吗？+
不是。付款受理和交付是相互独立的工作流事件。请通过其自身的权威流程传达开通状态。
前往来源。
这些参考资料支持本指南中的技术概念。在更改生产系统之前，请遵循当前文档。
- Bitcoin 开发者指南：区块链行为 developer.bitcoin.org
- Ethereum：权益证明与最终性 ethereum.org
- Solana：RPC 状态承诺 solana.com
由 SwissOctet 提供编辑指导。示例仅作说明。服务规格、可用选项和合同条件必须单独核实。