微信小游戏内购米大师支付，不同金额创单问题处理-Toy模板网

这篇具有很好参考价值的文章主要介绍了微信小游戏内购米大师支付，不同金额创单问题处理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、问题描述
微信小游戏的内购支付，接入的是米大师支付。先简单介绍下通用逻辑：

1）、用户点击游戏内下单

2）、客户端构造订单物品等参数并发给服务端

3）、服务端接收后，生成唯一订单号等内部逻辑处理后，返回客户端下单需要的参数

4）、客户端调用微信下单接口，wx.requestMidasPayment(Object object) | 微信开放文档，并将结果上报给服务端

5）、服务端根据客户端的支付上报结果，分时轮询对应订单的用户余额

6）、对用户余额进行扣款，并修改对应订单状态

7）、通知游戏服务端订单状态，并发货给用户

初看，逻辑很清晰，没啥问题，但是第4步经常会返回错误的结果（客户端），比如没有返回（比较多出现）或者说用户支付了但返回支付失败（相对比较少）。这样就导致部分用户支付后没有得到应有的物品，掉单。

微信小游戏内购米大师支付，不同金额创单问题处理

文章来源地址https://www.toymoban.com/news/detail-494371.html

二、旧解决方案

1）通过上面问题描述，知道靠客户端返回的结果不可靠，那为了用户不掉单，就只能自己想办法了，曲线救国。首先就是服务端不依赖于客户端的返回结果才去请求验证用户余额，或者说没收到返回的时候依然去请求验证用户余额（失败的如果压力不大，订单少也可以请求验证，成）。这样就保证了订单都有轮询到去验证。这样虽然解决了掉单问题，但是衍生出了新的麻烦。

2) 麻烦就是，所有订单都轮询了，这样就包含很多用户实际没支付的订单，这样就容易出现串单问题了。串单原因就是，微信是通过用户查询余额的，并没有订单啥事。那假如用户查询到余额有12块钱，用户有两笔6块和一笔12块的订单。那查询到的这12块钱，到底算2笔6块身上，还是12块订单身上呢。要知道用户支付到轮询结果是有时间差的，并不是即时结果。这样甚至会出现先扣了小金额的，比如先扣了1笔6块，后面的12块订单也不够余额扣款了。

3）为了减少串单问题，之前我们这边的做法就是如果余额不等于订单金额，就先记录下来，等用户所有订单查询完，再先扣大金额订单后扣小金额订单。这样虽然能减少部分串单情况，但依然没彻底解决问题，偶尔也会跑出一两笔串单的，这时候就得手动折腾处理了，很是麻烦

4）这个问题由来已久，最开始18年接入时候询问的，至今没找到啥好办法，一度怀疑是只有我们遇到而已

小游戏米大师支付串单 | 微信开放社区

微信小游戏内购米大师支付，不同金额创单问题处理

三、新方案

1）串单解决思路，就是无法确定哪笔订单是有实际支付的，以前一直停留在这个思路上，一直没找到合适方案。后面经同事提醒转变了思路，不能区分订单，就区分订单金额，手动给订单区分，比如6块钱的一类，12块钱的一类，这样至少6块不会串到12块的来，就是剩下可能的串单也是同金额的串，就问题不大了。

2）重新查看【wx.requestMidasPayment(Object object) | 微信开放文档】这个接口说明，看到里面有一个zoneId分区的参数，我们的解决方式就通过这个参数。我们先按照游戏内可能的金额挡位配置分区，或者将微信里面所有挡位都配置上。然后用户下单请求接口的时候，根据订单金额，带上对应的分区。这样相当于用户钱包人为区分成多个小钱包，每个小钱包对应不同的订金额，6块的就只去6块的钱包查询余额，如此就解决了不同金额串单的问题了。

微信小游戏内购米大师支付，不同金额创单问题处理