萬字解析“通道系統(tǒng)設計”
在支付中, 你是否了解通道是什么?通道系統(tǒng)設計該如何設計?本文對此進行解析,對相關(guān)設計流程進行了梳理,希望對你有所幫助。
一、通道與通道系統(tǒng)基礎
1.1 通道的概念
通道是什么?這個在我們進入支付行業(yè)開始,就自然而然進入我們視線的詞,到底意味著什么?
那么我們可以先回顧以下支付的定義:發(fā)生在收款人和付款人之間的貨幣債權(quán)轉(zhuǎn)移的過程。
而通道,就是在支付過程中進行貨幣債權(quán)(錢)轉(zhuǎn)移的服務提供方。
舉個例子:我們買個早餐,用支付寶刷了我們的招行信用卡,老板的工行卡收到錢,老板使用的收款工具是收錢吧,收錢吧使用的結(jié)算通道是銀聯(lián)。這個支付過程中的支付通道是什么?是收錢吧,是支付寶,是工行招行,還是銀聯(lián)?
那么從本質(zhì)上來說我們的錢從我們的招行到了老板的工行卡,因為我們的貨幣債權(quán)是由招行轉(zhuǎn)移到了工行,所以毫無疑問招行是本次的收款通道、工行是本次的結(jié)算通道。
那有的人就會說,如果這么說,所有的錢本質(zhì)上都在銀行或者錢包公司手里,所以通道就只能是銀行或者錢包公司對么?那這中間的支付寶、收錢吧、銀聯(lián)又算是什么呢?狹義上來說,確實如此。但廣義上來說,通道的定義并非如此簡單。
需要支付服務的公司就好比是一家超市,所有采購的商品雖然最終都是由廠家來生產(chǎn),但是超市不會去聯(lián)系成千上百個廠家來給自己供貨,雖然廠家直銷價格可能更優(yōu)惠,但是他依舊會需要一些中間的批發(fā)商作為自己的供應商。一家供應商就能解決N種商品的供應,這樣能為超市省下大量的聯(lián)系廠家的人工和管理成本。在這個過程中,不管是廠家還是批發(fā)商,都成為了超市的供貨通道。支付也是一樣,貨幣債權(quán)的直接主體(各個銀行)是通道,但是聚合了各種銀行的三方、四方支付機構(gòu),也可以成為通道。
這也是直連通道和間聯(lián)通道的由來。在上述例子中,直連通道有:招行、工行;間聯(lián)通道有:銀聯(lián)、支付寶、收錢吧。雖然目前國內(nèi)在經(jīng)過了斷直連改造后,在三方支付機構(gòu)的視角里,已經(jīng)沒有直連間聯(lián)的說法,但是在跨境領(lǐng)域和境外支付,這種場景還是依舊廣泛存在。
所以很多時候,我們要有一個“通道意識”:我們在對接通道的同時,我們也是客戶的通道,我們對通道提要求的時候,看看自己是否滿足了客戶的要求。
1.2 通道的重要
就如超市一樣,超市本身并不生產(chǎn)商品,他必須依賴廠家或者一些批發(fā)市場供貨商供貨,超市才有商品可賣,才能生存,支付機構(gòu)也需要一個個通道來為自己提供資金處理的能力,這樣支付機構(gòu)才能為收款人提供收款服務,為付款人提供付款服務。
所以,三方支付機構(gòu)本質(zhì)上就是基于支付通道而存在,并在此基礎上而為收付款雙方提供安全、便捷的支付服務的機構(gòu)。甚至在早期,在支付方案不夠成熟的時代,很多支付機構(gòu)在大家眼中就是個賣通道的。從這種說法我們也可以明白通道對于一個支付機構(gòu)的價值。
強如支付寶、微信,也需要客戶先綁定銀行卡。支付通道是三方機構(gòu)的基石,沒有通道,有再多客戶、再強大的交易清算系統(tǒng)、再強大的解決方案都如空中樓閣,遙不可及。
1.3 通道的分類
對于日常的消費者(收款人或付款人)來說,通道是一個不可見的存在,他們所見的的也許是一個聚合支付的掃碼牌、一個刷卡的pos機、一個支付方式的選擇頁面等等,但是對于我們支付相關(guān)的從業(yè)者來說,我們應當有能力去識別隱藏在背后的通道和一些簡單的設計原理。
下面,我們選擇用京東、美團、支付寶的支付頁面。
這幾個頁面就是大家所熟知的收銀臺,而在圖里我們可以很明顯的發(fā)現(xiàn),雖然內(nèi)容完全不一樣,但是由于每個平臺都有很多支付方式可供消費者選擇,所以每個平臺都對支付方式做了不同的分類、集合。但是,分類的原因是什么、合并的原因又是什么?我們先簡單對頁面進行維度的梳理:
- 銀行:每家都有展示綁卡的銀行,而且不止一個;
- 方式:快捷、網(wǎng)銀(一代二代)、分期等
- 卡種:有信用卡也有儲蓄卡;
- 其他賬戶:有白條、小金庫、花唄、錢包余額等;
其他的支付工具:支付寶支付、微信支付。
而之所以有上面的這些分類,一方面是為了讓消費者比較方便的選擇他想要的支付方式,另一方面毫無疑問是因為通道本身也是有區(qū)別和分類的。
而通道我們通常會有以下常用的幾個分類:
- 按支付載體分類??ɑ河勉y行卡直接支付,賬基:用電子錢包支付。
- 按服務主體分類。銀行類:由銀行直接提供通道;三方支付類:由別的三方機構(gòu)提供通道,如支付寶、微信支付等,四方支付類:有四方機構(gòu)聚合三方支付提供的通道,如收錢吧這類的聚合支付服務商。
- 按支付場所。線上支付:app支付、網(wǎng)銀支付、線上掃碼支付等。線下支付:pos機、二維碼立牌支付、NFC支付、生物特征支付等等。
- 按支付的用途。收款通道、付款通道、鑒權(quán)通道,甚至跨境還有外匯通道等等。
- 按業(yè)務形式分類??旖?、代扣、代付、二維碼、網(wǎng)銀等等。
- 按支持的對象分類。對公通道、對私通道;借記卡、信用卡、存折等等。
- 按區(qū)域劃分。境內(nèi)支付、境外支付、跨境支付(一筆交易同時涉及兩個國家地區(qū)的)等等。
還以一些其他維度的分類,就不一一細說了。
每個支付機構(gòu)根據(jù)自己開展業(yè)務的范圍和傾向。
都會選擇一種或同時選擇多種分類來對自己的通道進行分類,同時還會采用合理的分類的層級分布。
而分類的目的就是為了梳理每個通道的特點、優(yōu)點、缺點,以便于更好的使用每一個通道,最終提升自己的服務水平和客戶的支付體驗,同時還能更好的管控成本。
1.4 通道管理系統(tǒng)基礎
支付機構(gòu)的業(yè)務變化往往是伴隨著通道的發(fā)展,而業(yè)務的不同的階段有不同的通道管理的要求。
1.4.1 通道管理系統(tǒng)的先決條件
在業(yè)務模式簡單,而且通道少的時候,我們可能只需要幾句話、幾行備注說明,就能做好通道的管理。每個通道負責處理一類業(yè)務,使用上也沒任何困難。
通道稍多的時候,可能我們就不得不借助一個結(jié)構(gòu)合理的excel表,而且可能部分通道出現(xiàn)了功能重復,選擇哪個通道更為合適的問題也出現(xiàn)了,不過這個問題還不算太麻煩,做好通道分類和信息整理,人工還能勉強管理。
通道進一步拓展的時候,靠人工對所有的通道進行高精度的管理已經(jīng)是非常困難了,經(jīng)常會出現(xiàn)各個部門或員工之間信息不同步的問題,從而導致了業(yè)務出現(xiàn)各種各樣的事故。同時,相似的通道越來越多,如何選擇合適的通道進行支付更是一個非常困難的問題,交易系統(tǒng)的自動化也面臨巨大的困境。所以,如何高效的在公司內(nèi)同步通道信息、做好成本核算管理工作,并且合理的使用好每個通道的需求就呼之欲出。而通道管理系統(tǒng)也應運而生。
當然,我們首先要明確一個大前提:
通道的復雜性和多樣性是通道管理系統(tǒng)的先決條件。
如果是第一階段,我們可能并不一定需要通道管理系統(tǒng)來支持業(yè)務,因為即沒有管理需求也沒有使用上的問題。第二階段,可能只需要部分核心的功能就能較好的滿足展業(yè)需求,這個時候并沒有非常迫切的必要去搭建一個比較完整的通道管理的系統(tǒng),畢竟技術(shù)資源也是有限的。只有在第三階段,我們才有搭建完整通道系統(tǒng)的客觀需求。
知道整個通道管理系統(tǒng)的架構(gòu)非常重要,但是按實際業(yè)務情況,從整體功能架構(gòu)中抽象當前需要的核心模塊,減掉暫不需要的功能,同時為未來拓展打下堅實的基礎,也是產(chǎn)品的必修課。
1.4.2 通道系統(tǒng)的使命
當然,假設我們確實需要搭建一個通道管理系統(tǒng),那他應該至少包括兩方面的核心功能:
通道的信息管理和通道的使用管理。
前者很好理解,而后者就是我們常說的:路由系統(tǒng)。而兩個功能模塊分別在支付體系內(nèi)發(fā)揮各自的作用。今天,我們先來介紹前者:通道信息系統(tǒng)(后面簡稱通道系統(tǒng))。路由系統(tǒng)會在后續(xù)的章節(jié)中再詳細介紹。
設計系統(tǒng)之前,我們先問自己幾個問題:通道系統(tǒng)的核心使命是什么?他需要為誰服務?僅僅只是路由系統(tǒng)嗎?
所以我們需要和每個關(guān)心通道的部門同事聊一聊,然后我們可以總結(jié)到通道系統(tǒng)的兩個核心使命:
為業(yè)務部門提供良好的通道信息管理工具。
讓通道拓展部門了解通道拓展需求;讓運營部門了解每個通道的性能如何;讓銷售部門了解公司現(xiàn)在對外能提供的支付能力;讓財務部門了解每個通道的成本,讓合規(guī)部門了解每個通道的風控要求等等。
作為系統(tǒng)各相關(guān)功能模塊的通道信息中心。
路由、監(jiān)控中心需要有信息來保證每筆交易使用最優(yōu)通道:性能最好、成本最低、高成功率、高穩(wěn)定性。計費中心需要有信息來統(tǒng)計通道成本,對賬中心需要信息來進行對賬項目和對賬邏輯的處理等等。
這兩個使命就是我們搭建通道系統(tǒng)的核心目標,整個系統(tǒng)的功能都應該為這兩點服務。
換個角度來說:通道系統(tǒng)的核心功能就是對系統(tǒng)內(nèi)模塊和系統(tǒng)外操作人員做信息輸出,本身基本不參與業(yè)務流程。
1.5 通道系統(tǒng)的業(yè)務架構(gòu)
在明白我們的核心需求后,我們來談談怎么設計通道系統(tǒng)。
我們再將兩個核心使命細化,你可以得到下面的圖:
整理成通道系統(tǒng)在整體業(yè)務中的的業(yè)務架構(gòu)圖:
二、通道的生命周期與產(chǎn)品架構(gòu)
2.1 通道的生命周期
在詳細的介紹通道系統(tǒng)如何設計之前,我們首先來介紹下通道的生命周期相關(guān)的知識。
通道生命周期就是一個通道在整個業(yè)務體系內(nèi)從商務對接,到技術(shù)業(yè)務對接,到投產(chǎn)的整個過程。在國內(nèi)通道同質(zhì)化極高的情況下,三方機構(gòu)本身是很少的去對接新的國內(nèi)支付的通道了,但是商戶對接支付通道以及在跨境支付領(lǐng)域,新通道的對接依舊是個常有的場景。
了解一個通道接入的生命周期、知曉每個節(jié)點各部門關(guān)注的點、理解其背后的底層需求,對我們設計和優(yōu)化通道管理系統(tǒng)是非常有幫助的,所以我們也對此做個簡單的介紹。
2.1.1 流程與節(jié)點
超市想找一個新的供應商,他會怎么辦?首先他需要先搞清楚,他為什么需要找這個供應商,他需要供應商給他提供什么貨?是拓新商品還是為老商品做個備份?找到了一個供貨商,在確定合作之前,超市需要供應商告知他一些基本情況:供貨的清單、商品的價格、補貨的時效、賬期等等,同時要驗下貨。超市覺得沒問題,那就簽合同,同時超市內(nèi)部還得和相關(guān)的員工同步這個消息。而且,新的商品沒經(jīng)過市場的考驗,超市一般會先少進點貨,看看市場反應,反響不錯再大量上架,這事終于成了。
從這個例子中,我們可以大致可以將通道的生命周期總結(jié)為以下4個階段:
- 拓新——確認需求,尋找符合條件的通道;
- 對接——商務對接,技術(shù)對接,業(yè)務對接;
- 驗收——測試驗收,生產(chǎn)驗收,試運營;
投產(chǎn)——正式運營,持續(xù)關(guān)注。
然后我們可以根據(jù)具體要做的事務,將其中的幾個關(guān)鍵的節(jié)點列出來:
接下來讓我們看看這些節(jié)點是如何推進,各部門的職責及需要產(chǎn)出的物料分布是什么。了解其職責與產(chǎn)出的需求,我們才能更好的明白,通道系統(tǒng)應該如何去服務他們。
2.1.2 參與方及其負責內(nèi)容
基于不同的公司架構(gòu),每個節(jié)點的參與部門或者人員都會有所不同,而且需要完成的工作也會有所區(qū)別,這里給到一個角色與分工的示例表,僅做參考:
2.1.3 相關(guān)物料
經(jīng)過整理,我們可以得到下面的角色與物料的表:
至此,我們對整個通道的生命周期,已經(jīng)有了一個完成的理解,并對每個部門的述求都有了詳盡的了解。此外,我們在上文有提到過,通道系統(tǒng)是同時需要滿足業(yè)務部門和業(yè)務系統(tǒng)的雙邊信息要求,但是兩者對信息的要求維度其實基本一致。所以通道系統(tǒng)應該輸入的信息和輸出的信息也基本成型了。
2.2 通道系統(tǒng)的產(chǎn)品架構(gòu)
在理解這通道的生命周期后,我們可以根據(jù)階段將通道系統(tǒng)拆分為3個功能模塊:通道接入模塊、通道信息模塊、通道業(yè)務數(shù)據(jù)模塊。
同時,每個模塊都需要有信息的輸入和輸出功能。再結(jié)合之前的信息述求??梢缘玫较旅娴漠a(chǎn)品架構(gòu)圖:
三、通道系統(tǒng)設計
3.1 通道接入管理
一般來說,我們很少會在系統(tǒng)里專門去設計一個模塊去做通道接入生命周期的管理,因為整體投入的性價比實在太低。所以通常我們會借助一些成熟的OA工具當做工單系統(tǒng)來推進節(jié)點、wiki工具做線上文檔管理,來進行這種頻率并不高的商務性流程的管理。
這里整理一些較為具體的工作內(nèi)容,以作參考:
3.2 通道信息管理架構(gòu)
通道系統(tǒng)的本質(zhì)就是提供通道信息的中心,因此這個模塊是通道系統(tǒng)的最為核心的模塊。我們的主要工作都在于如何抽象通道信息并搭建通道系統(tǒng)的信息輸入輸出體系。讓通道系統(tǒng)真正的成為支付體系的基石。
3.2.1 通道的層級
前文我們有提到,通道分類的維度很多,使用符合公司業(yè)務需求的分類是架構(gòu)通道系統(tǒng)的大前提。而往往單一的分類是不足以滿足日常的通道管理需求的,所謂通道的層級就是我們所采用的通道分類維度的先后。
比較常用的一種分類邏輯是首先按業(yè)務線分類,而對于很多公司來說,業(yè)務線大多由目標客戶群體決定,所以我們對通道的第一層級分類也會基于這個基調(diào)而展開。后續(xù)的層級,則會更加自由一點,但核心目的都是為了很好的滿足管理需求。
舉個例子,公司兩條主要業(yè)務線:境內(nèi)業(yè)務、跨境業(yè)務,境內(nèi)業(yè)務線主要服務于零售類商家的日常收款,跨境業(yè)務線主要針對出口貿(mào)易賣家提供服務。那么我們也許可以采用如下通道分類結(jié)構(gòu):
又或者,公司主要是為電商平臺提供支付服務,面對的都是個人付款人,那我們也許可以采用如下的分類結(jié)構(gòu):
一個合理的通道分類,能夠讓我們大大的提升公司的通道管理效率,實現(xiàn)通道系統(tǒng)的價值。分類確定后,通道信息模塊的架構(gòu)基本就確認了
3.2.2 通道的信息層
做好通道分類之后,接下來就是按分類進行通道信息的抽象了。
我們把我們業(yè)務所需要的最小顆粒度的通道信息稱之為:通道能力。
那么如何進行能力的抽象?例如:一個通道的快捷業(yè)務支持10個銀行,如果所有銀行的所有參數(shù)(費用、時效、體驗、清算等等)一致,而且其他通道的快捷業(yè)務特征也如此,那我們可以認為,這個通道有一條快捷的能力,它支持10個銀行,他的能力是XXX。
若10個銀行的特征不一致,則我們需要認為:這個通道有10條10個銀行的快捷能力,他們的能力分別是XXX。
根據(jù)前文,以入金通道為例,我們先把初步把通道信息抽象為下圖:
顯然,這么多信息并不便于管理,而且我們會發(fā)現(xiàn),在實際情況中,往往一個合作伙伴會同時擁有多種服務能力,就會出現(xiàn)一個現(xiàn)象:
一個通道可以擁有很多通道能力。
不同的相似通道之間,也有非常多的信息是相似的。從管理上來說,這些通道信息都可以被統(tǒng)一管理。所以我們一般需要在通道能力的管理,維度上面,新增一個信息層級,例如取名為:通道管理。這樣我們就可以在一條數(shù)據(jù)上維護這些一致的信息了,不需要到N條能力數(shù)據(jù)上去維護,大大的降低了管理成本。
所以我們可以將通道的信息管理分類拆分為如下兩個層級
通道信息變更的時候,會影響其所有的能力,能力數(shù)據(jù)變更時,只會影響本條能力。
3.2.3 通道的信息分類
有了信息層級之后,可以進一步的將信息按需求拆分:財務、合規(guī)、交易結(jié)算等等
3.2.4 通道的數(shù)據(jù)權(quán)限
數(shù)據(jù)準備的差不多了。那么該該考慮誰能看的問題,也就是數(shù)據(jù)權(quán)限的問題了。
權(quán)限,是任何后臺系統(tǒng)設計都必須考慮的要素。而通道信息,作為支付公司的核心信息模塊,權(quán)限設計更是其非常重要的一環(huán)。
常用的權(quán)限有兩類:操作權(quán)限、和數(shù)據(jù)權(quán)限。操作權(quán)限就是操作員是否有某些頁面、某些按鈕的權(quán)限。數(shù)據(jù)權(quán)限就是即便在同一個頁面,不同的人看到數(shù)據(jù)也是不一樣的。
我們設計通道系統(tǒng)時,一定要考慮功能如何去滿足不同操作權(quán)限的操作員的需求,例如我們上文舉例的原型:我們將成本信息和交易信息合并在一個頁面展示,若不設計數(shù)據(jù)權(quán)限,那么我們就無法滿足高級權(quán)限人員(可知道通道成本)和低級權(quán)限人員(不應該知道通道成本)的需求。那這個設計方案就是不合理的。
另外說句題外話,作為產(chǎn)品經(jīng)理,應當對數(shù)據(jù)在數(shù)據(jù)庫的存儲模式有粗淺的了解。數(shù)據(jù)庫中的數(shù)據(jù)表都可以認為是一個個excel表,有行有列。數(shù)據(jù)權(quán)限就是對行數(shù)據(jù)和列數(shù)據(jù)分別做權(quán)限控制。
我們用兩個例子來解釋這兩種數(shù)據(jù)權(quán)限:
- 銷售系:不同的銷售在同一個頁面都只能看到自己的商戶數(shù)據(jù),這就是行數(shù)據(jù)權(quán)限。
- 交易查詢頁:后臺運營可以看到每筆交易走了什么渠道、什么成本,客服只能看到每筆交易的狀態(tài)和錯誤描述,這就是列數(shù)據(jù)權(quán)限。
當然有時候如果開發(fā)資源不充裕,我們也可以取個巧,手工權(quán)限,就是一個頁面復制兩遍,各自展示各自的信息,這樣就不需要去實現(xiàn)數(shù)據(jù)權(quán)限了。
總而言之,無法實現(xiàn)權(quán)限分離的設計,都是存在缺陷的。我們在設計任何功能時,一定要時刻考慮權(quán)限。這個方法不僅限于通道系統(tǒng)設計,任何設計也都是通用的。
3.2.5 通道信息模塊的功能架構(gòu)
按照功能模塊的使命,結(jié)合信息的層級與分類,我們可以基本設計通道信息模塊的功能架構(gòu):
3.3 通道信息模塊設計
現(xiàn)在,我們可以來進行具體的系統(tǒng)功能設計了。
3.3.1 模塊設計邏輯
這里我們會用到兩種設計邏輯:
將不同用處的信息分散到不同的頁面上,進行模塊化分開管理。
比如我們會有通道對賬信息管理、通道成本信息管理、通道交易信息管理、通道響應碼管理等等,這樣的好處在于結(jié)構(gòu)清晰,權(quán)限采用操作權(quán)限設計方案,實現(xiàn)簡單。但因為模塊相互獨立,但是參數(shù)相互間有較強的關(guān)聯(lián),會帶來一定管理方面的困擾。
將關(guān)聯(lián)性較強的信息合并在一個頁面進行維護。
比如通道交易信息和成本信息和合規(guī)信息,都是后續(xù)路由系統(tǒng)的核心信息,那么我們就可以把他們放在一個地方維護,輔助用權(quán)限進行數(shù)據(jù)隔離即可。優(yōu)勢在于維護方便,但是結(jié)構(gòu)上會相對不夠明了,同時對權(quán)限體系的要求也更高,基本需要實現(xiàn)列權(quán)限才能按這種方案設計?;蛘吖颈旧韺?quán)限管理相對簡單,也可以使用該方案。
兩者各有優(yōu)劣,而且通常我們會同時采用這兩種設計邏輯,有機組合才能搭建出一個架構(gòu)合理,可用性又高的通道系統(tǒng)。
接下來我們給到幾個示例頁面,通道信息頁面是和業(yè)務聯(lián)系緊密度非常高的功能,因此不同的業(yè)務場景,不同的階段,所需要的通道系統(tǒng)也是不一樣的。這里給到的只是一個樣例參考。大家主要參考整個設計思路和信息結(jié)構(gòu)的框架。
3.3.2 通道信息頁面
設計的核心邏輯就是前文提到的通道分類結(jié)構(gòu)和信息層級,只有明確了通道分類,才能清晰的定義通道和能力的管理層級。
在這個例子中,我們用到了4個分類:支付載體、業(yè)務形式、支持對象、支持銀行。(當然實際原型中會有類似type切換的交互,截圖中不做展示)。
同時,我們新增了通道編碼的概念,因為大部分公司對通道都是有權(quán)限控制的,所以很多時候系統(tǒng)內(nèi)都會用編碼來代替真實的通道名稱,以作權(quán)限控制。
3.3.3 通道能力信息頁面
通道新增后,可自動生成通道能力(部分信息設置默認值后續(xù)編輯),也可手工批量新增。
通道能力的字段在于之前提到的各個部門或系統(tǒng)需要的信息。不要抽象無用的字段(比如代付通道的支持銀行),也不要少抽象字段。這個尺度的把控就要求設計者對公司的各業(yè)務邏輯都要有一定程度的理解。當然若是真的有所偏差,信息架構(gòu)合理的情況下,迭代也不是一件麻煩的事情。
由于入金、出金、鑒權(quán)通道字段可能有所差異,所以我們需要有不同的頁面來管理各自的能力,當然也可以合并在一個頁面,一切取決于實際情況與設計傾向。法無定法,一切為我們的核心使命服務,保證自己在正確的方向上,即便設計不夠完善,也不會有太大的偏差。
此外通道能力往往會遠多于通道,所以我們設計了批量增改的入口,當然如果業(yè)務需要設計復核權(quán)限,也可以添加。
3.3.4 通道響應碼管理頁面
通道響應碼管理,參考頁面:
頁面一般由IT和運營同事共同使用,用以保證映射的準確和友好。有新增的響應碼時,應當有默認映射的內(nèi)容,同事可以自動新增一條記錄,避免異常。
3.3.5 通道參數(shù)管理頁面
通道參數(shù)管理,參考頁面:
參數(shù)管理頁面并非必須頁面,一般由IT相關(guān)同事使用,尤其需注意權(quán)限。
3.3.6 通道黑名單管理頁面
通道黑名單是針對某些被通道拉黑的主體,但可能尚未被我司拉黑,因此將他置于通道黑名單中進行特定的交易阻斷。黑名單一般適用于整個通道而不是僅限于某個業(yè)務類型,一般需要手動維護。黑名單主體將無法被路由到對應通道,主體類型會有:證件號、名稱、卡號等。
通道黑名單管理,參考頁面:
3.3.7 通道備案管理頁面
部分通道有預先備案的業(yè)務邏輯,未備案主體無法進行交易。備案過程可能有api或人工,api模式也行可以設定自動備案邏輯。但是無論那種方式,都需要有頁面進行備案信息管理。
通道備案管理,參考頁面:
3.3.8 商戶通道信息頁面
經(jīng)過上面的功能,我們已經(jīng)基本實現(xiàn)了通道信息的輸入與輸出,基本滿足了對中后臺員工的管理訴求、系統(tǒng)功能模塊的信息訴求。但是還欠缺一個最重要的功能點,即滿足對客的通道信息輸出。參考京東的收銀臺頁面,對客展示的限額應當是所有通道能力的匯總有效限額,再有銷售同事也需要對公司的通道能力有所了解,這個能力也應該是匯總的通道能力。
所以我們還需要通道系統(tǒng)有產(chǎn)出匯總數(shù)據(jù)的能力。
通常來說,我們在通道充足的情況下,會通過給不同級別的商戶配置不同的一堆通道能力來說滿足商戶分級的業(yè)務述求。一般我們稱之為通道組,具體的配置邏輯我們會在介紹路由系統(tǒng)時詳細說明。所以這里面其實有個小小的流程:
給銷售、客服同事提供的商戶通道信息參考頁面:
整體功能會相對簡單,主要依賴研發(fā)同事的實現(xiàn)和通道組的配置。
至此,整個通道核心使命已基本完成。
3.4 通道業(yè)務數(shù)
任何系統(tǒng)和業(yè)務的成長,僅僅滿足于當下是不夠的,所以一定周期的數(shù)據(jù)分析工作是非常有必要的。如果通道系統(tǒng)能產(chǎn)出分析數(shù)據(jù)來補上最后一塊拼圖,無疑是一個非常好的收尾。
在這里我們主要會用到兩類數(shù)據(jù):統(tǒng)計類數(shù)據(jù)、分析類數(shù)據(jù)。我通常也會稱之為結(jié)果性數(shù)據(jù)和過程性數(shù)據(jù)。
結(jié)果性數(shù)據(jù):某個通道在某個周期內(nèi)的交易量、成本、成功率、業(yè)務數(shù)據(jù)分布等等。
過程性數(shù)據(jù):通道業(yè)務數(shù)據(jù)的變化,比如一定周期內(nèi)的環(huán)比、同比數(shù)據(jù)。
一般我們可以選擇用數(shù)據(jù)報表的形式來展示,大家可以根據(jù)各個業(yè)務部門的關(guān)注重心,為他們定制其需要的業(yè)務分析數(shù)據(jù),從而反哺通道系統(tǒng),最終持續(xù)強化我們的通道管理能力和通道結(jié)構(gòu)。
最后的話
一定要時刻牢記通道系統(tǒng)的兩個核心使命:為業(yè)務部門提供良好的通道信息管理工具,讓系統(tǒng)盡可能詳細的了解每個通道的特征。
深入的了解公司通道生命周期:每個節(jié)點會有什么部門參與,他們各自需要做什么。
對通道合理的分類,設計良好的管理架構(gòu),抽象信息字段,是搭建通道系統(tǒng)的重中之重。
隨時考慮權(quán)限的設計,是檢驗設計主干是否合理的重要方法。
大數(shù)據(jù)量和數(shù)據(jù)層級復雜的背景下,如何提高功能的可視化程度、降低操作的難度,需要好好的做些思考。
最后,通道本身就同時具備死板與靈活的特點的,通道系統(tǒng)沒有什么固定的設計方案。我所使用的例子主要還是用以展示設計思路,希望大家活學活用,適合自己的才是最好的。
專欄作家
陳天宇宙,微信公眾號:陳天宇宙,人人都是產(chǎn)品經(jīng)理專欄作家。多平臺支付領(lǐng)域?qū)谧髡?,十年資深產(chǎn)品;專注為10萬支付產(chǎn)品經(jīng)理和支付機構(gòu)以及企業(yè)提供深度支付內(nèi)容和服務!
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于 CC0 協(xié)議。
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
“所以毫無疑問招行是本次的收款通道、工行是本次的結(jié)算通道?!笔湛钔ǖ朗侵Ц斗降母犊钽y行么?希望作者能夠解惑
案例中指的是支付寶接了招商的快捷支付通道(收款通道),用戶在支付寶內(nèi)綁定了招行信用卡,所以說本案例中的收款通道是招行提供,這個跟是否是付款行沒有關(guān)系
“所以毫無疑問招行是本次的收款通道、工行是本次的結(jié)算通道。”收款通道是支付方的付款銀行么?