这篇文章从发行商角度简单说一下网络游戏行业通用的下单支付流程，和上一篇博文一样，下单也会涉及到多方系统。
下单支付流程
在有对接CP和推广渠道的发行SDK来说，下单流程其实和登录类似，会存在多方系统的订单号，在数据中需要都保存起来，方便查询。
下面从两个场景说明一下游戏下单并完成支付所需要经历的流程。
发行直接推广
发行SDK直接接第三方支付系统和普通支付没有什么区别，下面是大概流程：
-
用户在游戏界面点击购买某个道具的时候，客户端会先向CP服务器下单，此时CP会生成游戏订单信息，包括订单号、商品价格等并返回到客户端。
这个订单信息作用有两点：一是作为后续向用户发送道具查询用；而是作为商务对账使用。
客户端在收到返回信息后，会继续向发行SDK下单，此时会生成SDK订单号，同时需要保存客户端通过CP服务器传来的订单信息。
接下来发行SDK需要向第三方支付系统（比如微信、支付宝）下单，再第三方返回需要的信息后，发行SDK再次把这些信息返回，通过客户端调起支付接口。
客户完成支付后，第三方会向客户端展示支付成功，同时会向发行SDK服务端发送验签信息。
-
发行SDK在接受到验签信息并验签成功后，把CP订单信息传回CP服务端并通知发送道具。
如果对接不同的CP，需要后台填写相应CP的发货接口地址。
CP服务收到发货通知，校验后发送道具。
整个流程大致如此，相比普通下单，这里多了一个CP的订单信息，附一张时序图：
接渠道商推广
如果发行SDK对接了推广渠道的SDK，那么一般情况下就会调用渠道的下单和支付接口。下单时，不同的渠道稍有不同，有的是通过客户端下单，而有的是服务端下单的。
用户支付完成后，渠道都会分别通知客户端和服务端支付结果信息。如果支付成功，客户端会展示支付结果，服务端进行验签然后通知CP发货。
笔者在接过的很多渠道中，只有应用宝是没有服务端通知支付结果的，需要通过客户端通知，SDK服务端收到通知消息后，需要查询应用宝服务端订单信息，再通知CP发货。
这一点和苹果支付很像，像客户端通知支付结果的情况，客户端一定要有轮询机制，避免因为网络等问题出现丢单的情况。
接渠道支付的流程和发行直接接第三方基本一致，只有上面所说的第3点不一样，其实渠道商自己封装了第三方支付方式，把通知消息转换了一下而已。附一张时序图：
总结
以上就是网络游戏下单支付的一些基本流程了，其中在开发过程中，有很多坑需要注意的，支付这一块又是公司业务的命脉，所以开发过程中一定要多留意，测试一定要充分。
希望这篇文章对读者有所帮助，结束。
本文章系博主原创，如需转载，请注明出处。
