在之前的幾篇文字中，我們分析了從零開始搭建一個管道聚合SDK服務端所需要應對的幾個最重要的一般性流程。按照文中的内容，我們大可以自己最擅長的語言和工具開發出一套已經可以正常工作的服務端，這個服務端可以應付大多數管道，例如UC，百度，360等等的接入需求，如果你的遊戲隻需要接入這些管道，那麼現在這個服務端已經可以上線工作了。但是，這個世界還是存在這樣一些管道，它們的工作流程和其他的管道不太一緻。為了保持相容性和擴充性，我們需要為這些管道做一些特别的工作。
為了友善說明，我們還是先舉個栗子——VIVO是一家影響力較大的機商管道，而他們的充值流程和上述幾家的不太一樣。下面我們先看看VIVO官方文檔關于充值流程的說明：
----------------------------------------開始引用VIVO官方文檔的分隔線----------------------------------------
1、商戶APP攜帶商品資訊、價格等資訊，請求商戶伺服器；
2、商戶伺服器生成商戶訂單号，并攜帶商戶APP傳遞的商品、價格資訊請求vivo的訂單推送接口；
3、驗證vivo伺服器（訂單推送接口）傳回的消息（驗證簽名、價格、訂單号等），準确無誤之後将訂單推送接口傳回的資訊傳回給商戶APP；
4、商戶APP組織調起vivoSDK的參數（包括訂單推送接口傳回的transNo和accessKey等），調起支付SDK進行支付；
5、Vivo伺服器異步通知商戶伺服器支付成功，商戶伺服器驗證簽名、價格等資訊，準确無誤後，以HTTP狀态碼200傳回。
----------------------------------------引用VIVO官方文檔結束的分隔線----------------------------------------
根據對VIVO官方文檔的解讀，我們很容易發現，和之前的管道充值流程相比，VIVO增加了一步擷取管道訂單号的步驟。這一步驟在其他管道的充值流程中，是由管道的用戶端lib庫包攬的，遊戲用戶端隻需要使用訂單相關資訊作為參數，調用管道用戶端lib庫裡的對應方法，和管道服務端通信并擷取到管道訂單号的工作由管道lib庫封裝掉了。VIVO可能出于安全性的考慮，要求這一步需要由遊戲服務端完成。下圖描述了一般流程和VIVO流程的差别，圖中黑色箭頭即追加流程。（這裡省去了SDK用戶端和服務端的角色，僅描述原始流程）
圖1
了解了VIVO管道的充值流程，我們自然可以發現，由SDK服務端來實作這一特殊流程步驟，我們隻需要将充值流程修改如下：
圖2
其餘步驟和之前相同，追加的步驟就在途中黑色箭頭所示的步驟6～步驟9，可以看到，這一步驟完全由SDK的用戶端和服務端獨立完成，無需變動遊戲的接入邏輯流程。這樣，就由我們的SDK服務端接管了這一特殊通信流程邏輯。在無需遊戲用戶端和服務端做修改的情況下，成功的聚合了VIVO的管道。
VIVO的這種特殊流程隻是目前國内市場各大小管道各自獨立實作的千奇百怪邏輯的其中有代表性的一個範例，為了達到我們的目标，即讓遊戲開發者“一次接入，到處可用”的目的，我們還有很長的路要走。但是基本的處理思路，都是将這些特殊邏輯盡量使用SDK自己的接口封裝起來，對遊戲開發者透明。但是，即使我們使用了這樣一些手段，仍然還是有我們無法簡單封裝的管道邏輯，以應用寶為代表。後文中，我們會以一個專題來介紹如何封裝應用寶的邏輯。
這個項目已開源，大家有興趣可以自己研究或者參照項目編寫自己的聚合SDK
項目位址：https://code.csdn.net/typesdk_code
項目位址：https://github.com/typesdk