支付宝sdk报invalid app_id或签名失败，主因是app_id、private_key、public_key未对齐，需确认rsa2密钥、用支付宝公钥验签、sign_type设为'rsa2'，私钥trim处理，验签用原始post数组；微信v3签名需按规范拼接并哈希请求体，用平台证书公钥验签；notify路由须排除csrf中间件，立即返回200/success并入队处理，校验来源ip；订单状态以异步通知为准，做好幂等和轮询兜底。
支付宝 SDK 报 Invalid app_id 或签名失败
问题通常不是配置错了 app_id，而是没把 app_id、private_key、public_key 三者对齐——支付宝开放平台生成的是 RSA2 密钥对，但 Laravel 包（比如 lokielse/laravel-alipay）默认可能用 RSA1；更常见的是，你用了支付宝提供的「应用公钥」去验签，而实际该用「支付宝公钥」（在开放平台「开发者中心 → 应用详情 → 支付宝公钥」里下载的那个）。
- 检查
config/alipay.php中sign_type必须设为'RSA2'，且私钥内容不含-----BEGIN RSA PRIVATE KEY-----等换行和空格（建议用trim(file_get_contents(...))加载） - 验签时传入的
$data必须是原始 POST 参数数组（不能是 JSON 解析后的、也不能被 Laravel 自动过滤过），推荐用request()->all()并排除_token和空值 - 沙箱环境必须用沙箱版的
app_id和alipay_public_key，这两个在沙箱账号页面单独提供，和正式环境不互通
微信支付 V3 接口返回 INVALID_SIGNATURE
微信 V3 的签名机制和 V2 完全不同：它要求用商户私钥对「请求方法 + 换行符 + 请求路径 + 换行符 + 请求体哈希 + 换行符 + 时间戳 + 换行符 + 随机串」拼接后签名，且时间戳误差不能超 300 秒。Laravel 中最容易漏的是请求体哈希计算——不能直接 hash 原始 JSON 字符串，得先 json_encode($body, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) 标准化后再 hash('sha256', ...)。
- 确保
WECHAT_PAY_V3_MCH_ID、WECHAT_PAY_V3_CERT_SERIAL（证书序列号）、WECHAT_PAY_V3_API_V3_KEY（APIv3 密钥）全部从微信商户平台「API 安全」页准确复制，尤其注意 APIv3 密钥是手动设置的 32 位字符串，不是证书密码 - 调用
POST /v3/pay/transactions/jsapi时，notify_url必须是 HTTPS、可公网访问、且域名已备案并加入支付目录（否则预下单直接失败） - 回调验签必须用平台证书里的公钥（不是你的私钥），证书需定期轮换；推荐用
wechatpay-php官方 SDK 的Verifier类，别手写验签逻辑
Laravel 中统一处理支付异步通知（Notify）的路由和中间件
支付宝和微信的 Notify 都是纯 POST 请求，不带 session、CSRF token，甚至不走 Laravel 默认的中间件栈。硬套 web 中间件会导致 419；放 api 中间件又可能触发频率限制或日志污染。
- 在
routes/web.php里单独注册不经过VerifyCsrfToken的路由：Route::post('/notify/alipay', [PaymentController::class, 'handleAlipayNotify'])->withoutMiddleware([\App\Http\Middleware\VerifyCsrfToken::class]); - 通知入口必须立刻返回 HTTP 200（微信要求响应体为空，支付宝要求返回
success字符串），任何业务逻辑（如更新订单状态）必须丢进队列，避免超时 - 务必校验通知来源 IP：支付宝只从
openapi.alipay.com解析出的 IP 段发通知（官方文档有列表），微信只从https://api.mch.weixin.qq.com/v3/certificates返回的证书中提取 IP 列表——别只靠 Referer 或 User-Agent
订单状态与支付结果不一致的典型场景
最常出问题的是「用户重复点击支付按钮」或「前端跳转成功页后，后端还没收到通知」。这时候如果前端直接查数据库判断订单状态，会看到「待支付」，但其实钱已经扣了。
- 不要依赖前端传来的订单 ID 做状态判断；所有支付结果以异步通知为准，且必须完成幂等处理（比如用数据库唯一索引约束
out_trade_no+notify_id组合） - 用户支付完成后跳转的「同步返回页」（如支付宝的
return_url）只是提示作用，不能用于更新状态；它的参数可能被篡改，且不一定到达 - 加一个「支付结果轮询」兜底：前端 JS 调用
/api/orders/{id}/status，后端查订单状态 + 支付渠道单号是否已存在，最多轮询 3 次，每次间隔 2 秒——比干等通知更可控
支付链路里没有“最终一致性”这种模糊概念，只有明确的幂等标记、可验证的签名、以及隔离的异步处理边界。漏掉任意一环，都会让订单卡在灰色状态。
