林冠峰++曾陽



摘 要
隨著銀行面向商戶的支付結算系統不斷發展,商戶管理作為支付結算系統的基礎應用模塊也需改變以適應各類新型商業模式的使用。在國內銀行大力發展“雙線”支付模式——線下支付和線上(互聯網)支付的背景下,其商戶管理系統建設普遍出現數據模型不統一、商戶信息不集中、商戶接入管理分散等問題。文中提出了銀行統一商戶模型的設計,通過抽象化線上線下商戶數據模型,設計了通用的商戶基礎信息、接入模式及簽約管理等模塊。該設計能有效地支撐銀行支付結算的商戶信息管理集中,顯著提高銀行運營管理效率,簡化銀行支付應用系統架構。最后提供了系統開發示例,并做了總結。
【關鍵詞】商戶管理系統 支付結算 商戶數據模型 商戶接入安全工具
1 概述
隨著互聯網支付結算新興模式的不斷發展,傳統的銀行支付結算服務也逐漸從線下往線上轉變。如今移動互聯網時代,由第三方支付公司所代表的互聯網支付第一陣營,再次向傳統金融機構發起沖擊,各類互聯網金融產品推陳出新,而支付結算作為銀行重要的職能之一,也開始在移動互聯領域基于支付結算服務開展了各類相關產品創新。
在支付結算工具發展的歷程當中,從傳統的線下POS收單系統到近年來流行的移動支付收單系統,銀行為適應相應的新興支付商業模式,開始了多樣化的支付應用系統建設。作為這些支付應用系統的基礎支撐,商戶管理系統面向合作商戶、合作平臺、銀行運營管理人員提供有關銀行收單業務的一套集“商戶申請及準入、產品簽約、結算協議”為一體的綜合信息管理服務。
在國內銀行的支付應用系統建設實踐當中,由于不同商業模式的支付應用場景不盡相同,且線下和線上業務在時間上分屬兩個不同的發展時代,銀行大多采用不同的系統以此更專業化地滿足各類支付模式。而在商戶管理方面,由于線下商戶和線上商戶所具備的屬性也不盡相同,商戶管理系統大多依托于相應的支付應用系統作為基礎數據支持模塊,因此銀行系統架構內多套獨立且各具特色的商戶管理系統的并存是業內普遍的做法。但隨著支付模式不斷發展,支付應用系統不斷更新優化,分化式商戶管理系統建設方式將會對業務運營、系統運維等方面帶來一些問題:商戶數據冗余且不集中、運營操作重復且不統一、合作商戶接入繁瑣困難等。
而本文提出的銀行統一商戶管理模型,旨在解決分化式商戶系統建設給銀行支付結算業務帶來的現實問題,達到“數據集中、操作統一、接入通用”的商戶管理目標。
2 商戶數據通用模型
以民生銀行內部支付結算系統架構為例,面向商戶的收單業務系統分為線上與線下兩類。其中,線下收單類的系統有POS機收單、自助設備收單、二維碼收單等系統,線上收單類的系統有網銀B2C支付、網銀B2B支付、快捷支付、手機銀行支付、網關支付等系統。而不同系統所維護的商戶信息是獨立存在的,不同支付應用系統使用商戶管理存在于相應配套的商戶管理系統中,基本上一個支付系統會對應一個商戶管理系統。多個商戶管理系統的存在,使得商戶數據大量冗余、運營人員操作維護不便利、商戶維護接入信息不一致等問題突顯。如圖1所示。
舉例說明,某商場成為民生銀行的合作商戶,接入民生銀行線下的POS收單業務和互聯網的網關支付業務。該商城的同樣一份商戶基礎信息需在POS收單商戶管理系統錄入,同時也需要在網關支付商戶管理系統錄入,運營人員錄入操作需執行兩次,且操作步驟不同,增加運營操作失誤率,而且同一份數據存在于兩個系統中,出現了冗余。面向該商戶提供的接入信息由于分屬不同的商戶管理系統,產生的接入信息也是不一致的,POS收單業務商戶號、商戶標識、協議號等信息與網關支付業務相應的信息是不同的,對商戶端的接入銀行合作信息維護帶來了諸多不便。
因此,為有效改善上述的問題,設計通用的統一的商戶數據模型是非常必要的。
2.1 商戶數據抽象化
結合現有銀行支付結算系統不同的支付產品業務,綜合考慮線上和線下支付業務商戶的共同屬性及個性化屬性,可將商戶管理數據劃分為以下幾類:
2.1.1 商戶基礎信息,是關于商戶的相對靜態的各屬性集合
在典型的銀行線上和線下支付結算業務,商戶基礎信息具有普遍共性,屬性一般包括但不限于:商戶號、商戶名稱、商戶簡稱、商戶地址、所屬行業、組織機構代碼、營業執照、稅務登記證、ICP備案、商戶代表人、聯系方式、歸屬營業機構、拓展人員等。以上屬性作為銀行內不同的支付業務所需商戶信息具有共性,因此可抽象化。
2.1.2 商戶接入安全工具
一般地,銀行線下支付業務,大多依靠POS機、自助收款設備等終端機具或收款二維碼展示,多為實體的收款接入工具;而銀行線上支付業務,大多依靠商戶電子商務系統與銀行互聯網支付網關之間直連的方式,為虛擬的接入工具。因此,可將該兩類典型的商戶接入方式抽象為商戶接入工具,此工具分為實體工具和虛擬工具兩類,不同類別的工具所具備的屬性可不相同。
2.1.3 商戶簽約數據
銀行面向商戶提供支付結算產品或服務,將涉及銀行與商戶的合作協議,協議中包含商戶所享受的服務的相關描述、服務時間窗口、合作接入方式、商戶資金結算規則、銀行中間業務收費等雙方約定。一般可分為商戶合約基本信息、商戶資金結算規則、商戶手續費扣收規則、產品交易規則等抽象類。
2.1.4 商戶金融賬戶數據
合作商戶與銀行簽約支付業務,資金流轉需依靠最傳統的金融介質——賬戶來完成。不同的支付業務,可能需登記商戶的收入賬戶、手續費賬戶、備付金、專戶等不同用途的賬戶信息。
抽象化后的各類商戶管理數據關系如圖2所示。
2.2 商戶的關系網絡
銀行的商戶管理方面,除了針對商戶數據的管理,仍需考慮商戶與商戶之間的關系。關系是一種“聯系”,表明著關聯的事物之間存在著一致性、共同性,從而在此基礎上形成不同事務、特性的統一形式。銀行內部龐大的合作商戶體系,存在著錯綜復雜的關系網絡。一般地,關系區分了多個維度,包括商戶上下級關系、平臺外部拓展商戶的間連關系、供應鏈上下游關系等。
2.2.1 商戶上下級關系
大中型商戶一般具有母子公司、總店連鎖分店等顯著的上下級關系,是一種雙向關聯的強關系。該類關系在支付結算業務中一般涉及到資金歸集、下撥、以上級名義收付款、以下級名義收付款等方式的資金流動。
2.2.2 平臺外部拓展商戶的間連關系
該類合作商戶一般屬于平臺,該平臺自己具備拓展商戶的能力,構建了自身的中心化的商戶網絡結構。比如客如云是一家餐飲行業的智能點餐平臺,客如云自身拓展了眾多餐飲企業、門店及外賣店等商家,為商家提供餐飲軟件服務,包括了預定、排隊、外賣、點餐、收銀等功能,其中涉及客戶支付的功能對接了銀行的支付結算系統。各商家通過合作平臺間接地享受銀行的支付結算服務,商戶與銀行是一種單向連接的弱關系。
2.2.3 供應鏈上下游關系
該類關系一般多出現于銀行合作的中小商戶,在支付結算業務中一般涉及到擔保金、票據、交割憑證等資金與信息流。商戶之間存在著實際的生意往來關系。
2.3 商戶管控
銀行的支付結算業務與第三方支付類似,雖然銀行在資產管理經驗、資金及撥備保障、流動性管理經驗方面有明顯的比較優勢,但在實際的業務操作中,收單業務風險仍然是業務運營過程的主要阻礙之一。風險商戶的管控是商戶管理的另一個重要課題,基于本文提出的通用商戶數據模型,可從商戶的關系網絡、商戶合作接入等方面進行控制。一般地,管控操作分為技術管控與業務管控兩類。技術管控方式,針對商戶合作接入的各類交易進行控制;業務管控方式,通過商戶簽約凍結、商戶之間的關系凍結等方式進行控制。
3 商戶管理系統設計
基于上述的商戶數據通用模型,可構建銀行統一商戶管理系統,優化銀行支付結算應用架構,減少商戶相關系統冗余。設計大體思路:針對銀行各類面向商戶的支付結算應用系統搭建統一的商戶管理系統,該系統負責統一的商戶數據錄入、業務準入及技術準入。
3.1 系統架構
優化后的商戶管理系統,打破原有依附支付系統的商戶管理的分散設計,建立統一平臺,將商戶信息、關系數據集中管理,簡化銀行支付系統架構。如圖3所示。
統一商戶管理系統,與銀行內各支付結算系統、渠道系統的集成關系,闡述如下:
與商戶門戶的集成關系:商戶通過銀行的在線門戶(如銀行網銀、銀行官網、支付門戶等)提交業務申請材料,門戶系統將申請信息通過實時接口或異步批量導入的方式調用統一商戶管理系統,作為業務準入工作流的第一個任務節點,自動創建流程,后由銀行后臺運營人員接收并審核。
與支付結算系統的集成關系:統一商戶管理作為商戶的業務準入、技術準入的入口,是支付結算系統的業務規則數據源。商戶數據通過銀行內部合規的運營流程的層層審核,最后導入到相應的支付產品所歸屬的支付結算應用系統。支付結算系統中存在必要非全部的商戶數據,是統一商戶管理系統中數據的子集和拷貝。
3.2 系統模塊設計
根據商戶管理通用數據模型設計以及運營工作流要求,統一商戶管理系統可劃分為商戶基礎信息管理、商戶接入管理、商戶金融賬戶管理、商戶簽約管理、商戶關系管理及商戶管理工作流六大模塊。如圖4所示。
3.1.2 信息管理
統一商戶管理系統的商戶基礎信息管理、商戶接入管理、商戶金融賬戶管理、商戶簽約管理、商戶關系管理五大模塊屬于業務信息管理類。
(1)商戶基礎信息管理,包括新增商戶、修改商戶信息、注銷商戶。
(2)商戶接入管理,含實體接入工具管理和虛擬接入工具管理兩個子模塊。實體接入工具管理,包括工具配置管理、工具庫存管理;虛擬接入工具管理,包括在線安全證書的類型配置、安全證書發放、安全證書維護、安全證書注銷等;
(3)商戶金融賬戶管理,包括賬戶類型配置、新增關聯賬戶、修改關聯賬戶信息、取消關聯賬戶。
(4)商戶簽約管理,一般根據不同支付結算業務劃分相應的子模塊。如POS收單簽約、B2C支付簽約、B2B支付簽約、快捷支付簽約等。
(5)商戶關系管理,包括關系類型配置、關系網絡創建、關系網絡維護等。
3.1.3 工作流管理
統一商戶管理系統的商戶管理工作流模塊屬于工作流管理類,主要包括用戶角色管理、角色權限分配、任務權限關聯等內容。
工作流管理中涉及到重要的用戶權限控制,可采用基于角色的訪問控制模型(Role Based Access Control,簡稱RBAC)進行設計。RBAC基本模型包含了三個重要的實體:用戶User、角色Role、權限Privilege。一個用戶可以被賦予若干角色,一個角色也可以被賦予給若干個具體用戶,用戶和角色之間是多對多的關系。同樣,一個角色可以具有多項權限,一項權限也可被賦予給多個不同的角色,角色和權限之間也是多對多的關系。
工作流采用RBAC來控制各個任務節點的權限,工作流由多個任務節點按一定邏輯順序連接在一起,一個任務節點為了實現針對用戶的操作權限控制,可與RBAC模型中的權限關聯,任務節點與權限之間是多對一的關系。如圖5所示。
4 系統實現示例
基于文中闡述的商戶管理通用數據模型及系統設計,可使用面向對象的語言及輕量級的開發框架快速搭建系統原型。以下以民生銀行統一商戶管理平臺為例,簡單介紹系統實現相關內容。民生銀行統一商戶管理平臺的開發,使用Java語言,采用了經典的MVC框架,選用Spring MVC + Spring + iBatis開源框架進行構建。該平臺主要面向商戶拓展人員、銀行運營管理人員、銀行科技人員等用戶群體。如圖6所示。
5 結束語
為提高銀行商戶管理運營效率、優化銀行支付結算應用架構,達到“數據集中、操作統一、接入通用”的管理目標,文中設計了一種通用的商戶管理數據模型,并基于該模型設計了統一商戶管理的系統。通過該系統,通過統一入口對不同的支付結算業務商戶管理進行統一處理,顯著改善了商戶信息管理分散的問題。
在未來的研究工作中,將會跟進新興支付商業模式,致力于完善數據模型的通用性,進一步提升該系統對各類新模式下商戶新特性的適配能力。
參考文獻
[1]黃聰,賈彥東.金融網絡視角下的宏觀審慎管理——基于銀行間支付結算數據的實證分析[J].金融研究,2010,4(358): 1-14.
[2]李麗.對銀行支付系統設計的探討[J]. 陜西師范大學學報,2006,35(sup):67-68.
[3]付雄,程文青,郎為民,譚運猛,熊志強. 安全電子支付系統研究[J].計算機科學, 2005,32(01):108-110.
[4]俞軍備.基于商戶關系的購物中心商戶組合優化研究[D].上海:同濟大學,2009:1-133.
[5]饒林,周鵬博.有效實現第三方支付風險監管的幾點建議[J].金融理論與實踐, 2008(09):110-111.
[6]Sandbu R.Role-Based Access Control[M].Advance inComputers, 1998,46:P1-49.
[7]肖弘月,吳剛.面向多商戶的第三方電子券系統設計與實現[J].微型電腦應用, 2012,28(07):31-37.
[8]姚加賢.特約商戶管理模式的比較與選擇[J].金卡工程,1999(07):1-7.
[9]戴一崗.銀行卡特約商戶管理的問題及應對措施[J].金融科技時代,2011, 19(12):78-79.
[10]范佳榮,裘志華.大掌柜個體商戶管理系統的分析與設計[J].辦公自動化, 2014(09):41-43.
[11]張曉辰.民生銀行商戶管理系統的設計與實現[D].山東:山東大學,2014:1-54.
[12]陳冰婷.成都移動聯盟商戶管理研究[D]. 四川:電子科技大學,2013:1-50
作者簡介
林冠峰,男,北京市人。碩士學位。現為中國民生銀行信息科技部項目經理。主要研究方向為互聯網支付、移動支付、銀行支付結算應用。
曾陽,男,北京市人。碩士學位。現為中國民生銀行信息科技部軟件工程師。主要研究方向為移動支付、移動互聯收單。
作者單位
中國民生銀行信息科技部 北京市 101300