webman聚合支付回调需按渠道定制处理：支付宝须用php://input读原始数据验签，微信需手动透传wechatpay-开头的header并校验时间戳，各渠道须依content-type和数据特征路由，验签后还需核验订单状态、金额、商户id等业务逻辑，响应格式须严格符合渠道要求。
Webman 做聚合支付回调，不能靠一套逻辑通吃所有渠道——支付宝、微信、银联等验签方式、数据格式、响应要求全都不一样，硬套会丢单、被重试、甚至被恶意伪造。
支付宝 notify 回调必须用 php://input 读原始数据，别碰 $_POST
Webman 默认走 Swoole 的 POST 解析，但支付宝异步通知是 raw body（application/x-www-form-urlencoded），Swoole 有时因 Content-Type 解析异常导致 $_POST 为空或字段错乱。直接传 $_POST 给 AlipayAopClient::rsaCheckV1() 必然验签失败。
- 必须用
file_get_contents('php://input')读原始字符串 - 再用
parse_str($raw, $data)转成关联数组 - 手动
unset($data['sign'], $data['sign_type'])后再传给验签函数 - 全程确保 UTF-8 编码，否则含中文的
out_trade_no查库会失败
微信支付回调 header 被 webman 自动过滤，WECHATPAY-SIGNATURE 找不到
Webman 默认不透传带连字符的 header，像 WECHATPAY-SIGNATURE、WECHATPAY-NONCE、WECHATPAY-TIMESTAMP 全部丢失——这是最隐蔽的签名失败原因。
- 在
config/server.php的onRequest回调里手动补全：$request->withHeader('Wechatpay-Signature', $request->getHeaderLine('wechatpay-signature')) - body 必须用原始 JSON 字符串：
$request->getBody()->getContents()，不能先json_decode再拼验签原文 - 必须校验
WECHATPAY-TIMESTAMP与服务器时间差是否 ≤ 300 秒，NTP 不稳时容易飘偏
多渠道回调共用一个入口时，得靠 Content-Type 或原始数据特征做路由
不能靠 URL 路径硬拆（比如 /notify/alipay、/notify/wechat），支付宝和微信沙箱环境可能用相同域名+路径回调；也不能靠 User-Agent（可伪造）；得看真实数据特征。
- 支付宝：原始 body 是 urlencoded，且必含
sign和app_id字段 - 微信：header 含
WECHATPAY-SIGNATURE，body 是标准 JSON 字符串 - 银联/其他：通常带
signature+encoding字段，且 Content-Type 多为application/json - 建议先读
php://input或$request->getBody()->getContents()，再根据字段存在性 + header 特征分发到对应验签处理器
验签通过只是第一步，业务核验漏掉任意一项都会导致资金风险
验签只说明“数据来自官方且没被篡改”，不代表这笔通知合法有效。常见疏漏点：
-
out_trade_no必须查库确认存在且状态为「待支付」，否则直接拒收（防重放、防错单） -
trade_status（支付宝）或result_code（微信）必须是成功态，TRADE_CLOSED、FAIL等不能更新订单 - 必须比对回调里的
app_id或mch_id是否与当前渠道配置一致，避免多应用密钥混用 - 金额一致性校验不能少：
total_amount或total_fee必须与你数据库中该订单金额完全相等（注意单位：分 vs 元）
最易忽略的是响应体——支付宝要纯文本 success（无空格、无换行、无 HTML），微信要 XML 格式且大小写敏感，任何多余字符都会触发持续重试。别在中间件里自动加 JSON 包裹或全局输出拦截。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
