支付回调为什么要查幂等
支付与退款回调有三项硬要求：验签、幂等、状态机一致。支付平台的回调是“至少一次”语义，同一笔订单可能被推送多次；如果服务端没有幂等处理，就会出现重复发货、重复加余额、重复开票。乱序回调（先收到退款再收到支付）同样常见，需要状态机按业务顺序规则处理而不是按到达顺序。
基本信息
| 核查对象 | 支付、退款、代付、分账类回调接口与对账任务 |
|---|---|
| 三项要求 | 回调验签、幂等键与唯一约束、状态机一致性 |
| 验证环境 | 联调或测试环境，生产环境禁止回调重放 |
| 参考标准 | CWE-841、主流支付平台开放平台文档 |
典型使用场景
- 支付中心上线前的回调处理评审
- 排查偶发的重复发货与重复记账问题
- 评估订单状态机的健壮性与人工补单流程
- 核查对账任务与异常单处理机制是否完善
- 第三方支付渠道切换后的兼容性验证
核查清单
核查清单
回调是否验签：签名算法、平台公钥或证书的存放与轮换
重复回调如何处理：幂等键取值、唯一约束、状态前置判断
乱序回调如何处理：状态机是否允许从终态回退、是否有事件时间比较
金额一致性：回调金额与本地订单金额是否比对，币种是否校验
对账机制：T+1 对账任务的差异单处理与人工补单流程场景与期望处理
| 场景 | 期望处理 | 失败后果 |
|---|---|---|
| 同一回调重复到达 | 幂等键去重，重复请求直接返回成功 | 重复发货或重复记账 |
| 手工重放历史回调 | 签名与时间戳校验后仍走幂等逻辑 | 资金与业务数据错乱 |
| 先收款后发货顺序颠倒 | 状态机按事件时间处理 | 订单状态卡死或重复处理 |
| 退款回调早于支付回调 | 记录待处理事件并延后匹配 | 退款落空或重复退款 |
| 回调丢失 | 主动查询订单状态补偿 | 订单长期挂单 |
回调重放类验证只在联调或测试环境进行并做好数据隔离；在生产环境重放回调会直接产生资金与库存影响。
幂等实现要落在数据库层：仅靠应用层“先查后写”在并发下仍会重复，唯一约束或原子更新才是可靠边界。