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

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

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

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

默认场景下，多数渠道技术框架的设计都是默认一个游戏只有一个服务器回调地址࿰