银行统一商户管理模型与系统设计
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
银行统一商户管理模型与系统设计
作者:林冠峰曾阳
来源:《电子技术与软件工程》2016年第16期
摘要
随着银行面向商户的支付结算系统不断发展,商户管理作为支付结算系统的基础应用模块也需改变以适应各类新型商业模式的使用。在国内银行大力发展“双线”支付模式——线下支付和线上(互联网)支付的背景下,其商户管理系统建设普遍出现数据模型不统一、商户信息不集中、商户接入管理分散等问题。文中提出了银行统一商户模型的设计,通过抽象化线上线下商户数据模型,设计了通用的商户基础信息、接入模式及签约管理等模块。该设计能有效地支撑银行支付结算的商户信息管理集中,显著提高银行运营管理效率,简化银行支付应用系统架构。最后提供了系统开发示例,并做了总结。
【关键词】商户管理系统支付结算商户数据模型商户接入安全工具
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 平台外部拓展商户的间连关系
该类合作商户一般属于平台,该平台自己具备拓展商户的能力,构建了自身的中心化的商户网络结构。比如客如云是一家餐饮行业的智能点餐平台,客如云自身拓展了众多餐饮企业、门店及外卖店等商家,为商家提供餐饮软件服务,包括了预定、排队、外卖、点餐、收银等功能,其中涉及客户支付的功能对接了银行的支付结算系统。各商家通过合作平台间接地享受银行的支付结算服务,商户与银行是一种单向连接的弱关系。