2.1 三类结果：成功、明确失败、未知#

调用结果至少分成三类：

• 成功：渠道确认已经完成了本次操作，并返回可持久化的渠道流水号。
• 明确失败：渠道确认没有完成操作，且该失败不会在之后变成成功。
• 未知：调用方没有足够证据判断操作是否发生，例如连接超时、响应体丢失、渠道返回处理中，或渠道暂时不可查询。

超时属于未知，不属于失败。只有渠道契约明确说明“请求未受理”时，才能把它归为失败。这个判断会直接决定是否允许重试、是否释放冻结、是否向用户展示失败。

2.2 一个可落地的状态机#

下面是支付扣款的抽象状态，具体名称可以按业务调整：

状态机要同时约束“允许转移”和“禁止转移”。例如，已经 SUCCESS 的扣款不能因为迟到的失败回调回到 FAILED；已经 REFUNDED 的订单不能再次执行全额退款。被拒绝的状态通常也不能物理改写历史记录，而应通过退款、冲正或调整分录表达后续业务动作。

可以把外部事件的处理写成显式的状态转移函数，而不是在回调控制器里直接更新状态：

1
apply(channelEvent):
2
    verifySignature(channelEvent)
3
    event = inbox.insertIfAbsent(channelEvent.uniqueKey)
4
    if event is duplicate:
5
        return ACK
6

7
    payment = loadForUpdate(channelEvent.merchantOrderId)
8
    next = transition(payment.state, normalize(channelEvent))
9
    if next is illegal:
10
        recordDiscrepancy(payment, channelEvent)
11
        return ACK
12

13
    saveStateAndLedger(payment, next)
14
    markInboxProcessed(event)
15
    return ACK

示例中的 insertIfAbsent、行锁或版本号、状态转移和账务写入必须在同一个本地事务边界内完成。回调入口只做验签、落库和快速确认，复杂通知、对账和补偿由后续任务处理。

3.1 为一次业务操作建立稳定标识#

至少要区分三种标识：

同一次扣款的重试必须使用同一个幂等键；退款、冲正等补偿动作是新的业务操作，必须使用新的操作号。不能把“订单号”无条件当作所有动作的幂等键，否则同一订单的扣款和退款可能互相冲突。

渠道提供幂等接口时，要确认幂等键的作用域、保留时间、参数校验和重复请求返回值。以 Stripe 的幂等请求说明 为例，服务端会保存首次请求的结果，重复使用同一键时返回相同结果，并会校验参数是否一致；这类行为是具体平台契约，不应推断为所有支付渠道的共同规则。

3.2 渠道不支持幂等时不要盲目重试#

如果渠道没有幂等键，超时后的第二次扣款可能真的产生第二次扣款。安全做法依赖渠道提供的查询接口或商户请求号：

1. 以本地商户单号查询渠道是否已经受理。
2. 查询到成功或处理中时，停止再次提交，转入状态收敛。
3. 明确查到未受理且契约允许重试时，才重新提交。
4. 查询接口也不可用时，保留未知态并进入补偿队列，不把重试次数当作成功证据。

如果渠道既没有幂等能力，也没有可查询的业务引用，系统无法可靠地证明一次超时请求的结果。此时应在接入评审阶段提出约束，或者把该渠道隔离在人工复核和对账流程后面，而不是用更激进的自动重试掩盖协议缺陷。

3.3 让重试有边界#

查询和提交的重试策略不同：提交是有副作用的动作，查询通常是读操作，但查询过密同样会触发渠道限流。可采用带抖动的退避序列，并同时限制总时长、尝试次数和单渠道并发量：

1
delay = min(base * 2^attempt + random(0, jitter), maxDelay)
2
nextQueryAt = now + delay

这不是一个通用的固定参数。参数应由渠道 SLA、业务冻结时长、清算窗口和人工处理能力共同决定。超过自动查询窗口后，状态进入差错池或人工复核，而不是无限重试。

4.1 回调接收必须先落证据#

回调入口应完成验签、时间窗校验、原始报文落库和去重键登记，再快速返回渠道要求的确认响应。不要在 HTTP 回调请求内同步执行记账、通知、对账等慢操作；否则业务服务的短暂故障会被渠道解释为回调失败，触发更多重复推送。

回调去重键优先使用渠道事件 ID；没有事件 ID 时，按“渠道 + 渠道流水号 + 事件类型 + 事件版本”构造稳定键，并把原始报文哈希作为审计证据。只按订单号去重不够，因为同一订单可能有支付成功、退款成功等多个合法事件。

回调可能乱序到达。事件时间戳可以帮助识别旧事件，但不能只依赖本地时钟；若渠道提供序列号，应记录并按序列号判断。无论使用时间戳还是序列号，都必须再次经过状态机校验，不能因为“新来的回调”就无条件覆盖当前终态。

以 Adyen 的 Webhook 处理说明 为例，渠道在未及时收到确认时会重试，重复事件可能具有相同的事件类型和渠道引用，文档也要求接收方处理重复并关注事件时间或序列号。这个例子说明了回调的工程要求，但具体确认时限、重试次数和字段仍以接入渠道的契约为准。

4.2 主动查询是未知态的收敛工具#

主动查询不是“回调失败后的临时补丁”，而是外部一致性模型中的正式组成部分。查询任务应使用本地记录的渠道引用、商户单号和幂等键，不能依赖一次内存中的请求上下文。

查询结果仍要经过同一个状态机。查询到成功时，执行与回调相同的成功落账逻辑；查询到失败时，释放冻结或执行失败收敛；查询到处理中时，更新下次查询时间；查询超时则继续保留未知态。回调和查询共用收敛函数，可以避免“两套代码对同一个结果做出不同判断”。

5.1 支付尝试表#

一笔本地订单可能有多次查询、一次扣款和多次退款。把所有字段挤在订单表里，会让重试、渠道切换和审计都变得含糊。可以拆出支付尝试表，至少记录：

• 本地订单号、业务操作类型和商户请求号；
• 渠道、渠道账户、币种和金额的最小货币单位；
• 稳定的渠道幂等键、渠道流水号和渠道状态原值；
• 当前归一化状态、版本号、首次请求时间和最后一次响应时间；
• 查询次数、下次查询时间、租约到期时间和最后错误分类；
• 请求与响应的脱敏摘要、Trace ID 和审计引用。

金额、币种、手续费和结算日期必须作为同一事实的字段保存。只保存“渠道返回成功”而不保存金额、币种和渠道引用，后续无法判断成功是否对应了正确的业务单。

5.2 回调收件箱#

回调表保存“渠道发过什么”，支付尝试表保存“系统认为现在是什么状态”。两者不要混成一张表。收件箱可以包含：

1
channel, channel_event_id, channel_transaction_id,
2
event_type, event_version, event_time, received_at,
3
payload_hash, signature_valid, process_status, process_error

对 (channel, channel_event_id) 建唯一约束；如果渠道没有事件 ID，则对经过确认的组合键建唯一约束。原始报文应按合规要求脱敏和加密保存，支付卡敏感数据不应为了排障而完整写入业务日志。

5.3 对账批次和差错项#

对账不是一条 SQL，而是一个可重放的批处理。至少需要记录：

• 对账来源、渠道账户、业务日期、时区和结算批次；
• 文件名或接口批次号、文件哈希、下载时间和解析版本；
• 来源行号、渠道交易号、商户单号、金额、币种、费用、净额和状态；
• 匹配结果、差错类型、证据引用、处理人、处理动作和处理时间。

文件哈希和批次号用于防止同一账单重复导入；解析版本用于在渠道字段变更后复现历史结果。对账结果不能只写一个“已对账”布尔值，否则无法区分金额不一致、状态不一致和渠道多出一笔等差异。

6.1 三层对账#

内部对账检查同一系统内的业务对象是否自洽：订单、支付尝试、资金流水、分录和余额之间的数量与金额必须满足不变量。例如，已成功扣款的订单应存在唯一成功支付事实，账务分录借贷应平衡，余额应能由期初余额和有效分录推导出来。

外部交易对账把本地交易明细与渠道交易明细逐笔比对，发现本地没有而渠道有、本地有而渠道没有、状态不一致、金额或币种不一致、重复交易等问题。

结算对账把渠道的应收、手续费、退款、拒付和实际入账金额与银行账户或清算账户流水比对。交易日、结算日和账务日可能不同，不能拿一个自然日的订单总额直接与另一个自然日的银行入账相减。

6.2 实时、准实时和日终不是三选一#

• 实时校验：在收到回调或查询结果时检查金额、币种、渠道引用和状态转移，尽快阻止明显错误。
• 准实时对账：按分钟或小时级窗口检查未收敛订单、回调延迟和渠道可查询结果，控制未知态的存量。
• T+1 或渠道约定的完整对账：导入完整交易、结算和费用文件，覆盖漏回调、漏采集、跨日结算和渠道侧更正。

频率由渠道可提供的数据、业务冻结时长、监管或合同要求决定。没有完整渠道账单时，准实时任务只能发现“本地记录里已经存在的异常”，不能证明外部没有一笔本地完全不知道的交易。

ISO 20022 的现金管理消息提供了常见的银行报文形态，例如 camt.052 账户报告、camt.053 账户对账单和 camt.054 借贷通知。这些消息的版本、字段和采用范围由具体银行或清算社区决定；接入时应以对方的使用指南和样例为准，而不是只按消息名称猜测语义。

6.3 匹配策略要先严格、再人工#

对账匹配可按以下顺序收敛：

1. 渠道交易号或渠道提供的唯一引用精确匹配。
2. 商户单号、金额、币种、交易类型和业务日期组合匹配。
3. 对渠道允许的时间漂移、手续费拆分或批次汇总进行受控匹配。
4. 仍无法匹配的项目进入差错池，不用模糊规则自动“凑平”。

金额差异不能用一个全局容差吞掉。只有渠道契约明确规定的手续费、汇率或舍入差异，才可以按业务规则自动归类；未知差额应阻断自动调账。

外部调用#

• 每个有副作用的操作都有稳定商户单号和渠道幂等键。
• 同一操作的重试不会生成新键；退款、冲正等补偿使用新操作号。
• 超时、连接断开和空响应均进入未知态，不直接判失败。
• 渠道不支持幂等时，存在查询、人工复核或明确的接入限制。
• 提交、查询、回调和账单解析都保留原始引用和错误分类。

回调与状态机#

• 回调先验签和持久化，再快速确认；重复事件有唯一约束。
• 事件乱序不会逆转终态；非法转移进入差错池。
• 回调、主动查询和人工处理共用同一状态收敛函数。
• UNKNOWN 有查询窗口、退避、租约、告警和人工接管路径。

对账与修复#

• 有内部交易对账、外部渠道对账和结算/银行对账的责任边界。
• 对账批次、文件哈希、解析版本和原始行号可重放、可审计。
• 实时/准实时检查与 T+1 完整对账分别定义目标和时限。
• 差错池区分本地多出、渠道多出、状态差异、金额差异和重复交易。
• 挂账、冲正、退款、补单和人工复核均有授权、幂等和审计记录。
• 没有用模糊匹配或直接改余额掩盖无法解释的差额。