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

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

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

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

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

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

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

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

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

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

 

二、旧解决方案

        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块的钱包查询余额，如此就解决了不同金额串单的问题了。