微信小程序支付的完整流程与五个高发坑点

小程序支付看起来只是"调一个接口"，但线上事故大多出在支付环节。我们把完整链路和踩过的坑整理出来，希望你不用再用真金白银交学费。

完整流程

1. 小程序端调用后端下单接口，后端生成内部订单（状态：待支付）；
2. 后端携带商户号、订单号、金额、回调地址，请求微信支付「统一下单」接口，拿到 prepay_id；
3. 后端用商户私钥对支付参数二次签名，返回给小程序；
4. 小程序调起 wx.requestPayment，用户输入密码完成支付；
5. 微信服务器异步回调你的通知地址，后端验签、确认金额、更新订单状态；
6. 小程序轮询或后端主动查询支付结果，完成页面跳转。

五个高发坑点

1. 二次签名算法用错

统一下单返回后，调起支付前的签名用的是 RSA 或国密 SM2 签名（v3 接口），不是下单时的参数签名。最常见错误是拿 MD5 或 HMAC 去签，小程序直接报"支付验证签名失败"。

2. 回调验签没做或做错

支付回调必须验签，否则任何人都能伪造"支付成功"通知。v3 接口用平台证书验签，注意平台证书会轮换，要做证书自动更新，不要硬编码。

3. 回调没有幂等处理

微信会多次推送同一条通知（你没返回成功它就重试）。回调处理必须幂等：先查订单当前状态，已是"已支付"就直接返回成功，不要重复发货、重复加库存。

4. 信任前端回调，不等后端通知

wx.requestPayment 的 success 回调不能作为支付成功依据（用户可能支付成功后立刻断网杀进程，前端回调丢失或伪造）。唯一可信源是微信服务器的异步通知 + 主动查单。

5. 没有日终对账

网络抖动、服务重启总会造成极少量"用户付了钱但订单没更新"的单子。每天定时拉取微信账单与本地订单对账，差异单自动告警，这是商业系统的底线。

写在最后

支付链路的每一条规则背后都是钱。把验签、幂等、对账三件事做扎实，剩下的都是体力活。