微信小程序支付出了问题，最难的地方在于报错信息往往只说“支付失败”“签名错误”，既不说明失败环节，也不提示改哪里。实际上，微信支付返回的错误码、前端requestPayment的errMsg、公众平台站内信这三种来源，基本能把问题限定在一个很小的范围内。下面按故障发生的环节拆解常见原因，最后给出建议的排查顺序。
一、账号与授权没有对齐，问题多半出在下单之前
最常见的一类，是小程序绑定商户号这块出了问题，AppID和商户号没有建立正确的绑定关系。下单时如果返回“appid和mch_id不匹配”，基本上就是AppID与商户号未关联，或者关联的是另一个小程序。服务商模式更容易出现这类问题：sp_appid要绑定服务商商户号，sub_appid要在服务商平台为特约商户配置，配置错了就会报“sub_mch_id与sub_appid不匹配”。
openid也是容易出问题的地方。小程序支付必须传openid，而且这个openid必须来自下单所用AppID，拿公众号或其他小程序的openid传入，就会报“appid与openid不匹配”。
还有一类容易被忽略：账号本身状态不正常。商户号被注销、冻结，或者收款功能被限制，下单直接失败。小程序侧同样有权限门槛：服务类目不符、交易类小程序未按《交易类小程序运营规范》接入订单发货管理，前端会提示requestPayment:fail no permission或“小程序违规，无法使用支付”，具体原因小程序开发者要去公众平台通知中心查看，单纯改代码解决不了。
二、签名与密钥：错误码最集中的地方
签名错误和v3接口的SIGN_ERROR，是出现频率最高的一类。排开代码写错的可能，原因通常只有几种：密钥用错了商户号、v2与v3的密钥或私钥混用、商户API证书过期或与商户号不匹配。v2接口报400 The SSL certificate error，多数就是证书过期或误用了别的商户证书。
参数层面出问题更容易被忽略，而且特别隐蔽：下单接口的appid是小写i，调起支付的appId是大写I；签名原串必须用参数原始值，做过URL encode就会验签失败；请求统一UTF-8编码；调起支付的时间戳要用秒级，不能用毫秒。这些细节错一个，报错信息都一样。
三、下单参数与订单状态：金额、package、重复单号
参数非法里，金额单位是最经典的错误：v3的amount.total单位是分，传成元就差了100倍。时间字段要用RFC 3339格式，请求体里也不要带接口文档未定义的字段，v2和v3的参数结构不能相互套用。
调起阶段最常见的是package格式不对，必须是prepay_id=xxx，且与下单返回的值完全一致。另外，prepay_id有场景绑定：小程序下单生成的只能用于小程序调起，拿去H5或APP用会报“支付场景非法”。
订单号重复和订单已支付也很常见，多出现在用户重复点击、或前端超时重试的时候。同一个out_trade_no支付成功后不要重复下单，也不要再调关单，需要取消就走退款。
四、环境与调用方式的硬性限制
线上版本调用沙箱环境会直接报702008，这个错误在开发环境一切正常、上线后才暴露，排查时很容易找错方向。更常见的是调用方式本身不被支持：小程序web-view内不能用H5支付，H5支付只能在外部浏览器使用；从外部APP或H5跳转到小程序支付也不被允许。这类问题不是配置错误，改参数也没有用，只能更换支付产品。
五、按报错来源确定排查顺序
不要一上来就重写签名代码。先分清失败发生在哪一步：下单接口报错，看返回的code和detail，优先查AppID与商户号的绑定、密钥、金额单位；下单成功但调起失败，重点查package格式、appId大小写、时间戳位数；前端只提示无权限或违规，就去公众平台看站内信和服务类目。同时把完整请求报文和签名原串打出来，和文档逐字段比对，绝大多数问题在日志里就能定位。
高频报错属于另一类问题，用指数退避重试即可，业务量确实大的可以联系微信支付申请提频，不用当成故障处理。
