webman支付异步通知处理须严守三原则：验签必须严格、业务必须幂等、原始报文必须先落库；漏任一环易致资损或对账不平。

Webman 里处理支付异步通知，核心就三件事：验签必须严、业务必须幂等、原始报文必须先落库。漏掉任一环，上线后大概率资损或对账不平。

支付宝 notify_url 验签失败的常见原因

验签失败不是“配置错了密钥”这么简单，多数是数据被框架提前解析污染了：

• $_POST 不能直接传给 AlipayAopClient::rsaCheckV1() —— Webman 默认不自动填充 $_POST，且支付宝发的是 raw body（application/x-www-form-urlencoded），Swoole 解析可能丢字段或乱码
• 必须用 file_get_contents('php://input') 或 $request->getBody()->getContents() 读原始字节流，再 parse_str() 解析成数组
• 解析后务必 unset($data['sign'], $data['sign_type'])，否则验签函数会把签名本身也参与计算
• 全程 UTF-8 编码：数据库字段、日志记录、out_trade_no 查询条件都不能用 GBK，否则含中文订单查不到

微信支付回调验签与 XML 解析陷阱

微信回调是 XML 格式，不是 JSON，也不走 $_POST，直接用 simplexml_load_string() 容易出错：

Webman 2.2.0

Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。

下载

• 必须用 file_get_contents('php://input') 读原始内容，再转为字符串传入解析函数
• XML 中的 sign 字段要先提取出来，其余字段按字典序拼接 + 密钥再做 MD5，不能依赖 SDK 自动处理（部分老 SDK 对空格/换行敏感）
• 验签通过后，仍要检查 return_code 和 result_code 是否都为 SUCCESS，否则可能是微信平台级错误而非业务失败
• 微信不保证 IP，不能用 $_SERVER['REMOTE_ADDR'] 做白名单，只能靠签名验证来源

回调接口必须立即返回 success 的硬性要求

支付宝和微信都要求：验签通过、参数校验通过后，必须立刻返回纯文本 success，且不能有任何额外字符（包括换行、空格、HTML、JSON 包裹）：

• 返回 {"msg":"success"} 或 success → 微信/支付宝认为失败，持续重试（最长超 24 小时）
• 在返回 success 前执行耗时操作（如结算、发券、调第三方 API）→ 极易超时，触发重试，放大重复风险
• 正确做法：验签+基础校验通过后，立即 echo 'success' 并 exit；后续业务逻辑扔进异步任务（如 task 组件或 RabbitMQ）
• Webman 的 task 组件适合轻量任务；高一致性要求场景（如分账、资金流水）建议走 RabbitMQ，避免进程崩溃导致任务丢失

为什么“先落库原始报文”比业务逻辑还重要

原始报文不落库，等于没留证据。一旦出问题，你连“到底收到了什么”都说不清：

• 必须在任何业务更新前，把 php://input 的原始字节存进数据库（字段类型用 TEXT，编码 utf8mb4）
• 表结构至少包含：id、channel（alipay/wechat）、raw_data、created_at、handled（布尔，默认 false）
• 落库失败应直接返回失败（不重试），避免脏数据干扰；成功后才开始验签和业务处理
• 生产环境发现状态错乱时，第一反应不是查代码，而是翻这张表——它能快速区分是渠道发错、网络丢包、还是你代码逻辑 bug

最常被跳过的其实是“验签通过后查订单是否存在且状态合法”这一步。很多人只查 out_trade_no 存在，却忽略它当前是否为「待支付」状态，结果旧单重放攻击或测试环境回调直接刷穿生产订单状态。