uni-app前端不处理支付异步回调，需服务端接收微信/支付宝通知并验签更新订单；uni.onPaymentComplete仅小程序支持，App/H5需原生插件透传结果；uni.requestPayment的success仅表示拉起支付页面，非支付成功。
uni-app 本身不处理支付成功异步回调通知——这个动作必须由服务端完成，前端只负责接收和响应结果。所谓「回调通知」，本质是微信/支付宝服务器向你后端接口（如 /api/pay/notify）发起的 HTTP POST 请求，uni-app 的 JS 层完全收不到它。
为什么 uni.onPaymentComplete 在 App 和 H5 里不触发
这个监听函数仅在微信小程序环境生效，App 端和 H5 端压根不支持。很多开发者卡在这一步，反复检查 uni.onPaymentComplete 写法，其实问题不在代码，而在平台能力边界。iOS/Android 原生层不会自动把支付结果透给 JS，必须你自己打通通道。
- iOS 需通过原生插件调用
uni.postMessage主动把结果发给 webview - Android 需在 Activity 或广播中捕获支付结果，再用
uni.getEnv判断环境后调用uni.$emit或全局事件通知 - 若 manifest.json 未勾选「使用原生插件」，
uni.postMessage在 iOS 上会静默失败，无任何报错
uni.requestPayment 的 success 不代表支付成功
这是最容易误解的一点：uni.requestPayment 的 success 回调只是表示「支付页面已成功拉起」，用户可能立刻取消、输错密码、甚至关掉 App。它和实际支付成败毫无关系。
- 不要在这里直接跳转「支付成功页」或更新订单状态
- 正确做法是：在
success中立即启动轮询，查服务端订单支付状态 - 轮询请求应带订单号，例如
uni.request({ url: '/api/order/status?order_id=' + orderId }) - 服务端接口必须返回明确状态字段，如
{ status: 'pending' | 'success' | 'failed' }，不能只靠 HTTP 状态码
服务端异步通知（Webhook）才是唯一可信来源
微信/支付宝会在用户支付完成后，主动向你配置的 notify_url 发起多次 POST 请求。这个链路绕过前端，不可伪造，是更新订单状态的唯一权威依据。
- 后端收到通知后，必须校验签名、验证订单号、幂等处理（防止重复通知）
- 校验通过后，才可更新数据库订单状态，并可选触发消息推送、库存扣减等后续动作
- 务必在处理完逻辑后，返回微信/支付宝要求的特定响应（如微信要求返回
<xml><return_code></return_code></xml>），否则会被重试 - 前端不能依赖这个通知实时刷新 UI——它走的是服务端到服务端链路，JS 层无法感知
真正难的不是写轮询代码，而是让服务端 notify 接口扛住重试、防重放、验签不出错；以及在 App 端把原生层的结果可靠传回 JS——这两处一旦松动，用户就可能看到「已支付但订单仍是待付款」。别省略原生插件配置，也别跳过服务端签名验证步骤。
