小程序内虚拟商品的标准交易与交付流程
订阅
用户下单生成outTradeNo,微信支付后推送发货通知,服务端验签、幂等校验并发货;前端回调不可靠,需配合定时查单补发。
一、标准支付与发货完整时序
用户点击购买
→ 前端请求自身业务服务器下单
→ 服务器生成唯一商户单号 outTradeNo,保存待支付订单
→ 服务器计算签名,返回签名后的 payData
→ 前端调用 wx.requestVirtualPayment 拉起微信虚拟支付收银台
→ 用户支付成功
→ 微信平台向开发者服务器推送发货通知 xpay_goods_deliver_notify
→ 开发者服务器:验签 → 幂等校验 → 给用户账号发货
→ 开发者服务器返回 HTTP 响应:{"ErrCode": 0}
二、两个关键订单号区分
| 订单号字段 | 生成方与作用 |
|---|---|
| outTradeNo | 商家业务系统自行生成的唯一单号。下单时必填,全局必须唯一,用于业务关联。 |
| wx_order_id | 微信平台在用户支付成功后生成的平台单号。用于跟踪订单、发货、对账及幂等去重。 |
三、发货机制与兜底方案
- 以服务端推送为主:实际发货必须以微信服务器推送的
xpay_goods_deliver_notify事件为主。 - 前端回调不能作为发货依据:前端
wx.requestVirtualPayment的success回调可能受网络波动、用户闪退等影响而丢失,严禁只凭前端回调直接发货。 - 定时查单补发机制:为防止网络异常导致推送丢失,开发者服务器应设置定时任务调用
/xpay/query_order接口查单,发现已支付但未发货的订单及时补发货。
四、幂等性要求
微信推送可能因重试机制重复到达同一订单通知。服务端处理时必须使用
wx_order_id 或 outTradeNo 进行幂等去重判断,确保同一笔交易永远只发货一次,防止资损。
阅读全文

请先 登录后发表评论 ~