應用寶不管是之前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

總結

以上是生活随笔為你收集整理的php 应用宝支付,U8SDK——应用宝YSDK新的支付流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。