对于平台而言，支付功能最简单粗暴的实现方式是业务系统直接接入支付渠道，支付和业务耦合在一起。流程见下图。
但随着业务的多样性和复杂度的变化以及业务量的提升，需要有独立的系统来维护支付规则，管理支付渠道，记录支付信息。因此引入支付系统，业务流程升级为：
在一个消费者付款流程中，支付系统需完成以下任务：
1、接受业务系统的业务订单；
2、根据业务订单类型及金额判断可支持的支付产品并返回给前端页面，让用户选择；
3、根据用户选择的支付产品，选出具体执行扣款的支付渠道；
4、根据选出的支付渠道要求组装指令，调用渠道执行扣款任务；
5、获取支付渠道通知的扣款结果或主动查询通道扣款结果；
6、通知业务系统支付结果；
以上6个任务在具体执行中可以分化出以下几个单体：
1、支付应用
平台交易每天有无数订单，支付系统需要将订单进行分类。不同类型的订单对支付渠道有着不同的需求，可以将订单类型对支付渠道的需求规则维护在支付应用层。
支付应用提供给上层业务统一模块化的调用方式，业务层而不再需要关注支付的实现。一般来说，支付应用可分为： 即时消费（消费类订单），充值（钱包类业务），转帐（钱包类业务），提现（钱包类业务），退款（异常情况处理）等。
2、支付核心（支付产品）
支付核心将下游支付渠道自身带有的原子化功能（鉴权，签约，扣款等）封装后提供给上游统一调用。上游通道仅需明确具体支付产品和金额后，由支付核心根据路由选出的渠道的接口要求组装指令，调用渠道支付接口。
支付核心应封装渠道包括验证要素，支付额度，手续费，结算账户，查询方式等属性。也要能新渠道接入的可扩展性，屏蔽各渠道的差异，将渠道差异统一维护在单个系统中。
3、支付路由
用户选择支付产品后，可以有多个支付渠道支持对应支付产品。系统需要根据特定逻辑选出具体的支付通道去执行扣款，而这个特定逻辑就是支付路由。
这里至少要包括以下几个逻辑：
1) 指定走某条通道、指定不走某条通道；
2) 选出限额满足订单金额的支付通道；
3) 选出手续费较低的通道；
4) 现有的支付要素是否满足通道要求，是否仍需要用户参与。
另外，支付应用中支持的具体支付产品，也可在路由中实现。
4、渠道管理
支付路由，和支付核心都需要根据通道特性进行判断，可以独立维护一个系统来记录通道的特性。当通道属性发生变化时，比如需要参数发生变化，费率发生变化等，通道维护时，可以在渠道管理系统中配置相关信息即可，而不需要重新发版。
基于上面的讨论，可以抽象出下面两张模型图。
支付模型
支付系统
以上仅是收款环节的设计概述，其中仍有很多单体可以展开来讲，快捷产品设计，支付路由，账户系统等等，有机会再提。
以上仅是个人在实践中的总结，如有不对的地方，还请指正。
支付平台每日早晨会收到账务系统发送的批量扣款指令，这些扣款指令需要通过 支付路由 系统获取到最优的扣款支付渠道，进而再通过 支付网关 系统送往各个支付渠道进行扣款。为了保证扣款成功率及批扣的回盘速度，这些批量扣款指令需要在1小时内全部发出。
系统调用链如下：
在对公司PAY2.0的支付路由模块（采用Drools5实现）改造过程中，跑批压测发现随着并发的增大，路由处理的速度会急剧下降，单批路由（1000笔/批）的速度为10s左右，但压测过程中，单批路由的速度下降到120s+，这个速度显然是不可接受的。
鉴于目前的问题，在单批发送性能正常，压测多批并发发送性能下降。首先想到的是内存不足导致的FGC频繁引起的性能下降。
验证思路：
关注GC情况，发现在处理过程中,FGC次数并没有上涨，YGC频率大概为1次/每秒。GC情况并无异常，具体GC频率见下方：
根据上述的应用日志，发现在2018-10-25 19:22:09.495~2018-10-25 19:22:09.559时间段，drools规则引擎执行花费了64ms（正常情况下应该是小于1ms的）
检查该时间段的GC日志，并无CMS GC日志，只有一些YGC日志，YGC执行速度很快，不是引起性能较低的原因。
根据以上的GC分析，认定了 性能的降低与垃圾回收无关 。
在进行GC排查时，抽样了应用日志，发现StatefulKnowledgeSession的创建速度并不稳定，并发上去后，StatefulKnowledgeSession的创建速度会变得越来越慢，最高甚至达到100ms+的消耗。
写了一个测试类，模拟测试环境不停的进行session创建，并使用jprofiler工具进行监控，发现session创建的耗时在于Class.forName的反射上。如下图所示：
要加快StatefulKnowledgeSession的创建速度，那么就要避免每一次创建都去进行Class.forName的 *** 作。两个方案：
以上的两个方案实际并不友好，虽然提高了StatefulKnowledgeSession创建速度，但“provider为空的情况下创建的ksession”这个逻辑已经在线上验证过一段时间，现在为provider赋值，不知道会不会引起其他的逻辑BUG，所以 此方案放弃
基于以上两点分析，决定采用此方案进行性能优化，StatefulKnowledgeSession池的维护使用Apache旗下的common-pool2的开源工具类实现。common-pool2的使用此处不在赘述，仅说下几个要点：
通过方案二的处理，目前在相同运行环境下，压测每批交易的路由执行速度均能稳定在10s以内。
drools5的官方推荐使用方式，StatefulKnowledgeSession都是新new出来的，但在此我们使用的是共享session方式来解决性能问题（有局限性，需要结合自己业务规则），也算是一个新的解决问题的思路。记录一下，也希望能够帮到大家
付又称付出、付给，多指付款，是发生在购买者和销售者之间的金融交换，是社会经济活动所引起的货币债权转移的过程。支付包括交易、清算和结算。”从上述定义可以看出，一个完整的支付流程是由三部分组成的，分别是交易、清算和结算。
大多数人眼中的支付其实就是交易，可以看成是狭义的支付。比如我们用微信扫码付了款，我们会认为这是支付。
确实，对于用户来说，我已经付钱了，这笔交易便完成了，所以笔者认为，我们也可以把这个交易动作当成是支付，问题不大。
但如果你是支付行业或者与支付行业有关联的从业者，仅仅认识到狭义的支付，肯定是不够的，我们还需要进一步了解支付背后的清算与结算。
这就涉及到两个新的概念，信息流与资金流。
在一个完整的支付过程中，交易动作或者说是支付动作，代表的就是信息流。而清算则代表资金流。
清算其实是两个动作，先是清分，然后结算。
通俗来说，清分就是在用户完成支付动作后，清楚的算出谁付谁多少钱，谁欠谁多少钱，最终得出谁该付谁多少钱的。
而结算就是根据清分的结果，进行执行，并发生资金的实际划拨。
下面我将举两个例子来让大家了解信息流与资金流是怎么在一个完整的交易流程中体现出来的，分别是POS机线下收单与第三方支付机构线上收单。
01 线下收单
一般指POS机收单，即收单机构向签约商户提供的本外币资金结算服务。
通俗来讲就是收单机构为特约商户安装POS机具，持卡人在特约商户进行购物消费时通过刷卡方式支付款项，收单机构负责将扣减一定手续费后消费资金记入商户账户。
以你在星巴克刷卡消费为例：
持卡人：你自己
发卡行：给你发这张卡的银行，假设是农行
特约商户：与收单行签有商户协议的组织，比如星巴克
收单行：星巴克刷卡机的归属行，假设其在建行开设结算账户
转接机构：负责发卡行与收单行的信息传递，也就是银联
清算机构：负责信息清分与资金结算，也就是银联与央行
当你用农行卡在星巴克刷卡消费时，资金流与信息流如图：
图片
简单介绍整个流程：
1、你在收单行（建行）的POS机上刷卡消费（信息流）
2、建行将消费信息发送给银联（信息流）
3、银联记录交易数据，将消费信息给你的发卡行（农行）（信息流）
4、农行从你的卡中实时扣费，完成实时结算，并通知银联（资金流）
5、农行发送消费扣款短信给你，提醒余额减少（信息流）
6、银联更新交易数据，通知建行的POS机已完成扣款（信息流）
7、日终后银联在其清算系统完成清分，先把账算好（信息流）
8、清分完毕后，银联通过央行的清算系统，完成农行与建行清算账户的资金划拨（跨行清算）（资金流）
9、进行银行内部结算，完成建行和星巴克结算账户的资金划拨（收单清算）（资金流）
在这个过程中，银联提供两种清算：
建行和农行的清算叫“跨行清算”，一般为T+1日凌晨。
建行和星巴克的建行账户之间的清算叫“收单清算”，在跨行清算之后。
02 线上收单
一般指第三方支付机构（包括银联）的提供无卡化电子支付服务，持卡人通过互联网、移动互联网等介质，输入yhk相关信息从而完成交易，并实现资金的清结算。
通俗来讲就是消费者通过第三方支付平台完成支付，收单机构（即第三方支付机平台）收到资金后结算给对应的商户。
以你在每日优鲜通过在微信支付绑定的农行卡消费为例：
图片
简单介绍整个流程：
1、你在每日优鲜上通过微信支付的农行卡支付订单（信息流）
2、第三方支付平台将消费信息发送给网联（信息流）
3、网联记录交易数据，将消费信息给你的发卡行（农行）（信息流）
4、农行从你的卡中实时扣费，完成实时结算，并通知网联（资金流）
5、农行发送消费扣款短信给你，提醒余额减少（信息流）
6、网联更新交易数据，通知第三方支付平台（微信）已完成扣款（信息流）
7、第三方支付平台（微信）通知商户平台（每日优鲜），支付成功（信息流）
8、每日优鲜通知你订单已支付成功（信息流）
9、日终后网联在其清算系统完成清分，先把账算好（信息流）
10、清分完毕后，网联通过央行的清算系统，将收单金额结算给第三方支付平台的备付金银行账户。（资金流）
11、第三方支付平台（微信）按照一定的结算周期（一般为T+1）结算资金给每日优鲜在微信开设的虚拟账户。（信息流）
12、商户平台可通过自动或者手动的形式，将资金提现到实体yhk。（资金流)
支付相关的基本概念
支付方式
支付方式可以简单定义为用户在消费时，支付商品金额的方式，它是针对支付种类特性的一种归类。比如你在京东进行购物时，可以选择使用微信支付、云闪付、Apple pay、yhk快捷支付、白条支付。
支付渠道
支付渠道是钱走的路，即资金转移的通道。
从第三方支付公司的角度出发，支付渠道有网联、银联、直连银行、或者其他第三方支付等渠道。
从支付平台类电子商务公司的角度出发，支付渠道有第三方支付平台、银联、直联银行。例如：微信、支付宝、苏宁支付对于电商平台来说，都是可供选择的支付渠道。
从银行类平台（银行、银联、网联）的角度出发，支付渠道有人行的大小额系统、超级网银系统。
支付路由
有句话说“条条大路通罗马”，理论上没错的，但是每条路的通勤成本可能都不一样的，支付路由的作用就是根据各种因素的综合考虑，整合并提供最优的支付渠道。它考虑的因为包括但不限于支付渠道的稳定性、费率、限额、卡类型、卡银行。
银行底层接口
最底层的银行接口指的是银行、银联和网联提供的技术接口。支付机构的各种支付方式均是对银行底层接口的直接利用或者二次包装。
底层接口包括POS收单接口、网关接口、快捷支付与代扣接口。按应用场景可划分为线上与线下。
线下场景主要使用POS收单接口：
是银行开放给第三方支付机构用于线下收单业务的，主要用于pos机刷卡支付。
线上场景主要使用网关接口、快捷支付与代扣接口。
网关接口：第三方支付公司作为代理（网关），接入银行。用户选择银行后，跳转到对应的银行网银系统完成支付。比如在京东web端支付订单，收银台可选择个人网银或者企业网银支付。
快捷支付：快捷支付针对小额支付的需求场景，简化了授权过程（例如只需要完成持卡人yhk、身份z、手机号的实名认证即可），同时通过下行短信验证码的形式来完成消费确认。
代扣：代扣一般指用户通过线上或线下柜台方式签署“用户-商户-银行”的三方协议，授权商户可以从其银行账户中扣钱。实现用户资金向商户的定向划转。一般用于保险扣费、水电费缴费、消费信贷还款等场景。
中国银联
中国银联（China UnionPay）成立于2002年3月，是经国务院同意，中国人民银行批准设立的中国yhk联合组织，总部设于上海。
核心职责，建设和运营银联跨行交易清算系统（CUPS）并以该系统为依托，推广统一的yhk标准规范，为商业银行、特约商户、持卡人提供便捷yhk支付收单业务。
银联的业务重点侧重线下，在线下收单业务基本处于垄断地位，比如pos机收单与ATM业务均要通过银联完成统一的清算。
中国网联
网联清算有限公司，成立于2017年8月， 是经中国人民银行批准的非银行支付机构网络支付清算平台的运营机构，也称线上版银联。
具体则是指为支付宝、微信这类非银行的第三方支付机构搭建的一个共有的转接清算平台，处理第三方支付平台与银行交互的支付业务。该平台受央行监管。
网联出现的背景？
在网联出现之前，第三方支付此前普遍采取的是直连银行模式来进行资金的转接清算。如下图：
图片
支付机构通过在多家银行开设备付金账户实现资金的跨行清算，变相具备了清算职能。
这种模式绕开了央行的清算系统，使银行、央行无法掌握具体交易信息，无法掌握准确的资金流向。
同时也给反洗钱、金融监管、货币政策调节、金融数据分析等央行的各项金融工作带来了很大困难。
举个例子，在直连模式下，你在淘宝上购物，通过支付宝上绑定的农行卡进行支付，同时卖家的结算账户绑定了建行的卡。当你支付成功时，你在农行的钱会从你的yhk划扣入支付宝在农行开设的备付金账户，当你确认收货，交易成功时，支付宝会通过其在建行开设的备付金账户，将资金划入卖家的建行卡。
在这种情况模式下，央行无法掌握完整的资金链路，相当于是把央行架空了，这肯定是不被允许的。
网联的出现从根本上断了第三方支付平台的直联模式，所有的支付机构必须统一接入网联，由网联统一对接各个银行机构。如下图：
图片
为了让支付公司快速的接入网联系统，央行规定：
1. 所有交易必须通过网联进行清算。
2. 备付金全部集中存管，存放到人行。
3. 同时停止支付备付金利息。
作为唯一两家大型具备合法资质的清算机构，银联和网联扮演的角色并不相同。银联主要占领线下市场，而网联负责第三方支付线上与各家银行之间资金清算的职责。
不管是银联还是网联，本质上都是提供交易转接、清分和对账，最终银联跟网联都要通过央行的清算系统完成结算。
中国人民银行
中国人民银行，简称央行，是中华人民共和国的中央银行。
中国现代化支付系统（CNAPS）
主要提供商业银行之间跨行的支付清算服务，是为商业银行之间和商业银行与中国人民银行之间的支付业务提供最终资金清算的系统。
最开始央行的CNAPS一代系统包括，大额支付系统与小额支付系统。
2013年，央行的CNAPS二代系统投产运行，其中就包括超级网银系统，是对大小额支付系统的一个补充。
大额支付系统
全称为大额实时支付系统，简称HVPS，用于处理同城和异地跨行之间和行内的大额贷记及紧急小额贷记支付业务。
开放时间：工作日的 8:30 ~ 17:00
金额限制：无，一般银行会以5万为边界，大于5万走大额系统，小于5万走小额系统
到账时效：实时发送交易，实时清算，资金基本能够实时到账
小额支付系统
全称小额批量支付系统，简称BEPS,是对大额支付系统的一个补充。
开放时间：7*24小时
金额限制：单笔金额上限5万元
到账时效：批量发送，定时清算，所以有些银行的转账可能要5分钟到1个小时内到账
超级网银系统
全称网上支付跨行清算系统，俗称超级网银，是对大小额支付系统的一个补充，有两大亮点：
接入机构不再限于银行。支付宝、微信支付等第三方支付也可以接入
7*24小时实时到账，单笔上限5万元。在非工作日非营业时间也可使用
支付
狭义上，支付可以认为是用户通过银行类平台或者第三方/四方支付平台，使用yhk进行付款的过程。
代付
即付费企业在提供收款人（企业或个人）相关账户信息以及对应款项后，完成向目标账户划款的业务模式，一般用于余额提现、交易结算等场景。
清算
清算，包括清分与结算。
清分——
指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？
结算——
从商户与收单机构（第三方支付平台或银行）的角度出发，结算即交易完成后，收单机构根据清算结果将资金划入卖家账户的过程。这一过程的背后又依赖着银行与银行之前的结算、银行与收单机构之间的结算。
备付金
关于客户备付金央行给出的定义是这样的：
“客户备付金是指支付机构办理客户委托的支付业务，实际收到的预收代付货币资金。”
比如你通过支付宝上的农行卡完成了淘宝订单的支付，资金不会先进入卖家账户，而会先进入支付宝在银行开设的备付金账户，第三方支付平台无法直接接触资金。央行规定支付机构的备付金需要全额上交央行监管。
备付金账户
顾名思义，就是用来存放备付金的银行账户了。
2018年6月29日，央行发布《关于支付机构客户备付金全部集中交存有关事宜的通知》的特急文件，通知决定，自 2018 年 7 月 9 日起，按月逐步提高支付机构客户备付金集中交存比例，到 2019 年 1 月 14 日实现 100%集中交存。
这意味着，原来支付机构散落在各家银行的客户备付金账户将被销户，转而变成在央行开立备付金集中存管账户，支付机构的客户备付金将由央行直接进行监管。
入金
在对接第三方支付平台或者银行系统的时候，必定会接触入金这个名词。
入金，所谓的金，指的是资金流，也就是你通过第三方支付机构实现将yhk资金转入第三方支付机构的备付金账户，并完成虚拟账户入账的过程。
最典型的入金业务是充值，当你在微信上使用农行卡充值时100元时，你的农行卡会实时扣款100元，这笔资金会通过清算系统进入微信在银行开设的备付金账户，同时，你会看到你的零钱余额新增100元，完成入金流程。
出金
与入金相反的业务就是出金，也就是你通过第三方支付机构实现虚拟账户扣账，并通过备付金账户向你的实体yhk转账的过程。
最典型的业务就是提现，当你微信上将零钱提现时100元，零钱余额扣减100元，同时微信的备付金账户会转100元进入你的yhk，完成出金流程。
T+1/T+0、D+1/D+0
出金之后什么能到账呢？下面对几个概念做简单介绍。
T+1为第二个工作日到账；
T+0为当天工作日到账；
D+1为第二天到账（包含休息日，节假日）；
D+0为全年当天到账（包含休日，节假日）。
发卡行
发卡行是向持卡人（即用户或消费者）发行各种yhk，并通过提供各类相关的yhk服务收取服务费，是yhk市场的发起者和组织者，是yhk市场的卖方。
收单机构
包括第三方支付机构与银行机构，负责特约商户的开拓与管理、授权请求、账单结算等活动，其利益主要来源于特约商户交易手续费的分成、服务费。
收单行
负责对分发请款指令，同时存管用户备付金的银行。即用户付款后，需要有一个银行账户来存放用户所支付的资金，该备付金存管银行就是收单行。
特约商户
特约商户，是指与收单机构签订yhk受理协议、按约定受理yhk并委托收单机构为其完成交易资金结算的企事业单位。
关于以银联、网联为核心的支付与清算流程简介，同时对信息流以及资金涉及的支付行业相关概念介绍，本文暂时介绍到这里。
支付清算是一个极其复杂的系统，以上分享源于本人在对接第三方平台与银行系统的经验总结以及前人的经验分享，欢迎随时交流探讨。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）