支付管道是指能夠提供資金流轉功能的通道，我們常見的支付方式都要通過對應的支付通道來完成。支付管道需要進行管理，那麼為什麼需要對支付管道進行管理呢？下面通過場景說明其必要性。
支付管道，也可以叫支付通道，是指能夠提供資金流轉功能的通道，包括但不限于銀行、第三方支付機構。我們常見的借記卡（儲蓄卡）、貸記卡（信用卡）、微信、支付寶、雲閃付等支付方式，都是通過對應的支付通道完成支付的。
支付管道管理，通俗了解就是對支付管道的管理， 為什麼需要對支付管道進行管理呢？下面通過場景說明其必要性。
場景一
電商公司A，在初期，為了使産品快速的成型上線，支付是輔助功能，支付收銀台設計的是一個簡單的收銀台，隻有【支付寶】，那我們該如何實作呢？
支付收銀台隻有一個支付方式——支付寶，是固定的，對應支付通道也是一個固定的，支付的時候直接請求支付寶就可以，調用流程簡化如下
場景二
還是這個公司A，産品上線之後，業務發展的不錯，産品也不斷的疊代，單一的支付方式無法滿足業務發展，收銀台會發展到這樣
相比于場景一，支援了更多的支付方式，這意味着需要接入更多的支付通道。後續也有可能會支援更多的支付方式，也就有可能需要接入新的支付通道。這個時候我們就需要思考了，比如下面的幾個問題：
通道很多，如何對它們進行統一的維護呢？
當同一個支付方式有多個通道的時候，如何進行通道選擇（即支付通道路由）？
後面如果新增通道，如何能靈活的進行添加呢？
這些可以總結為：需要對支付管道進行管理。那支付管道管理是管理什麼？以及怎樣進行支付管道管理的設計呢？下面就以電商平台為例，進行支付管道管理的設計。
01 場景分析
電商平台（以下簡稱平台A）的交易業務流程（擔保交易）可以描述為以下幾步。
1. 買家通過平台A購買商品：下單并支付完成；
2. 賣家收到訂單，進行發貨；
3. 買家收到包裹後，确認收貨；
4. 平台A進行資金結算（按平台的結算規則），結算到賣家平台賬戶；
5. 賣家可以在平台A進行提現，提到賣家自己的銀行卡。
在這個過程中，也可能發生退款，可以分為2類——售前退款和售後退款：
a）售前退款：買家下單支付成功之後，确認收貨之前的退款。
b）售後退款：買家确認收貨之後的退款。
兩者主要的差異是退款的錢由誰來出，售前退款因為資金還沒有結算給商家，是以資金是從平台A退給買家；售後退款就需要從商家的賬戶退給買家。
我們對上述流程進行簡化，重點突出與支付管道相關的部分，如下圖所示。我們拆分成3個流程進行支付管道需求分析：
1.1 支付流程
對平台A來說，首當其沖的是要保證使用者能支付成功；其次才是其他的，比如通道的成本、使用者體驗等。分析管道管理的功能：
（1）管道的基本資訊管理維護
管道支援哪些支付方式。收銀台展示的支付方式都可以走哪些管道。
管道的狀态維護。例如某一個管道現在有問題，那後續的交易是不能繼續發到這個管道的，需要維護成下線或者不可用。有的管道有日常維護，比如每天的淩晨0點-1點不可用，需要增加管道的維護時間配置。
（2）管道路由
根據使用者支付方式，選擇一個最優的支付管道。影響路由可能的因素，比如：通道費率、買家是否已經在某個通道支付過、管道是否支援、管道目前是否可用、支付環境（比如微信環境有h5、小程式、sdk，設計的時候可能會定義成不通的通道），以及也有可能會有一些業務上的限制，比如跨境交易隻能走固定的幾個通道。
（3）補單流程
正常情況下，管道側支付成功後，都會主動發送回調通知，告訴平台這筆訂單的狀态，但是如果出現了意外，管道的通知服務異常了，單純依靠管道的回調就有問題了，使用者銀行卡已經扣錢了，但是平台的訂單還是待支付，是以為了避免這種情況的發生，就需要有補單任務，主動去管道查詢訂單狀态。
（4）錯誤代碼映射
提升使用者體驗。一般如果支付失敗，管道都會傳回對應的錯誤代碼以及錯誤原因，但是有些管道，特别是銀行卡支付的時候，因為失敗的原因有很多種，且管道直接傳回的原因，如果直接展示給使用者的話，使用者不一定能了解，是以需要做一層轉換，轉換成使用者容易了解的文案。
1.2 退款流程
退款都是原路退，即支付的時走的銀聯，退款的時候也走銀聯管道退款。但是也有情況例外，比如：
超過通道的原路退款時間：每個通道不盡相同，有的是一年、兩年或者更久，也有個的隻有6個月，比如微信支付寶。超過期限就不能原路退了。
原路退異常：比如微信賬号登出、卡登出等等。
是以退款這裡，還需要考慮下無法原路退的情況，應該如何處理。
1.3 提現流程
這塊涉及的功能和支付流程類似。需要額外考慮的是如果所有的提現管道都有問題的時候，提現流程如何進行處理。
02.支付管道管理設計
2.1 支付管道管理總體架構設計
根據上一部分的業務場景分析，支付管道管理系統的架構設計如下：
2.2 支付管道路由
（1）路由要素分析
路由要素有很多，下圖列了一下常見的要素。
管道與支付方式的映射關系：是某個支付方式可以走哪個管道的關鍵配置。
通道限額：除了微信或者支付寶支付的，銀行卡支付通道都是有單筆支付限額，以及日限額。
管道狀态：管道目前是否可以用。
管道權重：比如建設銀行-借記，送出篩選完之後，還有2個管道可以用，這個時候就需要通過配置的權重，選擇有限走哪個管道。
白名單：管道上配置白名單，白名單類型可以是卡号、買家使用者ID、賣家使用者ID，如果配置了白名單，在滿足管道條件之後，會優先走這個通道。
産品碼：做業務區分。根據前面場景分析，某些管道隻能走特定的業務。
支付環境：同一種支付方式在不同的環境路由到不同的管道。比如微信支付，可能的支付環境有：微信小程式環境、微信h5環境、SDK環境、浏覽器環境，環境不一樣，實際發送管道請求的參數也不一樣，是以需要進行區分。
管道費率：每個管道都會收手續費，會有一個費率配置。在實際路由配置的時候，費率選擇問題可以和權重進行合并，營運人員直接根據産品政策，配置管道權重，以達到目的。
維護時間：通道會有維護時間，即某段時間不能接受交易請求。銀行類的交易，維護比較常見。
（2）路由邏輯
核心邏輯是——選擇一個最優的可以使用的通道。其選擇過程如圖所示：
條件過濾：根據請求參數，選出所有符合條件的管道集合。實作起來比較簡單，配置好條件，篩選的時候逐個進行比較，如果符合就繼續下一個條件，如果不符合就中止，進行一個下一個管道篩選。
管道選擇：從可用的管道集合中選擇一個最優的管道。一般會進行一個打分制，需要配置分數規則，比如配置的費率規則：
把所有的分數進行加和，就是這個管道的分數，最後傳回一個分數最高的管道。比較特殊的，如果命中了白名單，則可以直接傳回這個管道。
（3）退款管道路由
退款管道的路由很簡單，就是退款的時候擷取到原單管道，那麼這個管道就是退款管道。
2.3 統一結果碼映射
這裡不僅有支付失敗的錯誤文案映射，也還有訂單狀态的映射，因為管道的傳回封包有對應的傳回碼，這個在對接時候，管道方會告知哪些傳回碼是成功的。這塊的處理流程如下：
2.4 補單邏輯
不管是支付、退款還是提現，補單流程是統一的，如下圖所示（圖十一）：
不同的是，支付/退款/提現的查詢，需要請求不同的接口，需要跟進訂單類型進行适配。
2.5 退款超期處理
這裡說的超期包含2種情況：
一是這筆退款訂單的處理超過了一定的時間還沒成功，我們就認為可能是有問題。這個時間是多少呢？不同管道還不一樣，微信或者支付寶的退款一般是很快的，銀行卡的退款可能會慢一點，最長可能會到幾天才會成功，是以這個時間配置在管道配置裡；
二是這個筆訂單像上面說的幾種情況，沒辦法原路退款了。
這2種情況我們都是需要發現并解決的，畢竟最終是需要把錢退給買家的，是以我們需要把這部分訂單找出來，然後進行處理就好。整個處理流程可以設計如下：
這塊核心就是需要把這個訂單發送到【線下處理系統】（一個能承載這部分訂單且能串通這個流程的系統即可）。對于處理方式，常見的有：
聯系買家，進行線下打款，打一筆資金到買家的銀行賬戶或其他的收款賬戶。
如果是管道系統問題，可以再把退款單進行原單重新發送（前提是管道支援重複發送）。
03 支付管道管理背景
3.1 支付銀行管理
這裡的支付銀行和收銀台側支付方式對應，是用于後面配置支付管道路由。
3.2 支付管道管理
支付管道管理維護了支付通道的基本資訊。描述為：哪個機構（外部機構的簡稱）、什麼業務（入款、出款等）、什麼支付類型（借記、貸記管道）的通道，并為其定義一個在該支付平台的唯一通道編碼。其中：
- 修改：對管道基本資訊進行修改；
- 配置接口參數：對這個管道的接口請求參數進行配置；
- 銀行配置：配置這個管道能支援哪些支付銀行。
3.3 管道路由
管道路由維護了支付銀行和支付管道的一些條件，如果需要修改。
3.4 白名單管理
白名單管理是為某個使用者或者是卡号添加管道白名單，在白名單清單裡，管道路由的時候有優先走這個管道。
專欄作家
陳天宇宙，微信公衆号：陳天宇宙，人人都是産品經理專欄作家。多平台支付領域專欄作者，十年資深産品；專注為10萬支付産品經理和支付機構以及企業提供深度支付内容和服務！
本文原創釋出于人人都是産品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。