为什么不创建订单？

网上很多接入支付宝、银联等支付渠道的功能，方便用户完成付款。付款流程通常情况下可分为3个步骤： 收集订单信息并提交到支付渠道 用户在支付渠道页面完成付款 支付渠道收到钱后通知我们发货

第一步，通常我们会产生一条订单记录，并把订单号一起送到支付渠道。付款后支付渠道回调通知会原样返回我们的订单号，我们根据自己的订单号读取订单信息校验后发货。这是常见的流程，不知道有没有人想过如果我们不创建订单为怎么样？

先来看看订单对象应该拥有的属性：订单号、金额、用户ID、物品ID、支付方式、创建时间、附加值（常常用来统计某些方面）等，如果我们不创建订单直接等待支付渠道返回，则送到支付渠道时需要带上这些参数，而支付渠道对于传入方的数据通常会有长度、个数限制，这样子组合估计除了核心数据其他数据都带不了，没法扩展。种种问题随之产生： 数据统计。只能统计到成功订单数据，而且要新增统计项则需要支付渠道支持，很可能字符长度、特殊字符不支持，扩展性差。 不支持先下单后支付，体验不好。 无法自动同步订单状态。通常对实时性要求较高的消费会定时同步支付渠道状态，这里无法保证实时性。 漏单无法处理。不创建订单就没法自动同步，没法处理漏单，只能依靠支付渠道通知和用户反馈。 程序之间相互依赖，对方有调整很有可能影响到自己，自己有调整也可能影响传入的订单信息。

所以这种场景都会创建订单，这估计是不用考虑的问题。但类似的在游戏中却存在很多不创建订单的情况。

游戏通常会接入各种SDK（SDK会集成用户和支付），用户在SDK上登录后，SDK会返回一个唯一的标识给游戏，游戏拿到该标识绑定一个游戏用户。购买流程和上面一致，但购买时很多游戏就不创建订单了。等待SDK通知时返回唯一标识、分区、金额这些参数。

问过几个游戏开发，基本上就说没必要。不需要做数据统计、不需要延迟支付、不需要同步状态，漏单也人工处理了。但不创建也就堵死了之后扩展的方法，出现问题的几率也会增大。当自己有调整时，如果发给SDK的某个参数出错，可能会影响到发货。当对方有调整时，也可能会影响到参数的传入。奇怪的问题就随之产生了。

与其他系统交互应该尽量减少与它之间的依赖，现在对接的游戏各种情况都存在，之后有得苦逼的了。

做程序员得有点程序员的态度，马虎不得！