U8SDK——应用宝YSDK新的支付流程

作者: 分类: U8SDK 发布时间: 2016-05-08 10:41 65条评论

应用宝不管是之前MSDK,还是现在YSDK,对于普通网络手游来说,他的支付方式都只能是游戏币托管的方式。之前接MSDK的时候,也是费了九牛二虎之力才搞定,主要就是被他这个所谓的“游戏币托管模式”弄的有点摸不着头脑。因为这个方式,和其他渠道SDK的支付流程还是有区别的。

其实,“游戏币托管模式”,就是字面意思。比如, 我们游戏中的玩家充值得到的是元宝,当玩家充值之后,我们在该玩家的角色数据中有一个元宝数量的字段,用来存储当前玩家身总共有多少元宝。而应用宝说, 嘿, 你们不需要这个字段了,玩家充值的时候,玩家身上的元宝数量,就存在我这里了。 你需要查询元宝数量的时候,调用我提供的api,到我这里来查询就好了。

那我要问了, 那玩家用元宝购买游戏中的道具时,怎么办呢? 我需要扣除对应的元宝啊。 应用宝又说了,嘿,我已经替你想好了,所以我提供了一个扣款的API,当玩家购买道具(消费)的时候,直接调用扣款的API来扣除对应的元宝数量就好了。

这样的处理方式,需要我们将SDK接入和游戏逻辑过度耦合在一起,而且接入过程过于复杂,游戏中消费的地方,可能都需要去调用扣款的api以及查询同步余额。

之前MSDK的时候,我们采用了单独的策略,就是“玩家充值完成,立即扣款全部”,从而将充值和消费的过程合二为一。但是,这样有一个意外情况,就是丢单的处理方式。 因为丢单的存在,导致,我们也无法根据订单号来区分玩家当前余额中对应的是哪个订单。具体可以看我们之前写的MSDK接入的备忘录

所以,之前MSDK,U8Server是为应用宝单独处理,同时提供单独的数据库表。不需要下单的过程,在玩家支付成功之后,立即通知U8Server查询余额并扣款,同时,玩家登陆的时候,。查询到的余额,其实就是玩家游戏中的元宝,然后通知游戏服务器,游戏服务器单独提供一个处理应用宝的接口,当收到这个的时候,直接给玩家身上增加对应的元宝。

但是,这种流程,导致游戏服务器需要提供两个回调地址来处理支付逻辑。一个是普通渠道的,一个是应用宝的,增加了游戏服务器的工作量,而且更多时候,是困惑了渠道SDK的接入者和服务器端的同学。

现在,应用宝推出了全新的YSDK,但是YSDK中支付接入的依然是米大师,之前MSDK中支付也是米大师。所以,支付接入方式本质上还是一样的。

老的流程,我们在U8Server对YSDK做了兼容,之前MSDK的用户,切换到YSDK之后,老的流程依然是通用的。

现在,我们提供了一个新的支付流程,新的支付流程,我们依然采用订单的方式,u8server处理完成之后,依然是通过和其他渠道SDK一样的方式通知游戏服务器,也就是游戏服务器不需要再为应用宝提供一个单独的处理接口。

同时,新的支付流程上,我们也稍微调整了下。 之前的流程是, 玩家登陆的时候,查询余额并扣款,作为补单的方式。然后支付完成之后,里面查询余额并扣款。现在,我们新的流程是这样:

支付之前,先查询余额,如果余额充足,就使用余额支付(这些余额就是之前可能丢单的),如果余额不足,就调出支付界面进行支付。支付完成的时候,直接调用扣款接口,进行扣款,扣款完成,和其他渠道SDK一样,通知游戏服务器发放游戏币

现在新的支付处理类,已经上传到U8Server了,需要的用户,请同步最新的U8Server的代码。对应的处理类是com.u8.server.web.YSDKNewPayAction

本文出自 U8SDK技术博客,转载时请注明出处及相应链接。

本文永久链接: http://www.uustory.com/?p=2065

评论功能已经关闭,请加入U8SDK技术群进行讨论和咨询:207609068
Ɣ回顶部
U8SDK技术群 x
技术同学请加入
点击加入