支付路由的動态配置實現
背景
近期,在接觸到決策引擎後,突然回想到以前在上家單位,做支付路由系統時所經曆過的點點滴滴,當初對于支付路由毫無概念,網上資料十分(fēn)匮乏,完全被業主方牽着鼻子走,也是不斷地挖坑填坑過程,甚是苦惱。也在想決策引擎這一工(gōng)具(jù)的出現,能(néng)否更加便捷地解決降本增效問題,即将之前用(yòng)groovy腳本和硬編碼方式給替換掉,以支持運營团隊對支付規則靈活調整。借此機會,将相關經驗和過程記錄下來,分(fēn)享給有(yǒu)需要的讀者,也歡迎專業人士的批評和指正。
1.支付相關概念
1.1 基本概念
在支付系統中(zhōng),支付公(gōng)司通常會給商(shāng)戶提供多(duō)種支付方式,而每一種支付方式,對于支付公(gōng)司而言,都會接入對應的支付渠道。
支付方式
即我們常用(yòng)的個人網銀支付、企業網銀支付、微信支付、支付寶支付、快捷支付、無卡支付等
支付渠道
支付渠道,體(tǐ)現在“道”上,道是人和交通工(gōng)具(jù)走的路,先修建道路才能(néng)運輸載體(tǐ)。支付渠道就是錢走的路線(xiàn),即資金轉移的通道,也被稱為(wèi)資金渠道、支付通道,與現實中(zhōng)“運輸交通” 相似,先建設渠道才能(néng)支付。
支付路由
試想一下,你現在的位置是天安(ān)門地鐵站,想去首都機場,具(jù)體(tǐ)怎麽去呢(ne)?路線(xiàn)有(yǒu)多(duō)種選擇,近的,遠(yuǎn)的,堵的,暢通的。怎麽選擇?你需要具(jù)體(tǐ)的路線(xiàn)和導航。支付路由就是就是根據用(yòng)戶所選擇的支付方式(如支付寶)之後,支付機構通過提前配置好一系列的“規則”,最後在衆多(duō)支持的支付渠道後面,選出當前最優的一條支付渠道。類似交通導航,公(gōng)路、航線(xiàn)有(yǒu)編号,渠道也會進行編号,支付路由就是那個導航,幫你選擇最合适你的支付渠道。
目标機構
用(yòng)戶實際使用(yòng)的錢包或者銀行卡對應的機構,是實體(tǐ)的屬性,比如剛才買菜的時候選擇的支付寶,或者你已綁定的銀行卡對應的銀行。
資金機構
平台合作(zuò)的實際進行資金清算的機構,資金機構有(yǒu)2個主要特點,1是實體(tǐ)的屬性,2實體(tǐ)有(yǒu)資金清算的權限,合作(zuò)時有(yǒu)資金機構直接清算給平台,一般是持牌的的機構,可(kě)以是三方支付機構、商(shāng)業銀行、支付網關等。一個資金機構可(kě)以支持多(duō)個目标機構,也可(kě)以隻支持1個目标機構,如在国内支付場景下,要接入微信支付可(kě)以選擇直接接入微信的方式也就是通常所說的話直連,也可(kě)以選擇通過其他(tā)三方支付公(gōng)司接入微信的方式也就是通常所說的簡連。
資金渠道
合作(zuò)資金機構的對應通道稱之為(wèi)資金渠道,資金機構不同産(chǎn)品屬性、開通方式、賬戶和币種的不同,按照合作(zuò)的産(chǎn)品對資金機構進行細分(fēn),劃分(fēn)為(wèi)資金渠道,通常來說資金機構和資金渠道是1對N的關系。資金渠道可(kě)分(fēn)為(wèi)以下幾類:
(1)按照資金方向劃分(fēn):資金機構通常都支持入金、出金處理(lǐ),有(yǒu)時候也叫收款、付款,資金渠道按照屬性來說,通常劃分(fēn)為(wèi)入金通道,及出金通道。一般像是支付寶、微信聚合支付(包括APP、Native,公(gōng)衆号,小(xiǎo)程序等)、快捷支付、網銀支付都是入金通道,另外像是代付、轉賬到支付寶、微信零錢等、轉賬到銀行卡都是出金渠道。
(2)按照貨币屬性劃分(fēn):貨币屬性,渠道可(kě)以支持人民(mín)币、歐元、美元、外币等。
(3)按照适用(yòng)客戶類型劃分(fēn):按照客戶類型,如果客戶是C端類型的為(wèi)對私類型,如果是企業類型的為(wèi)對公(gōng)類型
(4)按照支持的支付方式劃分(fēn):有(yǒu)錢包類型的,網銀支付類型的,快捷支付類型的,国際信用(yòng)卡等。
終端場景
用(yòng)戶支付是APP支付,掃碼支付,web端支付,微信小(xiǎo)程序,支付寶小(xiǎo)程序。
1.2 多(duō)視角理(lǐ)解支付渠道
1.2.1 第三方支付機構角度看‘支付渠道’
支付機構的一個比較重要的角色是幫助入網商(shāng)戶完成資金的轉移,将用(yòng)戶銀行卡中(zhōng)的資金轉移至入網商(shāng)戶的銀行賬戶中(zhōng),為(wèi)了完成該資金轉移過程,就需要對接銀行,銀聯等機構的資金渠道。
從上图我們可(kě)以看出,第三方支付公(gōng)司具(jù)有(yǒu):網聯、銀聯、直連銀行、或者其他(tā)第三方支付等渠道,通過支付公(gōng)司的路由系統,選擇不同的渠道來完成資金轉移。第三方支付公(gōng)司之間除了比拼渠道,支付路由也及其重要。
對于支付機構來說,銀行類和銀聯、網聯都是其支付渠道的選擇。
銀行
每家銀行提供的業務(wù)及産(chǎn)品不同,例如B2C、B2B、大額支付、銀企直連、代收代付、快捷支付。一般情況下,對接一個銀行的話預期需要2-3周的工(gōng)作(zuò)量,不同銀行對接入環境有(yǒu)不同要求,這也是成本,比如大部分(fēn)銀行需要專線(xiàn)接入,費用(yòng)和帶寬有(yǒu)關,一年也得幾萬費用(yòng)。
銀聯
銀行與銀行之間交易,分(fēn)兩種情況:同行和跨行。在同行交易的情況下,交易流程僅涉及到賬戶金額的變動;而在跨行交易的情況下,不僅涉及到賬戶金額的變動,還存在兩個銀行之間資金流轉的問題。相比之下,這裏面的交易環節,會更加複雜,同時銀行的運營成本也會随之增加。
那麽此時,銀聯就應運而生了。
銀聯的成立,就是為(wèi)了解決不同銀行之間繁雜的交易問題的。它是銀行與銀行之間的清算機構,當用(yòng)戶發起跨行轉賬時,銀聯先進行記賬,然後在結算日,再進行統一清算。銀行之間交易環節的減少,就會節省不少運營成本。
銀聯作(zuò)為(wèi)第三方的支付渠道,為(wèi)平台對接銀行起到非常大的幫助作(zuò)用(yòng)。平台對接銀聯的支付渠道後(快捷支付),用(yòng)戶在平台消費時需要綁銀行卡,首次需要上傳銀行卡号、手機号、身份證号碼,銀行卡綁定後,後續的操作(zuò)步驟會相對便捷一些,隻需在每次支付時輸入密碼即可(kě)。後續的支付扣款流程跟其他(tā)第三方支付一樣需要内嵌SDK,而是都在服務(wù)端完成校驗。
網聯
網聯,全稱為(wèi)“非銀行支付機構網絡支付清算平台”,是一個由中(zhōng)国人民(mín)銀行領導成立的支付清算機構。類似銀聯的線(xiàn)上支付通道,通過網聯清算平台實現了非銀行支付機構與各家銀行之間的支付交易清算和互聯互通。第三方移動支付機構不再直接連接銀行,而是通過網聯連接,資金通過網聯進行結算,線(xiàn)上支付統一清算平台,交易有(yǒu)問題馬上被過濾闆攔下來。
在以往,不同銀行的支付系統相對獨立,第三方支付機構要跨行清算需要在每一家銀行開啓備付金賬戶。網聯為(wèi)不同支付機構提供了一個統一的清算平台,支付機構隻需在網聯開設唯一的備付金賬戶,将交易數據傳遞給網聯,這樣大大縮短了跨行清算的周期,使得跨行支付變得更加便捷和高效。
網聯與銀聯的區(qū)别
①銀聯是從紙币發展到銀行卡階段,為(wèi)滿足各家銀行互聯互通交易而産(chǎn)生的。比如工(gōng)商(shāng)銀行部署的刷卡POS機,隻能(néng)刷工(gōng)商(shāng)銀行的卡,而不能(néng)刷建行的卡,所以出現了銀聯,銀聯是連接各大銀行的橋梁。
②網聯是互聯網支付時代,為(wèi)各家第三方支付公(gōng)司。比如微信、支付寶、易錢包、京東白條、錢寶科(kē)技(jì )等等這些第三方支付公(gōng)司互聯互通交易,網聯取代之前第三方支付機構直聯銀行的模式,網聯僅作(zuò)為(wèi)清算平台,一端連接持牌支付機構,另一端對接銀行系統。
③網聯支付可(kě)以理(lǐ)解為(wèi)是線(xiàn)上支付,銀聯支付目前主要市場在線(xiàn)下銀行卡刷卡,網聯定位于線(xiàn)上整合第三方支付公(gōng)司的網絡支付、移動支付。
1.2.2 支付平台類公(gōng)司角度看‘支付渠道’
支付渠道,顧名(míng)思義就是平台上支持用(yòng)戶支付的通道,這些支付渠道幫助平台用(yòng)戶完成交易金額的支付,并且支持平台與銀行之間進行資金流轉、對賬和清分(fēn),比如微信、支付寶、通聯、易寶等。一般交易平台都會對接多(duō)家支付渠道公(gōng)司。
上图中(zhōng),電(diàn)子商(shāng)務(wù)網站通過接入第三方支付公(gōng)司,或者有(yǒu)些牛的公(gōng)司能(néng)直接接入銀行或者銀聯系統,具(jù)有(yǒu)了支付能(néng)力。把他(tā)們當成自己的支付渠道,由支付路由系統來計算最合适的渠道進行處理(lǐ)。
1.2.3 銀行類平台角度看‘支付渠道’
銀行角度下的支付渠道
對于銀行來說,其支付渠道主要是人行的各子系統,不同的業務(wù),不同的時間段,選擇人行的子系統是不同的。銀行也會有(yǒu)自己的路由系統。
1.3 用(yòng)支付示例來理(lǐ)解支付概念
1.3.1 京東app購(gòu)物(wù)
在了解了支付和支付系統的概念後,也對現有(yǒu)的常用(yòng)的支付方式有(yǒu)一定的認識,我們來研究下支付背後的邏輯,下面以在京東購(gòu)買商(shāng)品時,以微信支付為(wèi)例來解說支付背後的邏輯。
如上图所示,在我的京東app上綁定了招商(shāng)銀行信用(yòng)卡、工(gōng)商(shāng)銀行儲蓄卡,那麽在收銀台默認支持的付款渠道有(yǒu)5個(京東支付、招商(shāng)銀行信用(yòng)卡、工(gōng)商(shāng)銀行儲蓄卡、微信支付、雲閃付),也可(kě)稱之為(wèi)【展示層路由】,而在選擇了“微信支付”作(zuò)為(wèi)目标機構後,又(yòu)選擇了“招商(shāng)銀行信用(yòng)卡”作(zuò)為(wèi)資金機構和資金渠道,好像這裏并沒有(yǒu)體(tǐ)現出【交易路由】的規則決策過程,全是人工(gōng)指定的渠道支付。假如我們新(xīn)增一種叫做“自動路由/通用(yòng)路由/渠道優選”這種方式來自動計算出一種最适合的付款方式,再為(wèi)每種渠道添加上各種限制因素(例如:手續費率、銀行交易限額、支付時效性、支付成功率),那此時就需要規則引擎來自動進行規則匹配,為(wèi)商(shāng)戶做出最優支付方案。
1.3.2 ETC微信小(xiǎo)程序充值
ETC場景的收銀台比較簡單,主要承擔着收單和充值兩個功能(néng)。充值主要是充值ETC錢包,用(yòng)于後續通行路費的扣款。而消費收單主要是通行路費扣款以及申辦(bàn)和其他(tā)增值服務(wù)的收費,如下图所示選擇不同的充值方式,可(kě)能(néng)會因手續費率不同導緻最終支付的金額會有(yǒu)所不同。
2.支付路由的價值
作(zuò)為(wèi)一家支付機構,其主要是給商(shāng)戶提供穩定、便捷的支付通道服務(wù)。因此每一家支付機構往往會接入多(duō)家支付渠道,從而避免某個支付渠道出現故障,降低用(yòng)戶支付體(tǐ)驗。
尤其是“斷直連”之前,支付公(gōng)司背後的支付渠道能(néng)力參差不齊,每一家支付渠道支持的服務(wù)能(néng)力、支持的支付方式,穩定性以及價格成本均會不一樣,具(jù)體(tǐ)表現如下:
- 穩定高的支付渠道,渠道價格會很(hěn)高,同時支持的支付方式也不一定全
- 價格便宜的支付渠道,可(kě)能(néng)系統穩定性不足;
- 價格适中(zhōng)的支付渠道,有(yǒu)些支持的銀行少,甚至支持的各個銀行互不相同;
- 穩定性适中(zhōng),服務(wù)态度較好的支付渠道,也有(yǒu)很(hěn)多(duō)支付方式不支持;
基于上述問題,支付機構就需要全面考慮好去設計一套支付路由系統了,而支付路由的價值也将體(tǐ)現在以下幾點:
- 保證渠道多(duō)樣性;提高綜合服務(wù)能(néng)力;提供多(duō)銀行渠道;
- 保證用(yòng)戶體(tǐ)驗,在支付渠道出問題時,将用(yòng)戶損傷降低最小(xiǎo),保證對外的用(yòng)戶體(tǐ)驗一緻性;
- 降低渠道成本,間接提高收入;
- 方便運營操作(zuò),降低人工(gōng)操作(zuò)成本,提升運營工(gōng)作(zuò)效率
3.支付路由設計與實現
說明:由于篇幅原因,并受限于個人的專業知識,不會對支付業務(wù)全面展開,隻局限于支付路由相關的流程進行探讨。
3.1 要解決的問題
要解決上述一系列問題,就需要系統性地考慮支付系統路由設計了,首先得進行渠道篩選,得到滿足要求的支付渠道也可(kě)稱之為(wèi)“收銀台”;其次需要檢查商(shāng)戶白名(míng)單或指定的支付規則,若能(néng)成功匹配到一種支付渠道,那就将其作(zuò)為(wèi)最終的支付方式,若未能(néng)命中(zhōng),則進入第三步的渠道優選;在渠道優選中(zhōng),通常有(yǒu)“費用(yòng)最低策略”和“擁堵策略”這2種。
3.2 路由設計
路由是支付系統的核心功能(néng)模塊。在整個支付系統的信息和資金流轉過程中(zhōng),清算和結算兩個階段基本上是用(yòng)不到路由的,路由規則的設計主要集中(zhōng)在商(shāng)戶入網和交易這兩個階段。在商(shāng)戶入網階段通常會用(yòng)到鑒權路由,交易階段通常會用(yòng)到商(shāng)戶路由和支付通道路由。
支付通道路由,主要是在交易的過程中(zhōng)由用(yòng)戶選擇或者支付系統按照低費率成本、高成功率、合規性的原則選擇一條合适的交易通道。當支付系統在接入渠道不多(duō)或者商(shāng)戶單一且需求簡單時,通常采用(yòng)人工(gōng)路由,由運營人員根據客戶需求配置指定的支付渠道、支付産(chǎn)品、配置指定的路由商(shāng)戶。當接入通道數量多(duō),商(shāng)戶數量大且個性化需求較多(duō)時,配置規則的工(gōng)作(zuò)量将很(hěn)大,可(kě)以采用(yòng)自動路由的方式解決,由運營人員提前在系統中(zhōng)固定好路由規則,交易時由系統自動選擇商(shāng)戶和通道。大多(duō)數成熟的支付系統都采用(yòng)人工(gōng)+自動路由的模式來處理(lǐ)路由模塊,具(jù)體(tǐ)哪些用(yòng)人工(gōng)、哪些用(yòng)自動,則根據業務(wù)的路由場景來判斷。
3.2.1 渠道篩選
渠道篩選的主要作(zuò)用(yòng)是篩選出能(néng)夠支持本次交易的資金渠道,再來回顧下上面的京東app支付例子,在付款時我選擇了微信付款,别問我為(wèi)啥不用(yòng)支付寶呢(ne)?
從上图我們可(kě)以看出,京東app是支持200多(duō)家銀行和三方支付公(gōng)司微信支付、雲閃付、Apple Pay。那麽,我們可(kě)以做個假設,若京東app是接入了以下渠道,咱們以支付單筆(bǐ)3894元為(wèi)例,資金渠道信息如下:
渠道名(míng)稱 | 目标機構 | 交易币種 | 終端場景 | 單筆(bǐ)最小(xiǎo)限額(包括) | 單筆(bǐ)最大限額(包括) | 費率 | 狀态 | 渠道維護時間 |
---|---|---|---|---|---|---|---|---|
支付公(gōng)司A | 微信 | CNY | APP | 0 | 1000 | 3% | ON | - |
銀行B | 微信 | CNY | 小(xiǎo)程序 | 0 | 10000 | 1% | ON | - |
微信C | 微信 | CNY | APP | 0 | 10000 | 2% | ON | - |
微信C | 微信 | CNY | 小(xiǎo)程序 | 0 | 10000 | 2% | ON | - |
支付寶D | 支付寶 | CNY | web | 0 | 20000 | 1% | ON | - |
銀行E | 銀行E儲蓄卡 | CNY | APP | 0 | 1000 | 0.5% | ON | - |
銀行F | 銀行F信用(yòng)卡 | CNY | APP | 0 | 5000 | 0.1% | ON | - |
首先把不支持app的終端場景過濾掉,然後把超限的渠道給過濾掉,再把關閉的渠道以及在維護中(zhōng)的渠道給去掉,初步篩選出滿足條件的渠道如下所示:
渠道名(míng)稱 | 目标機構 | 終端場景 | 限額 | 費用(yòng)(元) |
---|---|---|---|---|
微信C | 微信 | APP | 10000 | 77.88 |
銀行F | 銀行F信用(yòng)卡 | APP | 5000 | 3.894 |
3.2.2 白名(míng)單和指定規則
在實際的運營過程中(zhōng),我們對某一些商(shāng)戶單獨配置特殊的路由規則,如果符合條件的支付渠道有(yǒu)A,C,D,正常情況下運營會希望優先選擇渠道A ,因為(wèi)該渠道比較便宜;但是針對于商(shāng)戶c,我們希望是以用(yòng)戶體(tǐ)驗為(wèi)主,所以盡管支付渠道C更貴,但還是希望優先選擇渠道C而不是A。那麽,白名(míng)單的主要作(zuò)用(yòng)是看某個業務(wù)場景是否指定了資金渠道,優先匹配指定的高優先級的渠道。
規則編号 | 規則名(míng)稱 | 限定商(shāng)戶範围 | 策略優選 | 優先級 | 狀态 |
---|---|---|---|---|---|
RULE1 | 默認規則 | 不限 | 費用(yòng)最低策略 | 100 | ON |
RULE2 | 京東指定規則 | 京東 | 微信C | 2 | ON |
RULE3 | 京東指定規則 | 京東 | 京東支付G | 1 | ON |
RULE4 | 淘寶指定規則 | 淘寶 | 支付寶D | 100 | ON |
RULE5 | 默認規則 | 不限 | 擁堵策略 | 90 | ON |
注意:優先級數字越大,表示權重越大,即最先匹配
3.2.3 渠道優選
假設,渠道優選策略目前支持2種方式:“費用(yòng)最低策略”和“擁堵策略”。
費用(yòng)最低策略即支付産(chǎn)生的手續費最低,有(yǒu)按筆(bǐ)數收手續費,按金額階梯及筆(bǐ)數範围優惠階梯匹配渠道路由,達到一定阈值,筆(bǐ)數的阈值或者金額階梯的阈值走另外一個渠道計算下來的成本會更節省。也有(yǒu)些渠道可(kě)能(néng)存在按照日或者月限制流量,如每日能(néng)走1000萬交易,超過1000萬渠道就不在支持,這時候就需要切換到其他(tā)渠道。
而擁堵策略是由于支付渠道或開戶銀行網絡不穩定、系統出現問題等原因,導緻部分(fēn)交易處于處理(lǐ)中(zhōng)或者交易失敗,交易吞吐量低下。因此路由需要具(jù)備每個支付渠道的監控能(néng)力,例如連續失敗筆(bǐ)數、五分(fēn)鍾内失敗交易占比、交易吞吐量等屬性。
再或者,當對接的支付渠道有(yǒu)多(duō)個的時候,可(kě)能(néng)由于商(shāng)務(wù)層面和系統層面,需要執行交易量分(fēn)流。可(kě)設置每個渠道流量百分(fēn)比,備用(yòng)渠道交易總額等。
3.3 規則引擎實現自動決策
3.3.1 創建庫文(wén)件
支付訂單信息
渠道信息
渠道中(zhōng)間變量
白名(míng)單信息
參數庫
3.3.2 創建規則文(wén)件
支付渠道決策表
說明:根據輸入的支付信息,篩選出符合條件的支付渠道信息,并添加到集合中(zhōng)。
白名(míng)單規則表
說明:先自動匹配商(shāng)戶指定的支付渠道,若沒有(yǒu)匹配到,則會第二次匹配并命中(zhōng)默認規則。
決策集
說明:串起整個決策過程,邏輯運算等,得到最終的實際支付渠道信息。也就是按照3.1章節中(zhōng)的①渠道篩選 ---> ②白名(míng)單/指定規則 ---> ③渠道優選 ---> ④試算完成 這4步。
3.3.3 測試驗證
測試1
輸入的支付訂單信息中(zhōng)商(shāng)戶名(míng)稱是“京東”,會命中(zhōng)白名(míng)單走指定的支付渠道“微信C”,且微信C也在第一步的渠道篩選結果中(zhōng)。
(1)輸入/輸出數據
(2)規則執行日志(zhì)
測試2
輸入的支付訂單信息中(zhōng)商(shāng)戶名(míng)稱是“京東1”,未能(néng)命中(zhōng)白名(míng)單商(shāng)戶指定的支付渠道,那就會進入渠道優選環節,從而二次命中(zhōng)“費用(yòng)最低策略”,然後再計算出前面篩選出來的渠道中(zhōng)費用(yòng)最低的渠道,作(zuò)為(wèi)最終實際支付渠道。
(1)輸入/輸出數據
(2)規則執行日志(zhì)