经过前两篇文字的分析与设计，我们已经可以搭建出一个能够支持多游戏多渠道的聚合SDK服务端，但这只是理想化状态下的一个简化模型。如果接入渠道的逻辑都是按照理想化的简化过程来构建，那么对于支付的请求，我们可以简化成这样几步：

1. 游戏客户端创建订单。
2. 游戏客户端（通过TYPESDK客户端）调用渠道lib库中相应接口，发起支付。
3. 用户在弹出的支付窗口完成支付。
4. TYPESDK服务端等待渠道服务端的回调，收到回调后通知游戏服务端。
5. 游戏服务端执行发货动作。

但是显然这个简化流程在实际上线时是不够满足需求的，例如第一步的创建订单，在实践中就是不应该由游戏客户端来完成的。订单的创建和状态管理，都应该由游戏服务端来控制，当然，这个修改需要游戏开发时做好支持。下面我们就来考虑一个常见的流程问题，需要TYPESDK服务端和游戏服务端来共同处理。

默认场景下，多数渠道技术框架的设计都是默认一个游戏只有一个服务器回调地址，并不会考虑一个游戏存在多个区服服，多个回调地址的情况。当然更不需要考虑TYPESDK这种多游戏共用统一回调地址的需求场景。所以我们需要在设计SDK服务端时，让系统可以识别渠道发来的回调订单究竟属于哪个游戏的哪个区服，据此向对应的服务器发送发货通知。

但是如我们所知，接收到不同渠道的回调请求时，我们可以获取到的信息是不固定的，没有统一判断的信息。大多数渠道的回调信息中除了订单本身相关的信息，比如支付金额商品名称之外，最多提供一些诸如用户信息和安全性校验相关的信息。而可以利用的字段，最常见的情况就是只有一个叫扩展信息的字段。

这个扩展信息字段，在不同的渠道文档里有不同的名称，诸如“扩展字段”，“透传字段”，“自定义信息”，“保留信息”等，或者诸如此类的其他名称。这个字段在下订单时从游戏客户端传送给渠道服务端并作为订单的一部分保存起来，渠道不会对其做任何处理，在支付完成时，将它原样回调发给游戏服务端。通常，我们用这个字段传送游戏内部产生的订单号。我们需要这个字段发挥更多作用，比如传递订单的游戏信息，区服信息等等等等。但是，首先网络传输的时候，并不合适传送太长的信息；其次，很多渠道还人为限制了这个字段的长度。比较夸张的，只留给了开发者12位的长度限制，要在这么短的字段里强行塞进各种信息，并不合适。

TYPESDK服务端作为开发者自己搭建的统一接入后台，当然同样可以用来保存我们需要的信息。所以我们可以在TYPESDK服务端里存储一份订单信息，这个信息的主键是游戏服务器创建的内部订单号，而内容则包括订单的一些更详细的信息比如创建时间，订单金额，以及订单回调的区服信息。这样，在收到渠道发来的一份特定订单的回调信息时，就可以简单的根据这份订单的内部订单号获取到对应区服的回调地址了。

游戏区服回调地址可以使用配置的方式保存在TYPESDK服务端，然后根据保存订单的区服信息查询。但是更简单的方案是，在保存订单时，由游戏服务器直接在保存订单的时候将完整的URL作为一个字段，传送给TYPESDK服务端，作为订单的信息直接保存起来。

根据以上的做法，改进后的支付-充值流程如下图所述：

流程说明

1. 用户点击某商品的购买按钮时，游戏客户端访问游戏服务器

l  每次点击购买均需要访问游戏服务器并创建内部订单号，并非完成完整支付时才创建

1. 游戏服务端创建内部订单，生成内部订单号并调用TYPESDK服务端的充值信息提交接口
2. TYPESDK服务端保存订单信息。返回提交处理结果
3. 游戏服务端将生成的内部订单号返回游戏客户端
4. 游戏客户端使用内部订单号调用TYPESDK客户端支付接口
5. TYPESDK客户端调用渠道客户端SDK的API弹出支付窗

l  用户在支付窗完成支付

1. 渠道SDK客户端提交订单至渠道服务端
2. 渠道服务端返回充值请求已接受消息至渠道SDK客户端

l  此时充值尚未到帐，充值到帐是一个异步动作。这里返回的消息表示充值动作完成，请求已接受。

1. 渠道SDK客户端处理请求已接受消息。返回TYPESDK客户端
2. TYPESDK客户端包装请求已接受消息，返回游戏客户端
3. 游戏客户端将请求已接受消息通知游戏服务端，修改订单状态

至此就完成了支付流程中的充值这一过程，用户完成了支付金钱给渠道平台。随后渠道平台在确认到帐之后，会异步处理该订单，然后以回调的形式，通知TYPESDK服务端。TYPESDK服务端收到该回调时，就可以根据回调中的内部订单号字段，查询到该订单对应的游戏区服回调地址，并通知对应的游戏服务器了。

回头看我们在本系列文字第一篇里做出的简单充值到帐流程图，就可以将该流程修改如下图所示：

流程说明

1. 充值订单到帐后，渠道服务端异步通知TYPESDK服务端
2. TYPESDK服务端根据内部订单号查询该订单信息
3. TYPE服务端通知游戏服务端发货
4. 游戏服务端收到发货请求后先保存该请求，立刻返回TYPESDK服务端，表示已收到发货请求。
5. TYPESDK返回渠道服务端
6. 游戏服务端异步处理发货逻辑。并通知游戏客户端

这样，我们就比较圆满的解决了这一实际场景中常见的需求。下一章，我们会继续分析这一流程中存在的其他问题，并讨论如何解决。

这个项目已开源，大家有兴趣可以自己研究或者参照项目编写自己的聚合SDK

项目地址：https://code.csdn.net/typesdk_code

项目地址：https://github.com/typesdk

TYPESDK手游聚合SDK服务端设计思路与架构之三：流程优化之订单保存与通知