手机支付流程之华为补单

首先梳理一下我们游戏目前的支付流程：

1.玩家点击购买

2.客户端发来checkGood协议，游戏服校验当前商品是否限购，是否合理

3.返回客户端校验结果

4.如果成功，可以购买，客户端发起创建订单请求到支付sdk服务器

5.支付sdk创建订单，并返回给客户端，客户端弹出支付的页面

6.客户端支付成功，并通知sdk服务器

7.支付sdk服务器校验成功，通知游戏服务器发货

8.游戏服收到发货通知，发货给客户端

这种支付流程对普通商品是没什么问题的，只要回调发货的延时低，基本能正常走下来，但是服务器是全程不关心支付订单号，只在开始购买之前校验能否购买和收到发货通知进行发货。如果有遇到特殊需求，需要知道下单的订单号信息进行校验或者别的操作时，在客户端请求创建订单成功之后，将订单信息缓存到游戏服务器，在回调通知收到了再删掉，如果一些没有付款的订单，设置一定时长的过期时间。

之前我们按着这个流程运行了一段时间都没问题，后来到了每月月底大包提审时，华为包被拒绝了，理由是支付完后杀掉进程，登录进游戏发现上一笔的支付没有到账，而且不到账的原因也没有跟玩家说明，然后就拒包了，由于我们接入的sdk是公司的聚合sdk，不是直接接入的原生华为sdk，所以对华为的支付流程不是很了解，华为新版支付中，支付完成后，如果玩家不手动点击完成返回到游戏中，华为是不主动通知游戏服务器发货的。

客户端接入的聚合sdk，在下单支付时，本地会缓存订单号，当玩家完成支付杀掉游戏进程，然后重新进入时，前端sdk会拿本地缓存的订单号去询问sdk服务器当前这笔订单的状态，如果检测到这笔订单没有发货，做补单处理。但是我们的前端开发人员对接sdk支付文档的时候这一块没有了解清楚，所以也没有对sdk补单操作进行事件监听，sdk初始化成功之后直接登录进游戏，导致补单和登录进游戏是同步进行的，这样就有一个问题：客户端进游戏拿到的玩家数据是老数据，而后端已经收到sdk服务器的发货通知了。

后来，我们商量了一个尽快解决的方案，新增一个查询接口，里面返回玩家当前最新的道具，充值相关的信息。客户端这边对sdk补单操作进行监听，当补单完成之后，客户端向服务器通过新增接口获取玩家这部分的信息，这是一个临时最快的解决办法，如果发货有延时，那这个查询接口就没办法获取到最新的充值信息，可能需要额外的弹框提示了。