ThinkPHP支付回调处理方法-ThinkPHP-PHP中文网

thinkphp支付回调失败主因是未直取php://input、验签字段或编码错误、响应含bom/空格/非200；微信xml、支付宝原始字符串需绕过框架解析，v3须用官方sdk解密；防重放需唯一索引+状态机+notify_id去重；回调路由必须禁用所有中间件并确保响应洁净。

thinkphp支付回调处理方法

ThinkPHP 支付回调处理失败，90% 源于三件事没做对：没直取 php://input、验签时字段拼错或编码不一致、响应体含空格/BOM/非 200 状态。这三步任一出错，就会触发微信/支付宝持续重发，甚至重复发货。

为什么 `$this->request->post()` 和 `input('out_trade_no')` 总是空

微信发的是 raw XML，支付宝发的是 raw query string，Content-Type 常为 text/xml 或 application/x-www-form-urlencoded，但无标准表单边界；v3 接口甚至发 AES 加密 JSON。ThinkPHP 默认只解析 application/x-www-form-urlencoded 和 multipart/form-data，其他类型一律跳过，$_POST 为空是正常现象。

别在控制器里写 input('out_trade_no') —— 它依赖框架自动解析，对 XML/原始字符串无效
别用 $this->request->param() 处理微信 XML，除非你先调了 bind('xml', true)（TP6+ 不原生支持，需手动扩展）
混用 $_POST 和 file_get_contents('php://input') 会因输入流只能读一次，导致后者返回空字符串
正确做法：入口第一行就定死数据源 —— 微信 XML 用 file_get_contents('php://input')；支付宝原始字符串也用它；v3 加密 JSON 必须先解密再 json_decode()

微信 v2 / v3 和支付宝验签失败的硬性检查点

验签不是比对 hash，而是还原签名原文的过程。任何字段遗漏、顺序错、编码不一致都会失败。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

微信 v2：剔除 sign 字段后，所有剩余字段（含 sign_type）按字典升序拼成 k1=v1&k2=v2，末尾加 &key=YOUR_KEY，全部 UTF-8 编码后再 MD5；cash_fee 等数字字段值必须保持字符串原样参与拼接，不能转 int
支付宝：原始字符串（非数组）先 urldecode()，再用 parse_str() 转数组，剔除 sign 和 sign_type，键名升序排列后用 & 拼接，不加 key，最后用 RSA 公钥验签；alipay_config['rsa_public_key'] 必须是 PEM 格式且开头为 -----BEGIN PUBLIC KEY-----
微信 v3：不能手写验签，必须用官方 wechatpay-php SDK，构造 WechatPayMiddleware，传入平台证书私钥和序列号；回调体是 AES-GCM 加密 JSON，直接 json_decode() 必然为空或乱码

回调成功后更新订单，为什么还要防重放

支付平台会因网络超时、你返回非 200、响应含 BOM/空格/额外输出等原因持续重推同一笔通知，最长可达 24 小时。仅靠查 out_trade_no 是否存在无法解决并发冲突。

数据库层必须加唯一索引：在订单表建 trade_no 字段并设 UNIQUE，插入支付成功记录时用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE
业务层加状态机判断：只允许从 unpaid → paid，如果已是 paid 就跳过后续操作
不要依赖支付宝的 trade_status 做最终判断，它可能滞后（比如先发 TRADE_SUCCESS，后发 TRADE_CLOSED），应以你自己落库的状态为准
记录每次通知的 notify_id，同一 ID 只处理一次（缓存或 DB 记录均可，有效期建议设为 24 小时）

回调路由为什么不能走 ThinkPHP 默认中间件

微信服务器只认固定路径（如 /pay/notify），且要求无重定向、无 session、无 CSRF、不走中间件的裸响应。默认中间件栈（尤其是 VerifyToken、SessionMiddleware）会拦掉或污染原始 XML 数据。

常见错误现象：Empty XML、sign error、curl 500、日志里看到 Request method not allowed（其实是中间件提前返回了）
必须在路由定义中禁用所有中间件：Route::rule('pay/notify', function() { ... })->removeMiddleware();
不要把这段逻辑写进普通控制器，否则会触发 initialize 等生命周期方法，引入不可控变量
若使用多语言中间件，需在 app/middleware.php 的 except 列表中明确排除 /pay/notify

最易被忽略的是响应体的洁净度：哪怕一个 UTF-8 BOM、一个空格、一行 echo 日志，微信都会判定失败并重试。上线前务必关掉 app_debug = false，响应前调用 ob_end_clean()，严格输出 <xml><return_code>SUCCESS</return_code><return_msg>OK</return_msg></xml> —— 多一个字符都不行。