支付入门基础知识普及贴!纯干货!

2018-12-20 09:03:07 大雄 213

   

名词解释


1、支付:指货币债权从付款人向受付人的转移,属于电子货币的结算。

2、支付流程:包括支付的发起、支付指令的交换与清算、支付的结算等。

3、清算:指结算之前对支付指令进行发送、对账、确认的处理,还可能包括指令的轧差,属于电子货币和真实货币的核对。

4、结算:指双方或对支付交易相关债务的清偿,属于真实货币的结算。

5、轧差:指交易伙伴或参与方之间各种余额或债务的对冲,以产生结算的最终余额。

6、会计科目:指对各项会计要素按其反映的经济内容和管理要求不同所进行科学分类的项目。

7、业务系统:比如电商系统,指提出交易的系统,通常通过业务系统调用支付系统。

8、支付系统:指完成支付过程的系统,起点在支付网关,终点在告知业务系统支付结果。支付系统会串联发卡机构、支付渠道、收单机构和结算业务。

 

账户是什么?


这里提的账户主要指支付账户(会计账户),即用户在支付系统中用于交易的资金所有者权证的凭证。


注意区别于一般登录账户,即用户在系统中的登录凭证和个人信息。


通常一个登录账户可以有多个支付账户。

 

账户记录什么?


支付账户通常会记录两种信息:


1、分户账信息,包括该账户当前的所有状态信息,如账号、类别、余额、冻结金额、充值未到账金额、币种、状态、开户时间、科目等;


2、流水信息,包括一个账户所有状态变化的过程信息,如开户、变更、记账、查询等。

 

账户对业务有什么用?


交易的实现必须有账户支持。

支付的实现必须有账户支持。

清算的实现必须有账户支持。

结算的实现必须有账户支持。

 

账户对会计有什么用?


特别好理解,公司的业务很多,会计对每一笔交易都要做详细的记账,所以没有账户就没有会计业务了。

 

会计怎么设置账户?


会计科目一般会有资产类、负债类、所有者权益类以及其他不需要知道的。


一般严格遵守“资产=负债+所有者权益”和“复式记账法”:


资产类科目余额一般在借方,负债类科目余额一般在贷方,所有者权益类余额不一定。

会计科目最顶层是总账科目(一级),挂在上面说的三大类目之下;

明细科目在一级科目下,可以分二、三级;

最底层的科目就要对应到账户了,也就是上面说的支付账户(会计账户),每一个会计账户要对应一个实际的资金账户。


会计记账是一个挺复杂的事情,不用深入掌握,但需要知道:


1、他们对于业务上的每一次资金行为,都会做一次记录;

2、每一次记录,都会记一笔借和一笔贷;

3、每一次记录,都会记到一个实际存在的会计科目上,并且会记到会计科目的最底层。

 

业务系统怎么分不同的账户?


记住一个原则:能知道该账户所有分账户信息的,定义为内部账户,比如微信钱包里的零钱账户、支付宝里的余额账户;只能知道该账户在系统里流水信息的,一般都是外部账户,比如支付宝里绑一张招商银行卡,比如我们在银行或者第三方支付公司开设收款账户用于结算。


一般来说,内部账户不需要对账(也需要,只是比较简单),外部账户需要认真对账,出了问题要处理,会计工作时经常遇到的坑,都是外部账户导致的。

 

以上差不多讲完基本概念了,下面通过支付流程介绍支付系统架构。

 

用户视角里一次开心满意的支付流程:


1、小明在京东看中一件商品价值200,想买,点击“去结算”按钮;

2、小明进入订单详情页,选择收货地址、发票等信息填写后,点击“支付”按钮;

3、小明进入收银台,选择支付方式,如微信支付、支付宝、某张已绑定的银行卡,点击“确认支付”按钮;

4、小明跳转至第三方支付页面输入支付密码(也可能在不跳转的情况下直接输入支付密码);

5、小明在支付完成后看到页面跳转回到京东,显示支付已完成,剩下就是等待快递送货上门。

以上5步就是一个用户认知里面的支付体验,看似很简单,而且事实上只有3、4、5才是支付系统在做的事情。然而,为了满足用户体验和用户安全这两个相对矛盾的点,支付产品经理要考虑很多问题,涉及到支付网关、支付路由、风险控制、支付渠道、支付接口这几个关键模块。


我们抛问题,然后通过解决问题的方式引出概念。

 

比较完整的支付系统模块有什么?


1、应用层:

(1)支付应用,如收银台、银行卡管理、余额查询(分户账)、交易查询(流水)等;

(2)数据分析;

(3)交易风控:用于合规性校验的风控、反洗钱等,对每一次交易,风控模块都会返回三选一的结果:拦截本次支付申请、增强校验、通过申请。


2、接口层:

与其他系统的对接,核心是支付网关,它是业务系统和银行系统的中间层,既会将所有支付服务统一呈现给业务方,降低业务系统的对接难度,也会批量收集业务系统的订单任务,统一提交给银行系统,里面包含:

(1)参数校验(安全性、完整性、有效性);

(2)支付路由选择;

(3)支付渠道调用;

(4)接口消息管理。


3、其他层:

和正常的系统分层类似,还有服务层(提供API,支撑应用层的)、数据库层(做最底层数据存储的)、引擎层(具体功能模块算法会写在这一层)。

 

业务系统欺骗支付系统怎么办?


也就是说,当业务系统向支付系统发起支付申请的时候,怎么判断是正常业务,没有被攻击。


答案是参数校验。支付系统工作的起点,一定是对调用它的指令做参数校验。因此,在业务系统和支付系统对接时,首先要做的事情其实是约定,约定以后打交道时候的加密机制也就是签名。通常不同的支付渠道会有不同的要求,但逻辑都是渠道给个加密器,然后我们基于加密器做字符串拼接,每次校验时都先验证这个参数。


当然,除了校验签名外,参数校验也会验证输入参数的完整性、有效性,包括用户ID、商家ID、交易双方账户状态、订单时间、交易金额、收单机构等。


怎样接入支付渠道?


先不管有哪些支付渠道,说一下常规流程:


1、找一家支付渠道;

2、在这个渠道注册商家账户,绑定真实资金账户;

3、申请开通支付产品,也称支付方式,包括网页支付、认证支付、快捷支付等:

(1)网页支付需要在客户端新建一个web view,调用服务器URL地址并传参,实现简单;

(2)认证支付要调用SDK,在客户端直接获取用户所有信息,存储在服务器端,然后直接向支付渠道发起请求,安全性低;

(3)快捷支付也要调用SDK,但支付渠道会返回token作为后续支付凭证,服务器端不需要存储用户卡号等信息。

4、研发对接接口,需要一个服务器安装加密器。

 

支付渠道有哪些?


一个一个说:


1、银行:通过拉专线的方式连接,还要基于不同银行的加密要求安装加密机,加密机基本上都是上个世纪的机器才可以安装;而且银行那么多,基本上这事干不了,除非某家银行覆盖90%的业务且直连优势明显。

2、银联:可以理解为官方版的第三方支付,不需要拉专线了。

3、第三方支付:支付宝、微信支付、其他。

4、手机支付:指的是类似Apple Pay这样的支付渠道。

5、话费支付:直接对接运营商或对接话费支付整合机构。


特别说明:快捷支付、网银支付、代扣这些概念不等于支付渠道,它们属于支付产品或支付方式。

如果有人说银行代扣,其实传递了两个信息:支付通道是银行、支付产品是代扣。

 

怎样调用支付渠道提供的服务?


1、调用前:

(1)执行参数校验;

(2)基于支付路由寻找合适的支付渠道;

(3)评估交易风险。


2、调用过程:

通常只有银行才会提供同步接口,也就说调用该接口支付,然后实时反馈是否扣款成功;

其他的支付渠道全部是异步接口:


(1)当支付请求开始调用时,支付渠道方会很快返回一个结果,告诉你调用成功,特别注意这里不是扣款成功;

(2)然后经过3到5秒的延迟,支付渠道方才能告知我们扣款是否成功。原因很简单,除银行外的支付渠道,要用这3到5秒的时间向银行发起请求,做信息流登记,只有那头确认了,它们才能跟我们确认;

(3)所以,我们在发起支付请求的时候,肯定会在参数里带一个回调地址,这个地址是给支付渠道用的,当它们和银行确认自己扣款成功后,调用这个地址告诉我们扣款成功,然后我们接收后再同步反馈他们调用成功;

(4)注意几个坑:

1)错把第一次的调用成功当初扣款成功,更新我们自己的账户、流水、日志;

2)支付渠道告诉我们扣款成功后,忘记提示对方调用成功,导致对方不停调用,不停告诉我们扣款成功;

3)支付渠道根本没有调用回调地址,我们也没有主动发起查单请求,导致该请求搁置。

基于上面讲的这些,应该可以看出支付渠道连接和调用的各种坑了。因此,才会有支付网关、支付路由的概念。

 

支付网关是什么?


我们简单点来理解,由于支付渠道太多,提供的服务种类太多,交叉项太多,我们需要整合到一个相对统一的模块完成与业务系统的对接。有些收银台可以认为是支付网关的展示页,有些不是。

 

支付路由是什么?


一言以蔽之,支付路由是一个规则引擎。

通过支付路由规则将适当的支付请求推荐到适当的支付渠道,完成清算、结算、收单的工作。

首先记住一个原则:支付最重要的是保障交易安全性。

在这个原则满足的前期下,才去考虑支付的收益管理职能,才去考虑用户需求体验满足度、支付收益率、支付渠道商业关系等复杂问题。


举几个栗子:

1、小明在支付请求时,选的是招商银行扣款10万,支付路由在判断的时候发现当前A支付渠道的招商银行限额5万,B支付渠道限额10万,选择B渠道响应本次请求(PS:关于银行在不同支付渠道的限额问题,又是一个千年大坑,而且没法实时监控);

2、小明选的是安徽银行,支付路由判断只有一家支付渠道可以提供安徽银行服务,没得选;

3、对招商银行的请求,我们有多个支付渠道都可以响应,A的通道费极低,那1万次的请求里,我们应该9950次选择A渠道,剩下50次选择其他渠道(不能不选,支付渠道也有运营监控,长期不跟他们玩,会关闭我们的,渠道备份很重要,你永远不知道下一次哪个渠道会出问题)。


上面几个栗子可以看出,支付路由也很复杂,需要兼顾各种因素,要设计权重、监控、公式等。

衡量支付路由的好坏,可以看几个指标:支付成功率、支付损耗率、支付收益率。

 

此外再提一个概念:卡BIN。

卡BIN由国际标准化组织分给从事跨行业务的银行卡组织,在中国每张银行卡的前6位就是该银行的卡BIN,基于卡BIN库可以直接识别银行发行机构。

 

信息流和资金流是什么?


记住一个原则:资金流滞后于信息流。

然后从易到难看资金流。


1、支付渠道为银行的行内支付:

极简单,银行调用内部系统完成信息流变动直接带动资金流变动,结算在1毫秒。

2、支付渠道为银联的行内支付:

银联告诉该银行,银行调用内部系统完成信息流变动,带动资金流变动。

3、支付渠道为银联的跨行支付:

银联会同时发信息给两家,完成各自账户的余额增减;然后日结时两家先做清算,看看谁欠谁钱,再做结算,完成资金流变动,会T+1到账。

4、支付渠道为第三方支付公司的行内支付:

第三方支付公司告诉该银行,银行调用内部系统完成信息流变动,带动资金流变动。

5、支付渠道为第三方支付公司的跨行支付:

信息流和银联一样。


注意资金流:

第三方支付公司会在每家银行开个备付金账户,里面存了钱;假设用户A从招商银行账户向用户B在民生银行账户转1万元,则A在招商银行会减去1万元并加到第三方支付的招商银行账户,同时B在民生银行账户加1万元并减去第三方支付的民生银行账户。所以第三方支付跨行转账也可以实现秒到。

 

最开始讲的用户视角里的例子,其实是一个正向案例,实际过程中有可能会出现各种问题导致支付请求无法顺利响应或响应后无法正确完成。

因此,会计同学在面对高并发、高风险的线上支付业务时,不得不做的一件事情:对账处理。


对账怎么做?


对账其实分很多个维度。外部对账、内部对账、用户对账、分户账对流水、等等。


记住一个原则:对账一定是两两相对。

流程都是一样:先找内部账户数据,然后下载外部账户数据(内部账户和外部账户见上文),接着对账,最后平账。

支付渠道都会提供外部账户账单下载,但是数据格式不一致、下载方式不一致、更新时间不一致,需要对外部账户账单做标准化管理。

内部账户因为都存在本地,比较好管理,如果对账工作量大通常会考虑使用备用数据库执行对账,避免影响线上业务。


有个遇到过的坑:

在特定时间会出现当天的账无法对清,内部的某一笔流水在外部的账户流水中没有体现,原因是支付渠道的外部账户数据会有延迟,而更新时间刚好错过了该笔流水。因此,解决方案是在对账系统里设计规则,定义好容忍时间区间,当天对不平的流水信息,和第二天的外部账户流水信息比对。


1、什么是T+0,T+1


T就是Today的意思。

T+0就是资金当天到账。T+1就是隔天。

为何会有隔天的情况发生呢?因为全国所有银行的资金信息是第二天凌晨零点进行统一清结算的。


2、银行间清结算的几个系统

 

a、小额支付系统:

5万以内的普通贷记业务可以通过央行的小额批量支付系统(BEPS)来进行。7*24小时运行,批量运行,收集到若干交易后统一打包处理,所以是非实时到账的,费用相对大额来说也比较低。此外,小额支付需要提供联行号,即支行信息,一般绑卡流程不会要求用户提供此类信息。


b、大额支付系统:

大额实时支付系统(HVPS)每笔交易都实时发送,实时清算的,所以基本上能实时到账,跨行资金零在途。但大额系统运行的时间,仅限于工作日的 8:30 ~ 17:00运行,假节日也不运行。手续费较高,需要支行信息(联行号)。


c、超级网银:

全称是“网上支付跨行清算系统 ”,2013年10月份正式投产运行。超级网银是对大小额支付系统的一个补充,接入机构不再限于银行,第三方支付也可以接入,所以有的第三方支付给商户提供的提现代发(代付)功能就是基于超级网银做的。7*24小时实时到账,单笔上限5万元。 超级网银支持绝大部分的银行。此外,超级网银交易可以不需要联行号。


d、行内清算系统:

同一银行内部转账一般通过这系统来进行,不限金额,实时到账,手续费低。


这一节,我们谈谈计费和结算。至于清算部分,我打算放在说资金渠道的章节中。


计费和结算对于支付公司非常重要,直接影响收入,对商户也非常重要。一般企业,通过提供服务和产品,向使用者收取费用。支付机构,则通过提供资金划拨服务,收取费用。


先说几个简单的定义:


计费:按照规则,算出要收取的费用,可以是手续费、佣金。

结算:同一个机构间的资金转结,收单机构将商户应收资金结算给商户。

清算:不同机构之间的资金转结,外部渠道和收单机构之间资金交收。


支付基础的基本计费规则如下:


网银支付


基本的收费模式就这些,更加复杂的收费,基于这些扩展。简单说,就是如何收费,让商户比较满意,其实类似服务定价。所谓分润,就是分配利润,支付公司给平台方分手续费用。


在上图,我省略了线下银行卡收单的收费模式,那是人行规定的固定模式,也就不说了。目前已经从原来的“71X”模式,调整到了借贷分离的模式。


计费是手段,结算才是目的。计费来源于成本,支付公司进行资金转移,是有成本的。去银行扣款,银行会收服务费,用了银联的通道,通道也会收服务费,支付公司自己也需要收取服务费,一层层下来,最终转嫁给了商户。


结算的基本要点,整理如下图:


结算会生成结算明细文件,商户的财务会通过明细汇总,和收到的款项进行核对。存在差异,则线下核实。结算非常重要,结算错了,就可能导致资损。和任何金融机构一样,都是谈资损色变。所以,结算的数据来源非常重要,一定是保证核对通过的。原则就是:对不平不结算。


计费和结算在支付公司,是非常重要的,设计不好会导致资损。支付公司最担心的是什么?资损。一般公司,资损是产品的损坏之类的。支付公司,经营的产品就是钱,钱丢了可就丢大了。损的意思是什么?损就是赔。


最后,补充一下分账的概念。


所谓分账,就是支付机构帮助平台商,将资金分别结算给对应的供应商。比如,XX平台有很多供应商。资金层面,最终要给到供应商的,也就是分账。分账有两种,一种是平台商自己给供应商分账,一般针对自营商品。另一种是收单机构给供应商分账,一般针对非自营商品。供应商后面还有供应商,一层层嵌套。所谓分佣,入驻商户给平台商支付佣金,一般基于交易量。就是分账是比较常见的需求,相对复杂,据说某宝最高支持十级实时分账,挺厉害的。


经常看到某些公司,在计费结算上,没有做到系统化,大量依靠人肉,这是非常不可取的做法。系统化的成本可能会相对较高,但是能够满足业务的快速发展,且很大程度上,能够及时预警。财务和清结算人员,最多就是审核出款而已。