调用 uni.requestPayment 前必须确认:1. 后端使用微信支付 V3 接口生成 prepay_id;2. 小程序 AppID 与开放平台绑定一致且开通 JSAPI 支付权限;3. 支付参数 timeStamp 为字符串、nonceStr 和 package 原样透传;4. 小程序基础库 ≥2.10.3。

uni-app 调用 uni.requestPayment 前必须确认的 4 件事
微信支付在 uni-app 里不是“调个 API 就行”,uni.requestPayment 只是最后一步,前面漏掉任一环节都会卡在“requestPayment:fail invalid sign”或“支付参数错误”。
常见错误现象:fail invalid sign、fail no permission、fail system error,本质几乎全是服务端签名或配置问题,和前端代码关系不大。
- 后端必须用「微信支付 V3 接口」生成
prepay_id,V2 已不被uni.requestPayment支持(尤其注意:uni-app 的 H5 端走 JSAPI,小程序端走小程序支付,两者签名逻辑不同,但都要求 V3) - 小程序 AppID 必须和微信开放平台绑定的「公众号/小程序」一致,且在微信支付商户平台已开通「JSAPI 支付」权限,并配置了合法域名(开发时填
localhost不生效,真机调试需用https域名) - 后端返回给前端的支付参数中,
timeStamp必须是字符串类型(不是数字),nonceStr和package必须原样透传(不能额外 trim 或 encode) - 小程序基础库版本 ≥ 2.10.3,低于此版本可能触发
fail system error(尤其老用户手机未更新微信)
小程序端调用 uni.requestPayment 的正确姿势
别直接把后端返回的所有字段塞进 uni.requestPayment,它只认固定字段名,多一个或少一个都会失败。
使用场景:用户点击“立即支付”后,先请求后端获取支付参数,再调起微信支付弹窗。
参数差异:package 字段值形如 prepay_id=wx1234567890,不是 JSON 对象;timeStamp 是字符串格式的秒级时间戳(如 "1715823456"),不是毫秒;signType 固定为 "RSA"(V3 签名)或 "MD5"(极少 V2 兼容场景,不推荐)。
- 必须按顺序传参:
timeStamp、nonceStr、package、signType、paySign,缺一不可 -
paySign是后端对上述 5 个字段拼接后签名的结果,前端不能自己算(RSA 私钥不能暴露) - 不要在
success回调里直接跳转订单页——支付成功回调仅表示“用户点确定并输完密码”,不代表支付到账,最终状态以后端异步通知为准
uni.requestPayment({
timeStamp: res.data.timeStamp,
nonceStr: res.data.nonceStr,
package: res.data.package,
signType: 'RSA',
paySign: res.data.paySign,
success: (res) => {
console.log('用户完成支付操作(不一定成功)', res)
},
fail: (err) => {
console.error('支付中断或失败', err)
}
})
H5 端微信支付为什么总是跳转失败?
uni-app 的 H5 端调用微信支付,实际走的是微信 JSAPI,依赖微信内置浏览器(即用户用微信打开网页)。非微信环境(Chrome/Safari 直接访问)必然失败,且不会提示明确错误。
常见错误现象:fail config:invalid signature、空白页、跳转到微信首页、直接报 undefined。
- 必须确保页面 URL 在微信商户平台「公众号支付」中配置的「授权目录」内(注意:是目录,不是完整 URL,且末尾必须带
/) -
uni.requestPayment在 H5 下会自动调用WeixinJSBridge,但前提是页面已通过微信 JS-SDKconfig接口完成初始化(uni-app 不自动做这步,需手动集成) - 需要后端额外提供
jsapi_ticket和当前 URL(含 hash 前的部分),前端用它们调uni.startPullDownRefresh类似逻辑生成签名,再传给uni.requestPayment - 真机测试务必用「微信扫一扫」打开链接,而不是复制链接到 Safari —— 后者根本不会触发微信支付流程
支付成功后,前端最容易忽略的两个验证点
很多人以为 uni.requestPayment 的 success 回调 = 支付成功,结果出现用户付了钱但订单没变状态,或者重复创建订单。
性能 / 兼容性影响:前端无法 100% 确认支付结果,网络抖动、用户切后台、微信进程被杀都可能导致回调丢失。过度依赖前端回调会直接导致资金和业务数据不一致。
-
success回调只代表“用户完成了支付动作”,不代表银行扣款成功,也不代表微信已通知商户系统 - 必须以「后端收到微信支付异步通知」为准,前端可轮询订单接口(带防重机制),但不能替代服务端验签和更新状态
- 如果用户支付后关闭页面,
success和fail都不会触发,此时唯一可靠方式是监听onShow生命周期,检查订单最新状态
微信支付不是前端单点打通就能跑通的事,uni.requestPayment 只是最后一厘米,前面每一步——商户配置、后端签名、域名白名单、JS-SDK 初始化——只要有一个字母填错,就会静默失败。最常卡住的地方,永远在「你以为没问题」的配置项里。










