經(jīng)過前兩篇文字的分析與設計，我們已經(jīng)可以搭建出一個能夠支持多游戲多渠道的聚合SDK服務端，但這只是理想化狀態(tài)下的一個簡化模型。如果接入渠道的邏輯都是按照理想化的簡化過程來構建，那么對于支付的請求，我們可以簡化成這樣幾步：

1. 游戲客戶端創(chuàng)建訂單。
2. 游戲客戶端（通過TYPESDK客戶端）調用渠道lib庫中相應接口，發(fā)起支付。
3. 用戶在彈出的支付窗口完成支付。
4. TYPESDK服務端等待渠道服務端的回調，收到回調后通知游戲服務端。
5. 游戲服務端執(zhí)行發(fā)貨動作。

但是顯然這個簡化流程在實際上線時是不夠滿足需求的，例如第一步的創(chuàng)建訂單，在實踐中就是不應該由游戲客戶端來完成的。訂單的創(chuàng)建和狀態(tài)管理，都應該由游戲服務端來控制，當然，這個修改需要游戲開發(fā)時做好支持。下面我們就來考慮一個常見的流程問題，需要TYPESDK服務端和游戲服務端來共同處理。

默認場景下，多數(shù)渠道技術框架的設計都是默認一個游戲只有一個服務器回調地址，并不會考慮一個游戲存在多個區(qū)服服，多個回調地址的情況。當然更不需要考慮TYPESDK這種多游戲共用統(tǒng)一回調地址的需求場景。所以我們需要在設計SDK服務端時，讓系統(tǒng)可以識別渠道發(fā)來的回調訂單究竟屬于哪個游戲的哪個區(qū)服，據(jù)此向對應的服務器發(fā)送發(fā)貨通知。

但是如我們所知，接收到不同渠道的回調請求時，我們可以獲取到的信息是不固定的，沒有統(tǒng)一判斷的信息。大多數(shù)渠道的回調信息中除了訂單本身相關的信息，比如支付金額商品名稱之外，最多提供一些諸如用戶信息和安全性校驗相關的信息。而可以利用的字段，最常見的情況就是只有一個叫擴展信息的字段。

這個擴展信息字段，在不同的渠道文檔里有不同的名稱，諸如“擴展字段”，“透傳字段”，“自定義信息”，“保留信息”等，或者諸如此類的其他名稱。這個字段在下訂單時從游戲客戶端傳送給渠道服務端并作為訂單的一部分保存起來，渠道不會對其做任何處理，在支付完成時，將它原樣回調發(fā)給游戲服務端。通常，我們用這個字段傳送游戲內部產(chǎn)生的訂單號。我們需要這個字段發(fā)揮更多作用，比如傳遞訂單的游戲信息，區(qū)服信息等等等等。但是，首先網(wǎng)絡傳輸?shù)臅r候，并不合適傳送太長的信息；其次，很多渠道還人為限制了這個字段的長度。比較夸張的，只留給了開發(fā)者12位的長度限制，要在這么短的字段里強行塞進各種信息，并不合適。

TYPESDK服務端作為開發(fā)者自己搭建的統(tǒng)一接入后臺，當然同樣可以用來保存我們需要的信息。所以我們可以在TYPESDK服務端里存儲一份訂單信息，這個信息的主鍵是游戲服務器創(chuàng)建的內部訂單號，而內容則包括訂單的一些更詳細的信息比如創(chuàng)建時間，訂單金額，以及訂單回調的區(qū)服信息。這樣，在收到渠道發(fā)來的一份特定訂單的回調信息時，就可以簡單的根據(jù)這份訂單的內部訂單號獲取到對應區(qū)服的回調地址了。

游戲區(qū)服回調地址可以使用配置的方式保存在TYPESDK服務端，然后根據(jù)保存訂單的區(qū)服信息查詢。但是更簡單的方案是，在保存訂單時，由游戲服務器直接在保存訂單的時候將完整的URL作為一個字段，傳送給TYPESDK服務端，作為訂單的信息直接保存起來。

根據(jù)以上的做法，改進后的支付-充值流程如下圖所述：

流程說明

1. 用戶點擊某商品的購買按鈕時，游戲客戶端訪問游戲服務器

l  每次點擊購買均需要訪問游戲服務器并創(chuàng)建內部訂單號，并非完成完整支付時才創(chuàng)建

1. 游戲服務端創(chuàng)建內部訂單，生成內部訂單號并調用TYPESDK服務端的充值信息提交接口
2. TYPESDK服務端保存訂單信息。返回提交處理結果
3. 游戲服務端將生成的內部訂單號返回游戲客戶端
4. 游戲客戶端使用內部訂單號調用TYPESDK客戶端支付接口
5. TYPESDK客戶端調用渠道客戶端SDK的API彈出支付窗

l  用戶在支付窗完成支付

1. 渠道SDK客戶端提交訂單至渠道服務端
2. 渠道服務端返回充值請求已接受消息至渠道SDK客戶端

l  此時充值尚未到帳，充值到帳是一個異步動作。這里返回的消息表示充值動作完成，請求已接受。

1. 渠道SDK客戶端處理請求已接受消息。返回TYPESDK客戶端
2. TYPESDK客戶端包裝請求已接受消息，返回游戲客戶端
3. 游戲客戶端將請求已接受消息通知游戲服務端，修改訂單狀態(tài)

至此就完成了支付流程中的充值這一過程，用戶完成了支付金錢給渠道平臺。隨后渠道平臺在確認到帳之后，會異步處理該訂單，然后以回調的形式，通知TYPESDK服務端。TYPESDK服務端收到該回調時，就可以根據(jù)回調中的內部訂單號字段，查詢到該訂單對應的游戲區(qū)服回調地址，并通知對應的游戲服務器了。

回頭看我們在本系列文字第一篇里做出的簡單充值到帳流程圖，就可以將該流程修改如下圖所示：

流程說明

1. 充值訂單到帳后，渠道服務端異步通知TYPESDK服務端
2. TYPESDK服務端根據(jù)內部訂單號查詢該訂單信息
3. TYPE服務端通知游戲服務端發(fā)貨
4. 游戲服務端收到發(fā)貨請求后先保存該請求，立刻返回TYPESDK服務端，表示已收到發(fā)貨請求。
5. TYPESDK返回渠道服務端
6. 游戲服務端異步處理發(fā)貨邏輯。并通知游戲客戶端

這樣，我們就比較圓滿的解決了這一實際場景中常見的需求。下一章，我們會繼續(xù)分析這一流程中存在的其他問題，并討論如何解決。

這個項目已開源，大家有興趣可以自己研究或者參照項目編寫自己的聚合SDK

項目地址：https://code.csdn.net/typesdk_code

項目地址：https://github.com/typesdk