支付确认是一项信心阈值，而不是通用的区块数量
区块链支付并不会在所有网络中同一时刻完成。交易首先被观察到，然后可能进入区块、获得更多网络支持、达到该协议定义的最终确定性，最后满足商户的支付接受规则。
这些阶段回答不同问题。检测判断是否有人看到了候选交易；确认衡量网络在多大程度上支持它当前的位置；最终确定性表示撤销这一历史需要多么异常的故障或高昂代价；业务验收则判断这些证据能否支持发货、账户入账或其他操作。
本文聚焦链上信心转变为商户决策的边界。Blockchain Payments 讨论从网络交易到商业支付的完整模型；Blockchain Consensus 解释网络如何达成共同接受的历史。
可见、打包、确认、最终确定和业务接受是不同状态
钱包、区块浏览器、节点、支付网关和商户后台可能以不同含义使用“已确认”。可靠系统必须明确规定自己的状态含义，而不是直接采用某个界面的笼统标签。
- 广播：钱包提交签名交易，但网络未必已经接收或传播。
- 检测：一个或多个观察方看到了交易；它仍可能被替换、丢弃或延迟。
- 打包：交易出现在提议或接受的区块中；最新一段链上历史仍可能调整。
- 确认：网络提供更强支持，例如更深的区块、验证者投票或特定承诺级别。
- 最终确定：按照协议的安全假设，逆转历史需要极端共识失效或严重经济损失。
- 商户接受：支付系统已核实金额、资产、网络、时间、订单、风险以及履约规则。
客户说“交易已经上链可见”可能完全正确；商户继续显示“等待确认”也可能正确。双方反映的是不同层级的事实，而不一定是矛盾。
本节资料: OxaPay
确认主要降低近期链上历史不稳定与分叉竞争的风险
网络节点有时会暂时对最新有效历史产生分歧。如果几乎同时出现两个合法区块，分叉选择与最终确定规则会决定哪一段历史最终成为规范链。
链重组是指以另一条分支替换近期历史。交易可能被纳入其他区块、重新回到内存池；如果冲突花费被接受，也可能从规范链消失。更深的确认和更强的最终确定信号可降低这种风险。
比特币通过累积工作量证明提高改写历史的成本。比特币白皮书解释了诚实链继续增长时，攻击者追上的概率会下降，但这并不意味着所有金额都适合同一确认数。内存池是本地且非永久的；被弃用区块中的交易有时会重新进入内存池。
不同网络通过本质不同的机制建立最终确定性
“最终确定性”并非单一算法，而是网络在其协议与信任模型下能够提供的最强不可逆转保证。将其映射为商户决策之前，应先理解保证的来源。
- 概率型最终确定性：随着更多规范区块叠加，逆转概率下降、成本上升，但不存在全局通用的绝对时刻。
- 投票或检查点最终确定性：达到要求的验证者超级多数固定某些检查点；逆转往往需要严重违规或重大经济损失。
- 分层最终确定性：快速的本地反馈与更强的基础链结算发生在不同阶段，可能包含排序器、批次数据发布、证明和主链确认。
以太坊将链头选择与检查点最终确定分开。Gasper 通过获得三分之二质押权重支持的链接来证明并最终确定检查点，因此 Head、Safe 和 Finalized 不能混为一谈。经济最终确定性强于普通打包，但不等同于银行退款或法律上的撤销保障。
本节资料: Ethereum.org
多链支付系统必须翻译不同网络的信心表达方式
各网络使用自己的术语和数据结构。统一的商户支付状态很实用，但适配器必须保存产生该状态的原生链上证据，不能假定所有协议提供同样的保证。
| 网络 | 早期信号 | 更强信号 | 业务解释 |
|---|---|---|---|
| 比特币 | 内存池可见或首次打包 | 确认深度增加 | 信心具有概率性，应与支付风险相匹配。 |
| 以太坊 | 近期链头或一般打包 | Safe 与 Finalized 检查点 | 最终确定的加密经济保证强于近期区块包含。 |
| Solana | Processed | Confirmed 与 Finalized | Processed 反馈快，但遇到分叉可能被丢弃。 |
| TON | 待处理或已确认消息轨迹 | 由主链引用支持的最终确定性 | 需要跟踪异步消息及完整轨迹的最终结果。 |
Solana 官方文档区分 Processed、Confirmed、Finalized，并指出仅处理的交易仍有被分叉抛弃的可能。TON 的支付流程强调异步消息轨迹与主链引用。标准化标签应保留这些差异。
本节资料: Solana Docs · TON Docs
正确的确认阈值取决于商户可能承担的损失
并非每笔支付都必须等待最强最终确定性；关键是业务动作所需的充分信心。更长的等待有时降低链上风险，却也可能降低结账完成率、服务开通速度和客户信任。
- 金额风险：金额越高，通常需要更强证据和更审慎的异常处理。
- 履约可逆性：可撤销账户权限与无法收回的数字商品、已寄出的实体货物不同。
- 网络证据：区块深度、验证者投票、链的正常运行情况及重组信号必须按具体网络解释。
- 时效要求：零售结账、即时开通、B2B结算和资金管理的可接受延迟不同。
- 异常情况：少付、错误网络、过期、重复交易即便已最终确定，仍需独立处理。
“六次确认”是比特币历史上常用的更深信心标准，并不是适用于所有商户和所有区块链的法则。可撤销的小额信用与不可逆的大额企业交付需要不同策略。
本节资料: OxaPay
内存池检测改善用户反馈，却不意味着已经结算
在交易打包前显示“检测到支付”能及时回应客户；但若直接将同一信号当作不可逆履约指令，就会引入明显风险。
不存在所有节点共享的唯一全球内存池。节点的连接、接纳策略与本地视图不同。低手续费交易可能延迟、从部分节点消失，或被与之冲突的交易替换。
更具竞争力的手续费有助于提高及时打包概率，却不能证明订单匹配或支付达到最终确定。OxaPay 关于内存池与交易延迟的文章解释了相关机制。
确认引擎把协议证据转化为受控的业务决定
生产系统不应只读取一个浏览器的标签就完成订单。它需要收集可靠证据，校验预期支付，执行商户规则，并保存状态变化的理由。
- 观察：获取交易、区块、承诺级别和网络健康指标，并记录来源与时间戳。
- 链状态解释：将 Processed、Included、Safe、Finalized 和区块深度映射为统一的信心证据，同时保留关键差异。
- 支付校验：比对资产、网络、金额、目的地址、订单和时间；最终确定的交易也可能属于错误支付。
- 策略评估：根据金额、可逆性、网络状态及异常确定所需阈值。
- 受控状态更新：只执行一次可审计的幂等业务转换，避免重复轮询或Webhook导致二次发货。
Real-Time Monitoring 深入讨论多节点观察、事件采集与遗漏恢复；完整支付状态机还需要单独设计。本文关注二者之间的确认决策。
本节资料: OxaPay
二层网络可能快速给出本地确认，却更晚继承主链最终确定性
Rollup 交易可以先获得排序器即时回执，随后纳入数据批次并发布，最终依赖基础链得到更强结算保证。各阶段的信任假设并不相同。
Optimism 文档定义 Unsafe、Safe 与 Finalized。Unsafe 表示已本地执行但尚未写入一层；Safe 已写入一层，却仍受一层重组影响；Finalized 则依赖已最终确定的一层历史。
Arbitrum 同样区分快速排序器提供的软最终确定性，以及数据在主链发布并最终确认后的强保证。快速回执适合用户界面，但高价值结算可能需要批次发布、主链最终确认、证明完成或跨域验证。
本节资料: Optimism Docs · Arbitrum Docs
同一链上交易状态在不同商业场景下可能对应不同动作
- 小额账户充值：立即显示检测结果，在既定阈值后临时入账，并在更强确认前限制提现。
- 数字商品：如果下载或授权不可收回，交付前应要求更强确认。
- 大额B2B发票：结合最终确定性、准确的账单金额匹配、证据复核和资金部门确认。
- 实体商品：检测后可开始拣货和包装，但正式发货等待规定信心阈值。
- 过期或少付发票：即使交易已最终确定，仍可能需要补款、退款、重新报价或人工审核。
清晰的进度提示能减少客户对等待的负面感受，但不能将早期检测描述为不可逆的支付完成。
本节资料: OxaPay
OxaPay 提供支付状态，让商户把链上进展接入业务流程
自行维护多链适配器、确认规则、交易匹配、通知与重试机制需要大量运营投入。OxaPay 提供建立结构化支付请求并接收状态更新的接口。
Generate Invoice API 支持金额、计价币种、有效期、订单ID、少付容差、混合支付选项以及回调URL。这些字段定义商业预期，而区块链确认本身并不了解订单的业务含义。
Webhook 文档区分较早的 Paying 状态与之后的 Paid 状态，并说明 HMAC 验证和通知重试。商户应先验证、存储并幂等处理消息，再返回适当的成功响应。
- 定义请求：创建包含金额、时间、订单标识和异常规则的发票。
- 接收更新：采用经过身份验证的服务器到服务器通知，不能把客户跳转页面当作付款证据。
- 执行业务：根据自身策略，将 Paid 对应到发货、账户开通、财务记录或人工审核。
本节资料: OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay
允许不可逆动作前应完成五项检查
- 支付身份：资产、网络、地址、金额与订单是否匹配？最终确定性不能把错误支付变正确。
- 原生链证据：网络究竟达到哪个确认或最终确定级别？原始依据是什么？
- 网络健康：链是否正常推进，是否存在确认延迟、链重组、排序器停机或数据源分歧？
- 商业风险：如果支付状态以后变化，损失有多大，交付的东西能否追回？
- 受控执行：系统能否恰好执行一次，并用日志、对账和人工处理规则解释决定？
更稳健的政策不一定是最慢的政策，而是使用能安全支持行动的最低充分信心，并向客户准确说明当前状态。
关于最终确定性应参考协议原始文档，实际集成则参考 OxaPay
最终确定性的术语和机制可能随着网络升级改变。制定接受政策时应核实各项目的官方技术资料，而非依靠笼统的网络比较。
- Bitcoin：白皮书及P2P指南，涵盖概率安全、内存池、分叉与过时区块。
- Ethereum：权益证明和Gasper文档，涵盖分叉选择、检查点和经济最终确定性。
- Solana：支付验证工具和RPC文档，解释Processed、Confirmed、Finalized。
- TON：支付流程文档，解释异步消息轨迹与主链引用。
- Layer 2：Optimism和Arbitrum文档，涉及排序器软确认、批次发布与基础链最终确定性。
使用 OxaPay 集成支付时，还应查看 Invoice API、Webhook 以及 Crypto Invoice 服务文档，并把状态与商户操作规则关联起来。
本节资料: Bitcoin Whitepaper · Bitcoin Developer Guide · Ethereum.org · Ethereum.org · Solana Docs · Solana Docs · TON Docs · Optimism Docs · Arbitrum Docs · OxaPay Docs · OxaPay Docs · OxaPay