支付回调异常处理是围绕资金安全的防御性工程实践，需严格校验签名与来源、强制金额/状态/幂等三重校验、异步化处理+主动兜底、事务原子化+补偿机制+自动对账。

支付回调中的异常处理不是单纯“捕获 try-catch”，而是围绕资金安全构建的一整套防御性工程实践。核心目标是：不丢单、不错账、不重复、不可伪造。

严格校验签名与来源真实性

所有回调请求必须先过签名验证关，否则直接拒绝，不进业务逻辑。这是防伪造的第一道闸门。

• 使用支付平台指定的算法（如 SHA256withRSA），禁用 MD5withRSA 等弱算法
• 公钥从密钥管理服务（KMS）或配置中心动态加载，禁止硬编码在代码里
• 验证前先检查时间戳偏差（建议 ≤ 5 分钟），防止重放攻击
• 签名失败必须记录详细日志（含原始参数、时间、IP），并触发告警，不能只返回“验签失败”

强制金额、状态、幂等三重校验

签名正确只是起点，后续每一步都可能被绕过。必须叠加业务层防护。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 比对回调中的 total_fee 与本地订单应缴金额，不一致则拒绝并告警
• 检查订单当前状态是否为“待支付”，已支付/已关闭的订单直接返回成功，不再执行任何更新
• 以微信 transaction_id 或建行 order_no 为 key，用数据库唯一索引或 Redis 分布式锁实现幂等控制；处理前先查库，存在即跳过

异步化 + 可追溯 + 主动兜底

同步处理回调风险高、易超时、难扩展。应把核心动作拆解为轻量响应 + 异步任务。

立即学习“Java免费学习笔记（深入）”；

• 回调接口收到请求后，仅做签名和基础校验，快速持久化原始回调数据（含完整 body、headers、时间戳）到专用表，立即返回 success
• 由独立消费者线程或定时任务拉取未处理回调记录，执行订单状态更新、佣金计算、消息推送等耗时操作
• 对超 15 分钟未处理的回调自动告警；对超 2 小时无回调的已支付订单，启动主动查询（调用微信 / 建行订单查询 API）补全状态

事务边界清晰 + 补偿机制就位

涉及资金变动的操作必须原子化，且失败后能人工或自动修复。

• 更新订单状态、记账流水、生成佣金单等操作放在同一个数据库事务中；任一环节失败则全部回滚
• 关键步骤（如发券、通知用户）失败时，记录失败原因并进入“待人工干预”队列，支持后台一键重试
• 每日凌晨运行对账任务，比对支付平台账单与本地交易流水，自动识别差异单并生成工单