在支付中， 你是否了解通道是什么？通道系統設計該如何設計？本文對此進行解析，對相關設計流程進行了梳理，希望對你有所幫助。

一、通道與通道系統基礎

1.1 通道的概念

通道是什么？這個在我們進入支付行業開始，就自然而然進入我們視線的詞，到底意味著什么？

那么我們可以先回顧以下支付的定義：發生在收款人和付款人之間的貨幣債權轉移的過程。

而通道，就是在支付過程中進行貨幣債權（錢）轉移的服務提供方。

舉個例子：我們買個早餐，用支付寶刷了我們的招行信用卡，老板的工行卡收到錢，老板使用的收款工具是收錢吧，收錢吧使用的結算通道是銀聯。這個支付過程中的支付通道是什么？是收錢吧，是支付寶，是工行招行，還是銀聯？

那么從本質上來說我們的錢從我們的招行到了老板的工行卡，因為我們的貨幣債權是由招行轉移到了工行，所以毫無疑問招行是本次的收款通道、工行是本次的結算通道。

那有的人就會說，如果這么說，所有的錢本質上都在銀行或者錢包公司手里，所以通道就只能是銀行或者錢包公司對么？那這中間的支付寶、收錢吧、銀聯又算是什么呢？狹義上來說，確實如此。但廣義上來說，通道的定義并非如此簡單。

需要支付服務的公司就好比是一家超市，所有采購的商品雖然最終都是由廠家來生產，但是超市不會去聯系成千上百個廠家來給自己供貨，雖然廠家直銷價格可能更優惠，但是他依舊會需要一些中間的批發商作為自己的供應商。一家供應商就能解決N種商品的供應，這樣能為超市省下大量的聯系廠家的人工和管理成本。在這個過程中，不管是廠家還是批發商，都成為了超市的供貨通道。支付也是一樣，貨幣債權的直接主體（各個銀行）是通道，但是聚合了各種銀行的三方、四方支付機構，也可以成為通道。

這也是直連通道和間聯通道的由來。在上述例子中，直連通道有：招行、工行；間聯通道有：銀聯、支付寶、收錢吧。雖然目前國內在經過了斷直連改造后，在三方支付機構的視角里，已經沒有直連間聯的說法，但是在跨境領域和境外支付，這種場景還是依舊廣泛存在。

所以很多時候，我們要有一個“通道意識”：我們在對接通道的同時，我們也是客戶的通道，我們對通道提要求的時候，看看自己是否滿足了客戶的要求。

1.2 通道的重要

就如超市一樣，超市本身并不生產商品，他必須依賴廠家或者一些批發市場供貨商供貨，超市才有商品可賣，才能生存，支付機構也需要一個個通道來為自己提供資金處理的能力，這樣支付機構才能為收款人提供收款服務，為付款人提供付款服務。

所以，三方支付機構本質上就是基于支付通道而存在，并在此基礎上而為收付款雙方提供安全、便捷的支付服務的機構。甚至在早期，在支付方案不夠成熟的時代，很多支付機構在大家眼中就是個賣通道的。從這種說法我們也可以明白通道對于一個支付機構的價值。

強如支付寶、微信，也需要客戶先綁定銀行卡。支付通道是三方機構的基石，沒有通道，有再多客戶、再強大的交易清算系統、再強大的解決方案都如空中樓閣，遙不可及。

1.3 通道的分類

對于日常的消費者（收款人或付款人）來說，通道是一個不可見的存在，他們所見的的也許是一個聚合支付的掃碼牌、一個刷卡的pos機、一個支付方式的選擇頁面等等，但是對于我們支付相關的從業者來說，我們應當有能力去識別隱藏在背后的通道和一些簡單的設計原理。

下面，我們選擇用京東、美團、支付寶的支付頁面。

這幾個頁面就是大家所熟知的收銀臺，而在圖里我們可以很明顯的發現，雖然內容完全不一樣，但是由于每個平臺都有很多支付方式可供消費者選擇，所以每個平臺都對支付方式做了不同的分類、集合。但是，分類的原因是什么、合并的原因又是什么？我們先簡單對頁面進行維度的梳理：

• 銀行：每家都有展示綁卡的銀行，而且不止一個；
• 方式：快捷、網銀（一代二代）、分期等
• 卡種：有信用卡也有儲蓄卡；
• 其他賬戶：有白條、小金庫、花唄、錢包余額等；

其他的支付工具：支付寶支付、微信支付。

而之所以有上面的這些分類，一方面是為了讓消費者比較方便的選擇他想要的支付方式，另一方面毫無疑問是因為通道本身也是有區別和分類的。

而通道我們通常會有以下常用的幾個分類：

• 按支付載體分類?？ɑ河勉y行卡直接支付，賬基：用電子錢包支付。
• 按服務主體分類。銀行類：由銀行直接提供通道；三方支付類：由別的三方機構提供通道，如支付寶、微信支付等，四方支付類：有四方機構聚合三方支付提供的通道，如收錢吧這類的聚合支付服務商。
• 按支付場所。線上支付：app支付、網銀支付、線上掃碼支付等。線下支付：pos機、二維碼立牌支付、NFC支付、生物特征支付等等。
• 按支付的用途。收款通道、付款通道、鑒權通道，甚至跨境還有外匯通道等等。
• 按業務形式分類?？旖?、代扣、代付、二維碼、網銀等等。
• 按支持的對象分類。對公通道、對私通道；借記卡、信用卡、存折等等。
• 按區域劃分。境內支付、境外支付、跨境支付（一筆交易同時涉及兩個國家地區的）等等。

還以一些其他維度的分類，就不一一細說了。

每個支付機構根據自己開展業務的范圍和傾向。

都會選擇一種或同時選擇多種分類來對自己的通道進行分類，同時還會采用合理的分類的層級分布。

而分類的目的就是為了梳理每個通道的特點、優點、缺點，以便于更好的使用每一個通道，最終提升自己的服務水平和客戶的支付體驗，同時還能更好的管控成本。

1.4 通道管理系統基礎

支付機構的業務變化往往是伴隨著通道的發展，而業務的不同的階段有不同的通道管理的要求。

1.4.1 通道管理系統的先決條件

在業務模式簡單，而且通道少的時候，我們可能只需要幾句話、幾行備注說明，就能做好通道的管理。每個通道負責處理一類業務，使用上也沒任何困難。

通道稍多的時候，可能我們就不得不借助一個結構合理的excel表，而且可能部分通道出現了功能重復，選擇哪個通道更為合適的問題也出現了，不過這個問題還不算太麻煩，做好通道分類和信息整理，人工還能勉強管理。

通道進一步拓展的時候，靠人工對所有的通道進行高精度的管理已經是非常困難了，經常會出現各個部門或員工之間信息不同步的問題，從而導致了業務出現各種各樣的事故。同時，相似的通道越來越多，如何選擇合適的通道進行支付更是一個非常困難的問題，交易系統的自動化也面臨巨大的困境。所以，如何高效的在公司內同步通道信息、做好成本核算管理工作，并且合理的使用好每個通道的需求就呼之欲出。而通道管理系統也應運而生。

當然，我們首先要明確一個大前提：

通道的復雜性和多樣性是通道管理系統的先決條件。

如果是第一階段，我們可能并不一定需要通道管理系統來支持業務，因為即沒有管理需求也沒有使用上的問題。第二階段，可能只需要部分核心的功能就能較好的滿足展業需求，這個時候并沒有非常迫切的必要去搭建一個比較完整的通道管理的系統，畢竟技術資源也是有限的。只有在第三階段，我們才有搭建完整通道系統的客觀需求。

知道整個通道管理系統的架構非常重要，但是按實際業務情況，從整體功能架構中抽象當前需要的核心模塊，減掉暫不需要的功能，同時為未來拓展打下堅實的基礎，也是產品的必修課。

1.4.2 通道系統的使命

當然，假設我們確實需要搭建一個通道管理系統，那他應該至少包括兩方面的核心功能：

通道的信息管理和通道的使用管理。

前者很好理解，而后者就是我們常說的：路由系統。而兩個功能模塊分別在支付體系內發揮各自的作用。今天，我們先來介紹前者：通道信息系統（后面簡稱通道系統）。路由系統會在后續的章節中再詳細介紹。

設計系統之前，我們先問自己幾個問題：通道系統的核心使命是什么？他需要為誰服務？僅僅只是路由系統嗎？

所以我們需要和每個關心通道的部門同事聊一聊，然后我們可以總結到通道系統的兩個核心使命：

為業務部門提供良好的通道信息管理工具。

讓通道拓展部門了解通道拓展需求；讓運營部門了解每個通道的性能如何；讓銷售部門了解公司現在對外能提供的支付能力；讓財務部門了解每個通道的成本，讓合規部門了解每個通道的風控要求等等。

作為系統各相關功能模塊的通道信息中心。

路由、監控中心需要有信息來保證每筆交易使用最優通道：性能最好、成本最低、高成功率、高穩定性。計費中心需要有信息來統計通道成本，對賬中心需要信息來進行對賬項目和對賬邏輯的處理等等。

這兩個使命就是我們搭建通道系統的核心目標，整個系統的功能都應該為這兩點服務。

換個角度來說：通道系統的核心功能就是對系統內模塊和系統外操作人員做信息輸出，本身基本不參與業務流程。

1.5 通道系統的業務架構

在明白我們的核心需求后，我們來談談怎么設計通道系統。

我們再將兩個核心使命細化，你可以得到下面的圖：

整理成通道系統在整體業務中的的業務架構圖：

二、通道的生命周期與產品架構

2.1 通道的生命周期

在詳細的介紹通道系統如何設計之前，我們首先來介紹下通道的生命周期相關的知識。

通道生命周期就是一個通道在整個業務體系內從商務對接，到技術業務對接，到投產的整個過程。在國內通道同質化極高的情況下，三方機構本身是很少的去對接新的國內支付的通道了，但是商戶對接支付通道以及在跨境支付領域，新通道的對接依舊是個常有的場景。

了解一個通道接入的生命周期、知曉每個節點各部門關注的點、理解其背后的底層需求，對我們設計和優化通道管理系統是非常有幫助的，所以我們也對此做個簡單的介紹。

2.1.1 流程與節點

超市想找一個新的供應商，他會怎么辦？首先他需要先搞清楚，他為什么需要找這個供應商，他需要供應商給他提供什么貨？是拓新商品還是為老商品做個備份？找到了一個供貨商，在確定合作之前，超市需要供應商告知他一些基本情況：供貨的清單、商品的價格、補貨的時效、賬期等等，同時要驗下貨。超市覺得沒問題，那就簽合同，同時超市內部還得和相關的員工同步這個消息。而且，新的商品沒經過市場的考驗，超市一般會先少進點貨，看看市場反應，反響不錯再大量上架，這事終于成了。

從這個例子中，我們可以大致可以將通道的生命周期總結為以下4個階段：

• 拓新——確認需求，尋找符合條件的通道；
• 對接——商務對接，技術對接，業務對接；
• 驗收——測試驗收，生產驗收，試運營；

投產——正式運營，持續關注。

然后我們可以根據具體要做的事務，將其中的幾個關鍵的節點列出來：

接下來讓我們看看這些節點是如何推進，各部門的職責及需要產出的物料分布是什么。了解其職責與產出的需求，我們才能更好的明白，通道系統應該如何去服務他們。

2.1.2 參與方及其負責內容

基于不同的公司架構，每個節點的參與部門或者人員都會有所不同，而且需要完成的工作也會有所區別，這里給到一個角色與分工的示例表，僅做參考：

2.1.3 相關物料

經過整理，我們可以得到下面的角色與物料的表：

至此，我們對整個通道的生命周期，已經有了一個完成的理解，并對每個部門的述求都有了詳盡的了解。此外，我們在上文有提到過，通道系統是同時需要滿足業務部門和業務系統的雙邊信息要求，但是兩者對信息的要求維度其實基本一致。所以通道系統應該輸入的信息和輸出的信息也基本成型了。

2.2 通道系統的產品架構

在理解這通道的生命周期后，我們可以根據階段將通道系統拆分為3個功能模塊：通道接入模塊、通道信息模塊、通道業務數據模塊。

同時，每個模塊都需要有信息的輸入和輸出功能。再結合之前的信息述求?？梢缘玫较旅娴漠a品架構圖：

三、通道系統設計

3.1 通道接入管理

一般來說，我們很少會在系統里專門去設計一個模塊去做通道接入生命周期的管理，因為整體投入的性價比實在太低。所以通常我們會借助一些成熟的OA工具當做工單系統來推進節點、wiki工具做線上文檔管理，來進行這種頻率并不高的商務性流程的管理。

這里整理一些較為具體的工作內容，以作參考：

3.2 通道信息管理架構

通道系統的本質就是提供通道信息的中心，因此這個模塊是通道系統的最為核心的模塊。我們的主要工作都在于如何抽象通道信息并搭建通道系統的信息輸入輸出體系。讓通道系統真正的成為支付體系的基石。

3.2.1 通道的層級

前文我們有提到，通道分類的維度很多，使用符合公司業務需求的分類是架構通道系統的大前提。而往往單一的分類是不足以滿足日常的通道管理需求的，所謂通道的層級就是我們所采用的通道分類維度的先后。

比較常用的一種分類邏輯是首先按業務線分類，而對于很多公司來說，業務線大多由目標客戶群體決定，所以我們對通道的第一層級分類也會基于這個基調而展開。后續的層級，則會更加自由一點，但核心目的都是為了很好的滿足管理需求。

舉個例子，公司兩條主要業務線：境內業務、跨境業務，境內業務線主要服務于零售類商家的日常收款，跨境業務線主要針對出口貿易賣家提供服務。那么我們也許可以采用如下通道分類結構：

又或者，公司主要是為電商平臺提供支付服務，面對的都是個人付款人，那我們也許可以采用如下的分類結構：

一個合理的通道分類，能夠讓我們大大的提升公司的通道管理效率，實現通道系統的價值。分類確定后，通道信息模塊的架構基本就確認了

3.2.2 通道的信息層

做好通道分類之后，接下來就是按分類進行通道信息的抽象了。

我們把我們業務所需要的最小顆粒度的通道信息稱之為：通道能力。

那么如何進行能力的抽象？例如：一個通道的快捷業務支持10個銀行，如果所有銀行的所有參數（費用、時效、體驗、清算等等）一致，而且其他通道的快捷業務特征也如此，那我們可以認為，這個通道有一條快捷的能力，它支持10個銀行，他的能力是XXX。

若10個銀行的特征不一致，則我們需要認為：這個通道有10條10個銀行的快捷能力，他們的能力分別是XXX。

根據前文，以入金通道為例，我們先把初步把通道信息抽象為下圖：

顯然，這么多信息并不便于管理，而且我們會發現，在實際情況中，往往一個合作伙伴會同時擁有多種服務能力，就會出現一個現象：

一個通道可以擁有很多通道能力。

不同的相似通道之間，也有非常多的信息是相似的。從管理上來說，這些通道信息都可以被統一管理。所以我們一般需要在通道能力的管理，維度上面，新增一個信息層級，例如取名為：通道管理。這樣我們就可以在一條數據上維護這些一致的信息了，不需要到N條能力數據上去維護，大大的降低了管理成本。

所以我們可以將通道的信息管理分類拆分為如下兩個層級

通道信息變更的時候，會影響其所有的能力，能力數據變更時，只會影響本條能力。

3.2.3 通道的信息分類

有了信息層級之后，可以進一步的將信息按需求拆分：財務、合規、交易結算等等

3.2.4 通道的數據權限

數據準備的差不多了。那么該該考慮誰能看的問題，也就是數據權限的問題了。

權限，是任何后臺系統設計都必須考慮的要素。而通道信息，作為支付公司的核心信息模塊，權限設計更是其非常重要的一環。

常用的權限有兩類：操作權限、和數據權限。操作權限就是操作員是否有某些頁面、某些按鈕的權限。數據權限就是即便在同一個頁面，不同的人看到數據也是不一樣的。

我們設計通道系統時，一定要考慮功能如何去滿足不同操作權限的操作員的需求，例如我們上文舉例的原型：我們將成本信息和交易信息合并在一個頁面展示，若不設計數據權限，那么我們就無法滿足高級權限人員（可知道通道成本）和低級權限人員（不應該知道通道成本）的需求。那這個設計方案就是不合理的。

另外說句題外話，作為產品經理，應當對數據在數據庫的存儲模式有粗淺的了解。數據庫中的數據表都可以認為是一個個excel表，有行有列。數據權限就是對行數據和列數據分別做權限控制。

我們用兩個例子來解釋這兩種數據權限：

1. 銷售系：不同的銷售在同一個頁面都只能看到自己的商戶數據，這就是行數據權限。
2. 交易查詢頁：后臺運營可以看到每筆交易走了什么渠道、什么成本，客服只能看到每筆交易的狀態和錯誤描述，這就是列數據權限。

當然有時候如果開發資源不充裕，我們也可以取個巧，手工權限，就是一個頁面復制兩遍，各自展示各自的信息，這樣就不需要去實現數據權限了。

總而言之，無法實現權限分離的設計，都是存在缺陷的。我們在設計任何功能時，一定要時刻考慮權限。這個方法不僅限于通道系統設計，任何設計也都是通用的。

3.2.5 通道信息模塊的功能架構

按照功能模塊的使命，結合信息的層級與分類，我們可以基本設計通道信息模塊的功能架構：

3.3 通道信息模塊設計

現在，我們可以來進行具體的系統功能設計了。

3.3.1 模塊設計邏輯

這里我們會用到兩種設計邏輯：

將不同用處的信息分散到不同的頁面上，進行模塊化分開管理。

比如我們會有通道對賬信息管理、通道成本信息管理、通道交易信息管理、通道響應碼管理等等，這樣的好處在于結構清晰，權限采用操作權限設計方案，實現簡單。但因為模塊相互獨立，但是參數相互間有較強的關聯，會帶來一定管理方面的困擾。

將關聯性較強的信息合并在一個頁面進行維護。

比如通道交易信息和成本信息和合規信息，都是后續路由系統的核心信息，那么我們就可以把他們放在一個地方維護，輔助用權限進行數據隔離即可。優勢在于維護方便，但是結構上會相對不夠明了，同時對權限體系的要求也更高，基本需要實現列權限才能按這種方案設計?；蛘吖颈旧韺嘞薰芾硐鄬唵?，也可以使用該方案。

兩者各有優劣，而且通常我們會同時采用這兩種設計邏輯，有機組合才能搭建出一個架構合理，可用性又高的通道系統。

接下來我們給到幾個示例頁面，通道信息頁面是和業務聯系緊密度非常高的功能，因此不同的業務場景，不同的階段，所需要的通道系統也是不一樣的。這里給到的只是一個樣例參考。大家主要參考整個設計思路和信息結構的框架。

3.3.2 通道信息頁面

設計的核心邏輯就是前文提到的通道分類結構和信息層級，只有明確了通道分類，才能清晰的定義通道和能力的管理層級。

在這個例子中，我們用到了4個分類：支付載體、業務形式、支持對象、支持銀行。（當然實際原型中會有類似type切換的交互，截圖中不做展示）。

同時，我們新增了通道編碼的概念，因為大部分公司對通道都是有權限控制的，所以很多時候系統內都會用編碼來代替真實的通道名稱，以作權限控制。

3.3.3 通道能力信息頁面

通道新增后，可自動生成通道能力（部分信息設置默認值后續編輯），也可手工批量新增。

通道能力的字段在于之前提到的各個部門或系統需要的信息。不要抽象無用的字段（比如代付通道的支持銀行），也不要少抽象字段。這個尺度的把控就要求設計者對公司的各業務邏輯都要有一定程度的理解。當然若是真的有所偏差，信息架構合理的情況下，迭代也不是一件麻煩的事情。

由于入金、出金、鑒權通道字段可能有所差異，所以我們需要有不同的頁面來管理各自的能力，當然也可以合并在一個頁面，一切取決于實際情況與設計傾向。法無定法，一切為我們的核心使命服務，保證自己在正確的方向上，即便設計不夠完善，也不會有太大的偏差。

此外通道能力往往會遠多于通道，所以我們設計了批量增改的入口，當然如果業務需要設計復核權限，也可以添加。

3.3.4 通道響應碼管理頁面

通道響應碼管理，參考頁面：

頁面一般由IT和運營同事共同使用，用以保證映射的準確和友好。有新增的響應碼時，應當有默認映射的內容，同事可以自動新增一條記錄，避免異常。

3.3.5 通道參數管理頁面

通道參數管理，參考頁面：

參數管理頁面并非必須頁面，一般由IT相關同事使用，尤其需注意權限。

3.3.6 通道黑名單管理頁面

通道黑名單是針對某些被通道拉黑的主體，但可能尚未被我司拉黑，因此將他置于通道黑名單中進行特定的交易阻斷。黑名單一般適用于整個通道而不是僅限于某個業務類型，一般需要手動維護。黑名單主體將無法被路由到對應通道，主體類型會有：證件號、名稱、卡號等。

通道黑名單管理，參考頁面：

3.3.7 通道備案管理頁面

部分通道有預先備案的業務邏輯，未備案主體無法進行交易。備案過程可能有api或人工，api模式也行可以設定自動備案邏輯。但是無論那種方式，都需要有頁面進行備案信息管理。

通道備案管理，參考頁面：

3.3.8 商戶通道信息頁面

經過上面的功能，我們已經基本實現了通道信息的輸入與輸出，基本滿足了對中后臺員工的管理訴求、系統功能模塊的信息訴求。但是還欠缺一個最重要的功能點，即滿足對客的通道信息輸出。參考京東的收銀臺頁面，對客展示的限額應當是所有通道能力的匯總有效限額，再有銷售同事也需要對公司的通道能力有所了解，這個能力也應該是匯總的通道能力。

所以我們還需要通道系統有產出匯總數據的能力。

通常來說，我們在通道充足的情況下，會通過給不同級別的商戶配置不同的一堆通道能力來說滿足商戶分級的業務述求。一般我們稱之為通道組，具體的配置邏輯我們會在介紹路由系統時詳細說明。所以這里面其實有個小小的流程：

給銷售、客服同事提供的商戶通道信息參考頁面：

整體功能會相對簡單，主要依賴研發同事的實現和通道組的配置。

至此，整個通道核心使命已基本完成。

3.4 通道業務數

任何系統和業務的成長，僅僅滿足于當下是不夠的，所以一定周期的數據分析工作是非常有必要的。如果通道系統能產出分析數據來補上最后一塊拼圖，無疑是一個非常好的收尾。

在這里我們主要會用到兩類數據：統計類數據、分析類數據。我通常也會稱之為結果性數據和過程性數據。

結果性數據：某個通道在某個周期內的交易量、成本、成功率、業務數據分布等等。

過程性數據：通道業務數據的變化，比如一定周期內的環比、同比數據。

一般我們可以選擇用數據報表的形式來展示，大家可以根據各個業務部門的關注重心，為他們定制其需要的業務分析數據，從而反哺通道系統，最終持續強化我們的通道管理能力和通道結構。

最后的話

一定要時刻牢記通道系統的兩個核心使命：為業務部門提供良好的通道信息管理工具，讓系統盡可能詳細的了解每個通道的特征。

深入的了解公司通道生命周期：每個節點會有什么部門參與，他們各自需要做什么。

對通道合理的分類，設計良好的管理架構，抽象信息字段，是搭建通道系統的重中之重。

隨時考慮權限的設計，是檢驗設計主干是否合理的重要方法。

大數據量和數據層級復雜的背景下，如何提高功能的可視化程度、降低操作的難度，需要好好的做些思考。

最后，通道本身就同時具備死板與靈活的特點的，通道系統沒有什么固定的設計方案。我所使用的例子主要還是用以展示設計思路，希望大家活學活用，適合自己的才是最好的。