支付行业架构流程梳理

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/weikeke410/article/details/84323330

一、第三方支付产生的背景

最开始做第三方支付产品的公司是PayPal,也就是中文名为:贝宝(建议阅读《支付战争》)。

国内的产生的背景是随着互联网电子商务发展起来的,阿里巴巴和慧聪网把线下的商务交易转移到互联网上,在1998年首易信支付开始做第三方支付,当时功能仅仅是把用户的支付需求告知银行,让用户在银行的网上支付页面完成支付这样简单的支付模式上。

在2005年,阿里巴巴的马云提出第三方支付平台的概念(建议阅读《蚂蚁金服》)。

二、第三方支付牌照现状

央行总计发出了272张支付牌照,截止2018年6月央行注销了29张第三方支付牌照,全国剩余243张实际有效期242张,湖北蓝天星主动注销支付牌照,央行网站未更新。

三、我国现代支付体系及第三方支付行业

 

3.1 第三方支付产品链:

3.2  支付行业与类型

第三方支付现在可以分为线上和线下支付两个部分。线上支付分为基于PC端的互联网支付和基于移动端的移动支付。线下支付中占据最大市场份额的是银行卡收单业务,其他还包括扫码支付和预付卡业务等。第三方支付行业主要包括银行卡收单,网络支付及预付费卡发行与受理三种主要的业务类型,进一步细分又分为线下收单,互联网支付,移动支付,跨境支付等领域。

3.3  第三方支付参与者的主要盈利模式

产业链的不同环节赚取不同利润。

第三方支付企业目前主要的盈利方式:电商交易商户交易佣金;沉淀资金利息收入等。

银行的核心业务是负债业务和资产业务,支付清算和电子银行业务只是银行中间业务中的一小部分,该类业务占银行业务收入的占比非常小。

银联的核心商业模式有银行卡收单跨行交易手续费分润;ATM跨行取款收费;非金融机构支付清算;银行卡发行品牌服务(类似冠名)。

商业银行:银行卡交易发卡行手续费分润;银行卡交易收单行手续费分润;电子银行转账等手续费;快捷支付手续费分润支付。

支付清算是第三方支付的主要业务,是帮助实现资金转移支付的工具,银行对电子银行的业务的发展是为了更好的服务由资产业务和负债业务而产生的存量客户;电子支付作为第三方支付的根基,其要做到以支付产品去吸引用户,留住用户,所以在支付产品的开发、流程的优化的迫切性要远高于商业银行。资产负债类业务在银行电子支付业务之先,银行并非一定要通过支付数据的开发扩展新的业务模式,其对数据资源的重视和利用程度不如第三方支付。下图为第三方支付企业的盈利模式:

3.4 第三方支付企业市场规模

线上支付(PC端和移动端):在2015年其市场规模超过20万亿。互联网支付的爆发式增长先于移动支付,且在2015年两者都实现了快速增长。近两年,移动支付快于互联网支付,显示了手机端对用户的粘性越大,且明显感觉到移动支付的增长规模要远超于PC端支付,在2016年市场规模有望达到28.7万亿。

线下支付:主要为POS收单业务,扫码支付和预付卡支付等。扫码支付和预付卡支付市场均在千亿级别。

四、第三方支付系统整体架构

 

4.1 支付产品的主要分类

以下产品为绝大部分的支付公司所包含的产品:快捷支付(API快捷),网银支付,收银台产品、代付(分为单笔和批量),代扣(分为单笔和批量),余额支付(账户体系为前提的)。二级产品(公缴费:电话费,水电燃气费,信用卡还款)、跨境支付等,信用支付。

注:代扣是其实是协议支付,信用卡预约还款也属于协议支付。

快捷支付:是第三方支付提供接口,商户使用接口包装自己的支付产品,使产品拥有支付功能。

网银支付:是在商户的平台上,通过第三方支付的调用接口跳转到银行的网银页面,让用户去支付的形式。

收银台:是第三方支付将快捷支付,网银……等等支付功能集合到一个收银台内,供用户选择支付方式。

协议支付:包括代扣,信用卡预约还款,有线电视费定期扣费,渠道商和用户签订的协议中协定了每个月联系扣款等,在用户取消续约之后,就取消扣款等。在后台调用的就是代扣的接口。这类是从用户的卡上扣款到商户或平台,需要通用同意协议。

代付:将平台或商户的钱打给用户。

支付产品的支付支付能力,对外提供的功能大致有如下:

名词解释:

预授权:预授权交易用户受理方向持卡人的发卡方确认交易许可。受理方将预估的消费金额作为预授权金额,发送给持卡人的发卡方。

签约:在快捷支付和代扣等产品中,用户在使用前,需要先完成签约。签约可以在渠道侧进行,一般情况下在第三方支付公司会和银行去签约。在电商需要接入时,电商负责收集用户的信息,调用银行和银联的接口进行签约,签约后,后续的支付行为就可以使用签约号来进行,无需再输入个人信息。

解约:解除签约关系,银行不再到期扣款。

撤销:在渠道侧(电商或商户)对未结算的交易发起撤销本交易的请求;

退款:针对已经结算的交易或者未结算的交易发起退款请求。(不同的支付机构要求不同)

查询签约状态:对于需要签约的交易,可以通过接口查询签约状态。

查询订单状态:通过接口查询支付订单状态及信息(任何订单都可查询交易状态)

对账:通过FTP或者HTTP的方式提供对账文件供商户侧对账。

余额查询:查询商户的交易账户的余额,避免由于余额不足导致交易失败。

4.2 支付业务流程

除了对账、查单外,每个操作实现的主流程,一般会包括参数校验,支付路由,生成订单,风险评估,调用渠道服务,更新订单和发送消息这7步,对于一些比较复杂的服务,还会涉及到异步同通知处理的步骤。

1、执行参数校验

所有的支付操作,都需要对输入参数执行参数校验,避免接口受到攻击。

验证输入参数中各字段的有效性验证,比如用户ID,商户ID,价格,返回地址等参数。

验证账户状态:交易主体,交易对手等账户的状态是可交易的状态。

验证订单:如果设计到预订单,还需要验证订单号的有效性,订单状态是未支付。为了避免用户缓存某个URL地址,还需要校验下单时间和支付时间是否超过预定的时间间隔。

验证签名:签名也是为了防止接口被伪造。一般签名是使用分发给商户的Key对来输入参数拼接成的字符串做MD5Hash 或者RSA 加密,然后作为一个参数随其他参数一起提交到服务器端。

2、根据支付路由寻找合适的支付服务

根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。

比如用户选择工行信用卡来执行支付,但是我们没有实现和工行的对接,而是可以通过第三方支付,比如支付宝,微信支付,易宝支付,或者银联来完成。那如何选择合适的支付渠道,就通过支付路由实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。

3、评估交易风险

检查本次交易是否有风险。风控接口返回三种结果:阻断交易,增强验证和放行交易。

1):阻断交易,说明该交易是高风险的,需要终止,不执行第五个步骤;

2):增强验证,说明该交易有一定的风险,需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验,验证通过后,可以继续执行该交易。

3):放行交易,即本次交易是安全的,可以继续往下走。

4、生成交易订单

将订单信息持久化到数据库中。当访问压力大的时候,数据库写入会成为一个瓶颈。

5、调用支付渠道提供的服务

所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单,可以直接返回结果。一些第三方支付、支付宝,微信支付等,会通过异步通知接口来告知支付结果。

6、更新订单

对于同步返回的结果,需要在主线程中更新订单的状态,标记是支付成功还是失败。对于异步返回的渠道,需要在异步程序中处理。

7、发送消息

通过消息来通知相关系统关于订单的变更。风控,信用BI等,都需要依赖这数据做准实时计算。

8、异步通知

如上述流程,其中涉及到调用远程接口,其延迟不可控。如果调用方一直阻塞等待,很容易超时。引入异步通知机制,可以让调用方在主线程中尽快返回,通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口,也需要对应的在异步通知中将结果返回给调用方。

异步通知需要调用方提供一个回调地址,一般以http或者https的方式。这就有技术风险,如果调用失败,还需要重试。而重试不能过于频繁,需要逐步拉大每一次重试的时间间隔。在异步处理程序中,订单根据处理结果变更状态后,也要发消息通知相关系统。

4.3 支付宝系统架构设计

图示为支付宝顶层设计:

一:账务处理在记账方面,涉及到内外两个子系统,外部系统是单边账,满足线上性能需求;内部子系统走复式记账,满足财务需求。在清结算这个章节中也是基于这个模型来详细介绍如何记账,对账和平账。

另一个亮点是柔性事务处理,利用消息机制来实现跨系统的事务处理,避免数据库锁导致的性能问题。

4.4 京东支付系统架构设计

4.5 去哪儿的支付系统架构设计

4.6  支付系统从架构上说,分三层

1、支撑层

用来支持核心系统的基础软件包和基础设施,包括运维监控系统、日志分析系统等。

包括:运维监控,日志分析,短信平台,安全机制,统计报表,远程连接管理,分布式计算,消息机制,全文检索,文件传输,数据存储,机器学习等。都是构建大型系统所必须的基础软件。

2、核心层

支付系统的核心模块,内部又分为两个部分:支付核心模块以及支付服务模块。

包括:用户从支付应用启动支付流程;支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付;支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付;支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作,最终落地资金转移。

3、产品层

通过核心层提供的服务组合起来,对最终用户、商户、运营管理人员提供的系统。

服务系统

支付核心系统所提供的功能。服务系统又分为基础服务系统、资金系统、风控和信用系统。

基础服务系统

提供支撑线上支付系统运行的基础业务功能:

客户信息管理

包括对用户、商户的实名身份、基本信息、协议的管理;

卡券管理:对优惠券,代金券,折扣券的制作,发放,使用流程的管理;

支付通道管理:通道接口,配置参数,费用,限额以及QOS(Quality of Service 服务质量)的管理;

账户和账务管理

管理账户信息以及交易流水,记账凭证等。这里的账务一般指对接线上的账务,采用单边账的记账模式。内部账记录在会计核算系统中。

订单系统:一般订单系统可以独立于业务系统来实现了的。这里的订单,主要指支付订单。

资金系统

指围绕财务会计而产生的后台资金核实、调度和管理的系统,包括:会计核算:提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。

资金管理:管理公司在各个支付渠道的头寸,在余额不足时进行打款。对第三方支付公司,还需要对备付金进行管理。

清算分润

对于有分润需求的业务,还需要提供分清算、对账处理和计费分润功能。

风控系统

是支付系统必备的基础功能,所有的支付行为必须做风险评估并采取对应的措施;信用系统是在风控基础上发展的高级功能,京东的白条,蚂蚁花呗,都是成功的案例。

总体来说,可以按照使用对象分为针对最终用户的应用,针对商户的应用,针对运营人员的运营管理、BI和风控后台。

猜你喜欢

转载自blog.csdn.net/weikeke410/article/details/84323330