应用宝不管是之前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