「 在之前的文章中我們探討了在支付系統中如何設計有效地防重失效機制，今天繼續探討在搭建支付系統時另一個比較關鍵的問題：渠道參數路由化配置如何設計？」

在開發支付系統的時候，我們經常會涉及到對接多個支付渠道，除常見的支付寶、微信外可能還會根據不同的業務場景對接很多其他的支付渠道，如apple pay、銀聯甚至一些海外支付渠道如Adyen、Stripe等。

此外，根據公司業務類型的擴展，以及業務範圍不斷向不同國家、區域的延伸，面臨法律、稅收、區域產業政策等不同因素的影響，同一個支付渠道也會根據業務類型、國家、區域等因素的不同而申請不同的支付商戶號以關聯不同的法律主體。這些問題在公司發展的早期，業務比較簡單的情況下一般是不會遇見，但是一旦隨著公司業務的快速發展這些問題就會逐步顯現出來，而大多數創業公司在早期開發支付系統的時候是很少考慮這些問題的，一方面是時間成本問題，另外一方面也是初創公司真正擁有支付系統研發經驗的工程師比較稀缺，而前期的考慮不足往往也會造成後期支付系統在支撐業務快速發展的過程中顯得舉步維艱，維護成本及業務適配複雜度變得十分高昂。

那麼上述情況會究竟造成什麼樣的問題呢？

從上圖雜亂的關係圖中可以看到，不同的業務線擁有不同的業務，不同的業務及業務線在又擁有不同的支付方式以及不同的支付渠道商戶號，如果業務涉及海外，還會根據不同的國家在具體支付方式選擇上有不同的要求及規則。而這樣的場景也並不是從公司初創開始就這麼複雜，而是隨著業務發展日積月累產生的，在早期構建支付系統的時候如果不加以考慮，隨著業務的快速發展系統就會始終處於一個被動改造的境地，最終代碼中充斥著各種個性化邏輯場景，導致維護成本高昂且極容易出錯導致線上Bug，並且也會導致支付數據緯度混亂，影響對賬、清結算等其他系統邏輯。那麼怎麼設計才能讓渠道管理更加具有擴展性呢？業務模型的定義

根據上述因素，我們可以進行下抽象，具體來說各業務線對於支付平台來說可以理解為商戶（Merchant），在對接支付系統的時候可以為不同的Merchant開通不同的支付商戶ID及介面對接參數；同一個業務線也會有不同的業務，而業務可能比較獨立也可能會與其其他業務存在交叉關係，為了更好的釐清關係，我們對同一個商戶下的不同業務設計成兩個維度：應用（App）、業務類型（BusiType）。

另外比較關鍵的概念就是渠道（Channel）了，可以為對接的不同支付渠道定義Channel編碼進行區分，根據渠道合作方式的不同，有些海外渠道也會存在子渠道（SubChannel）的情況,這種情況一般是主渠道提供技術介面，而具體不同的子渠道直接對Merchant進行資金清結算。不同的渠道也會根據收單場景及不同的交易類型（TradeType），如支付、退款、轉賬、紅包等，提供不同的支付方式（PayMethod）,這些支付方式在國內的情況主要是支付公司根據市場情況的不同而定義的特定支付產品，例如「支付寶App支付」針對移動端App應用的支付場景，「微信小程序支付」針對微信小程序應用的支付場景。而海外支付渠道則可能會根據不同國家的業務發展情況而定，例如Adyen在香港具備本地收單資質，那麼如果希望通過Adyen在香港開展業務，除了可以通過Visa/Master收單外，也可以對接Adyen的ideal（本地化收單）方式。這裡的情況不同渠道表現方式會有所不同，但從我們搭建支付系統的角度看，都可以統一定義為支付方式（PayMethod）。

採用上述幾個概念設計渠道參數配置規則，基本上就能確保支付系統在後續的發展過程中向上能夠優雅地適配業務發展的不同要求，向下可以從容擴展不同的渠道了。並且通過這些定義可以有效地區分支付數據的維度，使得後續的對賬清結算處理更加便捷。

考慮到海外情況及渠道介面版本升級問題，可以再加上國家（Country）、介面版本（Version）兩個要素。

配置模型設計通過上述業務模型的定義，在系統實現時我們需要設計一套配置表，並在渠道對接編碼時按照配置邏輯進行介面參數路由動作，從而讓系統具備渠道管理的配置能力。

基於上述配置模型，我們就可以在業務與渠道參數配置上實現相對靈活的配置與路由了。假設，如果我們在完成微信渠道支付介面的對接並滿足了業務A的支付需求，如果業務B也需要採用微信進行支付，並且申請的是獨立於業務線A的支付商戶信息，那麼此時我們只需要完成渠道參數配置表的配置，並且在開通業務線B商戶ID及應用ID後進行路由規則設置，系統即可完成支持，而不需要進行硬編碼的改造。安全風險及其他

採用配置化方案設計，可以讓支付系統更好地適配後期業務發展帶來的複雜性，但是我們也需要考慮到操作風險，根據以往經驗，不受控的便捷往往會帶來危險，試想下如果因為配置錯誤，原本應該收到B賬戶的錢，被收到了A賬戶，而這兩個賬戶主體完全不同，這種情況不僅會導致資金問題、也會影響支付系統後面的邏輯，例如退款問題等。所以，我們在採用這樣方案的同時，也需要制定嚴格的操作規程，在配置系統上設計更為嚴格的審查流程。

此外，渠道參數屬於敏感信息，在配置上也需要採取必要數據安全措施（如加密），另外，因為這類參數是屬於低頻變更、高頻使用的配置數據，為了系統效率我們往往也採用緩存機制，做好緩存與持久層數據的一致性及緩存數據的安全性也至關重要。後記在支付系統設計的早期，如果我們能適度的對配置化模型加以考慮，雖然，會在一定程度上增加研發成本，但隨著業務發展，這種成本相較於後期對業務適配改造的成本來說，則是可以忽略的。因為，支付系統對於任何互聯網公司來說，都是很關鍵的業務系統，並且一旦上線就處在了高速運轉的模式之下，開著車更換輪子的成本往往比造一輛車的成本更高。並且，從一些公司的實際情況來看，很多都是在處於無法維護或維護成本異常高昂的情況下，重新花費了很大的精力及成本重建了支付系統。做好支付系統涉及很多細節，這裡只是介紹了其中一個比較關鍵的細節內容，希望能對大家有用～如果對上一篇文章感興趣可以??這裡br/>移動端支付系統如何設計有效地防重失效機制？br/> — 完 — 如果覺得小哥在認真寫文章，可以關注下公眾號，支持下哦

weixin.qq.com/r/ey66osv (二維碼自動識別)

推薦閱讀：

相关文章