小程序支付对接的核心原理，是一条严格的时序链：前端向自己后端请求下单→后端调微信统一下单接口拿到支付参数→前端用参数唤起微信支付→用户输密码→微信异步通知后端支付结果→前端轮询后端订单状态确认结果。这条链上每一步都有签名验证，任何一步签名错了，支付就调不起来或回调处理不了。本文按时序把每一步讲清。

下单到唤起支付的时序

后端统一下单与签名生成

用户在小程序里点"立即支付"，前端不是直接调微信，而是先请求自己的后端："我要给订单号A001付款"。后端拿到订单号后，从数据库查出真实金额（不信任前端传的金额），然后组装统一下单参数：商户号、商品描述、订单号、金额（单位分）、回调地址、随机字符串。参数按字典序排序后，用商户密钥做MD5或HMAC-SHA256签名，把签名一起发给微信。

微信验证签名通过后，返回一个prepay_id和一组二次签名参数。后端把这组参数原样返回给前端。做支付对接时，签名是最容易出错的环节：参数排序错一个、字段大小写不对、密钥泄露，微信都会返回签名错误。正规做法是把签名生成代码封装成一个函数，用微信官方示例报文跑一遍验证通过再接业务。

签名生成有几个细节必须注意：一是所有参与签名的字段要按ASCII码字典序排序，不能按参数列表顺序拼；二是空值字段不参与签名；三是签名结果要转成大写；四是商户密钥绝对不能写在前端代码里，密钥泄露等于商户账户不设防。丹棱县做交易类项目，密钥保管要写进安全规范。

前端唤起支付

前端拿到后端返回的支付参数后，调用wx.requestPayment，把时间戳、随机串、支付签名、商户号、小程序ID、package这些参数原样传进去。微信客户端收到后弹出支付密码键盘。这一步前端不做任何业务计算，只是把后端给的参数透传给微信。

前端这层的职责是：唤起失败时给用户友好提示（比如"支付调起失败，请重试"），唤起成功后不要立刻判定支付成功，因为用户可能取消支付。正确做法是唤起后让用户停在支付结果页，轮询自己后端的订单状态，等后端确认收到微信回调后再显示"支付成功"。丹棱县用户支付习惯成熟，对结果页响应速度敏感，轮询间隔太长会让人以为支付失败。

回调通知的时序与验签

回调报文结构与验签步骤

用户真正付款成功后，微信会向后端之前配置的回调地址POST一份XML报文，里面包含：微信订单号、商户订单号、支付金额、用户openid、交易状态、以及一个签名字段。后端收到报文后，第一步不是更新订单，而是先验签：把报文里除签名外的所有字段按字典序重新排序，用商户密钥再算一次签名，和报文里带的签名比对。

签名一致才继续处理，不一致直接返回错误。这一步是资金安全的底线：不验签，攻击者可以自己拼一份"支付成功"的报文发过来，后端不校验就把订单改成已付款，钱没到账货先发了。验签通过后还要校验金额：报文里的金额必须和数据库里订单的应付金额一致，防止有人篡改。

回调处理的响应要求

后端验签和业务处理都完成后，要按微信要求格式返回一个成功应答。如果微信没收到正确应答，它会按递增间隔反复重发回调（共8次左右，间隔从几秒到几小时）。所以后端处理回调必须做幂等：这笔订单已经处理过了，直接返回成功，不要再加一遍库存、再加一遍积分。

回调处理要快。微信等待应答时间有限，如果后端在回调接口里同步做发货、发短信、加积分这些耗时操作，容易超时。正规做法是：收到回调先验签、更新订单状态、立刻返回成功，然后异步队列处理发货和通知。丹棱县做电商类小程序，高峰期回调量大，异步队列还能削峰。

前端轮询兜底

微信回调是服务器之间的事，前端用户看不到。所以前端唤起支付后要轮询自己后端：每两秒查一次订单状态，最多查三十秒。后端一旦收到微信回调把订单改成"已支付"，前端轮询拿到这个状态就跳成功页。如果三十秒还没等到，提示用户"支付结果确认中"，引导他去订单列表自己看——因为回调可能晚到，但订单状态最终一定会更新。

另外还要注意一个边界情况：用户支付过程中杀了小程序。这时候前端轮询停了，但后端回调还是会到。等用户下次打开小程序，前端进订单列表时主动拉一次最新状态，该跳成功页跳成功页，该显示待支付显示待支付。这个边界场景不处理，用户杀进程重进就会以为支付没成功又下一单。

小程序支付接口对接原理的关键，就是这条时序链上每一步的签名都不能错、回调必须验签、前端轮询兜底。把这三件事做扎实，资金流转就不会出岔子。