为什么不创建订单?

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

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

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

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

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

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

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

做程序员得有点程序员的态度,马虎不得!

-- EOF --
发表于: 2014-09-17 22:36
标签: 随笔 吐槽