整个《支付设计(清结算篇)》历时5个月终于全部结束了,很多人劝我就199的课程你介绍百万级的系统设计,还提供参数资料、全部交互设计不是在干傻事吗?其实我也知道,以我对支付的理解深度,用表面的细节和组装一些名字云罩雾绕的写一堆“伪干货”大多数人都看不出来。但是我觉得这么写东西去误导别人不如不写,一方面是浪费别人的时间,另一方面在支付领域错误理解应用到工作中轻则挨喷,重则可能是生产事故。本课程最耗费时间的倒不是几十万字的文章和10几套系统的原型,而是怎么把“信息、账务、资金”之间三流合一的匹配关系能够解释清楚。为此在写这套课程期间,我翻阅的大量设计资料,表结构,代码。很多地方也找了相关的专家确认具体的实现方式,以确保呈现给大家的是真实、可靠、透明的白盒内容。另外为了秉持白话科普的风格,我将多年的经验整理成了12套设计思想和口诀,以便大家快速的理解。并且把里面的核心知识整理成了《支付知识地图》方便大家更直观学习支付知识。由于知识地图篇幅较大,导出全量的图显示有问题,只能先给大家提供“知识地图-试看版”,并编写本文把12套模型介绍给大家。
01、核心思想“三流合一”
1.1、什么是支付
什么是支付,业内共识的定义式“支付=交易+清分+结算”,其中交易可以理解成信息流、结算是资金流、清算是结算前的准备动作,在系统实现上就是订单数据清分和过渡科目账务处理。1.2、实物现金的二流合一
我们平时交流支付的时候都习惯于称之为“二流合一”,即信息流和资金流,其实这是大家对支付的黑盒理解。因为早期的支付,用户都是线下事先约定,然后通过银行进行跨行转账和汇款。这种实物资金的转移,收款人立即收到钱,也没人在意中间银行之间是怎么清算的。因此称之为二流合一也比较方便。1.3、电子支付的三流合一
移动支付出现后,收单机构通过在银行开通备付金,并给买卖双方开通支付账户,用户就可以在线进行支付、确定订单和结算。这个过程中支付机构给用户开通了存放电子现金的支付账户,通过跨行支付指令到开户行完成收付款。用户看到的支付结果,其实是一笔电子记账信息。当银行给支付机构的备付金账户完成清算后,用户这笔电子记账信息就成为可以使用的电子现金。因此,电子支付场景中“信息流、账务流、资金流”之间的衔接关系就显得非常重要了。02、基础篇:6套设计模型
2.1、三流合一,耦合架构
支付架构作为业务的载体也是呈现出了三流合一的耦合交易链路。日间交易链路让指令快速的进行跨行收付款,支付的结果以账务的形式登记。日终的结算链路通过对账和清结算,将待结算的账务变成用户实际可用的资金。实现资金和账务的最终一致。2.2、四段交互,支付收银
随着移动支付的推广,以及微信/支付宝的长期的市场教育,它们的收银台交互已经成为事实上的行业标准。收银台的支付过程被切分成非常原子化的四个阶段,这种处理即有利于支付安全,也能进行定制化的聚合包装。2.3、四句口诀,交易系统
交易系统为前端的收银台、app、钱包等用户提供了场景化的支付产品,虽然交易系统面对的场景纷繁复杂,但是结合联机交易和日终结算的流程,可以将交易规则总结成四句口诀。2.3.1、联机交易控制
2.3.1.1、两个范式,流程控制
先发送渠道,后本地扣款,根据渠道结果更新本地订单和账务信息,这样可以确保只有成功后才会给客户增加余额。先本地记账扣减客户余额,后发送渠道,根据渠道结果来更新账务信息。如果成功则更新订单为成功,如果失败则冲正本地账务然后更新订单为失败。2.3.1.2、三态控制,流程节点
支付过程需要跨多个外部过系统,因此涉及很多的交易节点,这些节点都是通过“成功、失败、处理中”这三类状态来控制的。其中成功、失败为终态,处理中为运行态。1)终态:
成功和失败为终态,它意味着结果将不再改变,可以参与日终的对账和结算。(那要退款怎么办?重新生成一笔订单呗)
2)运行态
处理中、待支付、待撤销等是运行态,它是用来控制每个流程节点流转。运行态不参与对账和结算,必须确认其终态后才可以。2.3.1.3、查退合一,订单和资金同步
支付过程中存在异常订单需要去确认结果,也存在用户请求退款和撤销来返还资金,因此在交易过程中需要设计“订单同步交易”和“逆向支付交易”。1、订单同步交易
1)订单查证:通过实时或者定时轮询来查询渠道支付结果来更正本地状态。
2)回调通知:根据渠道回调结果来更新本地状态。
2、逆向支付交易:
1)撤销:在途资金未结算给商户时的逆向交易称为撤销;
2)退款:资金结算到商户账户后在规定时间内进行的逆向交易为退款。2.3.2、日终差错处理:
如果有一些日间交易始终没有办法得到应答,此时就需要通过日终对账来确定最终状态,如果确实是差错,就需要通过调账来解决,这个过程都要做到订单和资金最终一致。一般都是通过“冲补挂”三种方式来进行差错处理。3、挂账:为了及时结算,有些异常账务先挂账到内部户,后面人工处理后进行核销。2.4、三类因子,渠道路由
用户支付过程中选择支付通道是一个筛选和匹配过程,需要根据渠道特性和规则来找到既快速又经济的支付路径。为了进行路由我们根据渠道特性抽取了三类路由因子作为渠道筛选的条件来作为渠道路由的策略。1)基础因子:
支付渠道的通用特性,通过基础因子能够对渠道进行全面而快速的筛选。如果命中渠道,会直接跳到最后一步进行支付。
2)扩展因子:
仅有标准的路由因子是不够的,即使相同的支付产品,渠道侧机构也会有不同的个性化特征来进行适配,为此要给这些渠道设置扩展特性来进行个性化的路由筛选。
3)技术因子:
完成业务路由,最终访问渠道网关前需要挑一条稳定好用的渠道给客户,这里就要对渠道的质量进行筛选。如果渠道运行良好就能提供给客户使用,反之则要降级、分流。2.5、三户模型,客户体系
开通支付产品之前首先要成为支付机构的客户,而客户模型是受限于组织机构的,可以这么说一家公司做什么生意,他的组织机构和客户模型的选择是有所不同的,与之对应的系统实现、核心流程和产品签约授权关系也会有所不同。本文举例的会员体系下的客户模型,他天然的认为所有参与交易的用户都是他的客户。1)客户(管理视角)
个人或者企业在社会体系中的唯一身份,一般作为内部合规、风控信息管理来使用,终端用户无感知。
2)用户(用户视角)
产品或者服务的使用者,又称为登录账号,企业场景可以是多个非同名的操作员。
3)账户(资产视角)
2.6、一户多卡,钱包账户
钱包账户主要面向C端用户提供零钱、卡券、理财、信贷等零售应用,因此他兼具储值和营销的功能。一户多卡的模式就是服务于这类在不同场景下提供金融和营销服务的产物。1、一户:开通一个主账户作为钱包一方面为了处置,另一方面与平台内商户进行交易
2、多卡:外部账户为卡,采用绑卡的方式进行关联,用来接入多种合作营销场景。03、进阶篇:3套会计模型
3.1、金融借贷规则地图
金融行业和普通企业的区别在于它经营的商品是比较特殊的“货币”,因此他的账务处理也是三流合一的耦合在一起的。通过”收付实现制”让客户的资金能够实时变动(即实收实付),通过权责发生制(应收应付)进行会计账簿的登记,最终通过核算来实现账务和资金的最终一致。因此这张金融会计的记账规则表要牢记,并且熟练运用,假以时日你也能随手写出会计分录来了。3.2、三板斧搞定,会计科目
牢记借贷规则后你还有一个门槛要跨越,就是大量的会计科目要熟悉,很多机构的产品账套经常是上千个科目,显然这些不是通过死记硬背能够解决的。其实科目和分录就是用会计语言对经济业务的描述,而软件系统计算机语言对因为场景的描述。因此会计科目和软件系统模块划分之间是可以映射起来的。通过待清算、交易、辖内往来这三板斧,可以完美的将“外部渠道、内部交易与客户、辖内资金流转”进行清晰的划分。上图我们可以看到支付业务的科目90%都在渠道上,剩下的就是交易和客户间资金流转。3.3、四步搞定,账务核算
基于三流合一的设计思想,支付的核算可以分为“联机交易、渠道清算、客资结算和银存结转”四个步骤。这四步的清结算账务也就是“收付退”的核算过程,最终在途资金通过待清算和银存之间的结转完成平账。04、高阶篇:3套专家模型
4.1、内外双驱,支付引擎
支付引擎是支付核心的三大系统之一,他对外提供了一套原子化的支付接口,为上游的交易系统提供账务和清算服务。支付引擎既要记账准确,又要跨行清算快速,因此采用了内场记账和外场清算的方式来处理。内场记账和外场清算就像一辆双驱跑车,既分工合作也相互配合,实现高速和准确的记账。4.2、清算结转,清结算系统
清结算过程就是日终结算的发动机,它把日间联机交易产生的账务通过“渠道清算、客资结算”两个步骤完成业务层面的明细账目平衡,最终支付核心总账汇总完成所有账务的平衡后系统结账并日切。4.3、最终一致,支付核心
4.3.1、单边记账客资动账
支付系统需要承担较大的交易请求,记账过程采用外部客户账户单边记账,内部账户和会计账异步记账的方式。这样对用户的影响最小,也能处理更大的支付账务请求。4.3.2、实时/缓冲分录记账
异步推送会计账务请求会先落入“分录流水”表中,然后进行会计账簿的记录和内部账户的更新。为了提高记账的性能,支付核心采用实时和缓冲两种记账方式。1)实时记账:大部分交易都是采用实时记账的方式进行会计账务处理和内部户余额更新。
2)缓冲记账:部分交易由于涉及过渡户和大量的客户账户之间的账务处理,为了减少性能瓶颈系统会采用“缓冲记账”的方式,定时进行汇总批量记账。4.3.3、总分平衡最终一致
期末日切后系统会进行总分账核对后进行总账结账,保持当日的期末余额后切换到下个会计日期,一天的交易、账务和资金就全部一致了。05、本文资料和课程
5.1、获取知识地图
关注公众号,回复“知识地图”获取“支付知识地图-试看版”5.2、获取本文课程
扫下方二维码获取16套课程,10套交互设计,12套专家模型高清知识地图。