支付域——清结算系统体系

news2024/12/23 5:43:04

摘要

本文深入探讨了支付清算的基础知识和跨机构清算原理,涵盖了组织、账户、支付工具和系统的基础,支付流程的模型,以及支付清算的全局实现。文章还详细介绍了支付机构的五大业务和支付系统的总架构,并通过案例分析了支付清算的具体流程。

支付,是一个巨大工程,由众多机构和组织共同完成,这些组织包括了:提供服务的交易平台、提供支付服务的支付机构、提供清算网络的清算机构、提供金融基础的商业银行、提供支付基础的央行大小额等二代系统;他们之间通过系统网络、账户网络等共同构成了现代支付体系;当然还包括一些支付外包服务商、各类支付终端制造商、软件服务商以及检测机构。

以及在这样复杂的支付信息流网络中,各机构内部的交易、支付、清算、结算等的详细的逻辑处理流程。

这么多组织的众多系统之间在内外构建起来了一个支付清算网络,通过各种各样的渠道和模式形成一个庞大的支付网络,将他们链接到一起,就像一个个的王国之间的贸易往来一样,宏大而繁荣。

1. 清算基础

用户使用一定的支付工具,例如银行卡、支票、网络支付或者移动支付等,在某个业务场景中,发起了一笔支付,这笔支付经过众多支付参与者的支付系统处理之后,到达央行的清算账户,完成最终的资金清算。可以将这个过程,高度抽象成一个宏观框架,如图所示,从图中可以清晰地看清楚整个生态网络。

1.1. 组织基础

这么庞大的支付网络,离不开众多支付组织的支撑,每个支付组织都承担着相应的“支付职能”。

1.1.1. 交易平台提供交易场景

可以说所有支付都在某个场景下依赖一个“支付的原因”而发生,例如饿了要买包子,那么,包子铺就是交易场景,饿了就是支付的原因;双11线上抢购,电商平台就是交易场景。

交易平台为商家和用户提供交易场所,提供商品或者服务,撮合买卖双方,这是进行支付的基础,无交易不支付,当然,也可能存在纯支付行为,例如捐款。

1.1.2. 支付机构提供支付服务

三方支付机构的出现提高了整个支付行业的支付生态,为社会提供了成本更低、效率更高的各类创新型产品,例如快捷支付、扫码支付、聚合支付等等。

交易平台要进行收付款离不开支付机构,支付机构通过提供各类收付支付解决方案为交易平台提供支付服务,例如微信支付、支付宝支付、聚合支付等等所提供的小程序支付、H5支付、App支付等;根据提供支付服务环节的不同,可以将支付机构分为收单侧和账户侧。

收单侧: 为商户提供快捷、网关、聚合、POS等收单服务的支付机构,商户可以通过接口或者页面的形式接入收单机构的支付服务。

收单侧,以为服务商户,为其提供收款通道为主要特征,所以以商户入网为服务起点,签约相应支付产品或者解决方案,由商户提供给其客户进行收付款、充值、提现等支付服务。

账户侧: 账户侧支付机构为用户提供付款需要的“资金账户”,以微信和支付宝为主,还包括和钱包、壹钱包等机构,为用户提供零钱账户即支付账户;通过与银行卡进行绑定实现银行结算账户与支付账户的链接,通过充值增加账户余额,通过提现可以将余额提至绑定的同名银行结算账户。

用户在向商户付款时,可以直接使用零钱余额进行支付。

当然,因为各支付机构之间渠道不通的因素,账户侧的付款场景受到极大的限制,例如微信账户的资金当前无法通过易宝支付的收款服务进行付款;不过,个别支付机构之间也在逐渐实现打通,例如京东支付和微信支付在商户收款码和用户付款码的双通。

账户侧以服务用户,提供零钱账户为主要特征,以用户实名鉴权进行开户为支付服务的起点。

1.1.3. 清算机构进行跨机构信息转接

当支付业务需要跨机构进行交易转接和资金清算时,需要依赖清算组织实现,虽然在之前非银支付机构可以直接接入银行通过多头开户,利用在商业银行开设的备付金账户进行跨机构资清算,但是为了更好的金融监管和支付安全,现已实现断直连通过网联一点接入。

清算机构根据于服务的对象和业务不同又可以划分成多种,例如银行卡收单和跨行清算通过银联实现;非银机构和商业银行之间通过网联实现(银联也可以);以及为城市商业银行提供跨地域清算服务的城银清算服务有限公司;还有农信银资金清算中心为农村信用社、农村商业银行、农村合作银行等农村中小金融机构提供资金清算服务。

本文将重点介绍网联和银联清算机构的业务,他们实现三方支付机构之间,银行之间,三方支付机构和银行之间的交易转接和资金清算服务。

整体来看,断直连后的网联和银联主要有2大处理模块,处理支付指令的支付清算平台和进行清算资金处理的备付金前置系统。

支付清算平台

支付报文清算平台,实时处理支付机构提交的收付请求报文,并转接给收付款行,同时通知前置模块进行账务处理,可以把这个平台看成是“支付系统”,主要处理清算指令。

备付金前置系统

简单来讲就是央行支付系统的前置系统,为啥要做这一层,为了避免高并发而造成央行系统形成热点账户,从而造成较大的系统压力,而带来隐患。为啥会形成热点呢?在直联时代,支付机构的交易分散到了各个商业银行,以及众多的备付金账户中;断直连以后集中存管到央行的ACS-备付金集中存管账户,交易都提交央行,势必会造成巨大的交易并发,进而形成备付金账户热点。

该前置系统主要就是为了解决备付金集中存管后所形成的热点账户问题,并在清算过程中承担机构清算资金的账务处理职能,可以把这个模块类比成“账务系统”。

这个模块最基本的账户逻辑就是上述的恒等式,其中最主要的三个概念含义和用途如下:

  1. 映射额度:因为付款需要基础的可用额度,在清算场次刚开始并没有收款做为付款基础时,需要将备付金资金映射给网联或者银联、做为清算的基础,也就想调拨一笔钱到账户里,为即将开始的清算业务备用;只不过这个不是真实资金,只是一个额度;就像我们将自己微信零钱里的钱通过亲属卡授权给自己的家人一样,家人的那个额度就是虚拟额度;后面会详细介绍这个额度的申请和管理。
  2. 收付发生额与净额:清算场次内,支付机构提交收款指令和付款指令,从而形成了收付金额,以及收付净额,这个净额即清算场次内的收支发生额之差;代表着本次清算周期内是净流入还是净支出。
  3. 可用额度:可用额度是可以用于付款的账户余额;是映射额度和收支发生净额的总和,这也是可以用于付款的最大金额。

1.1.4. 银行提供基础金融服务

支付需要钱,最原始的钱在哪里,在银行,在银行的结算账户当中;银行为社会提供最基础的金融服务,是支付服务的最主要提供方。

从业务分类上来看,银行业务可分为存、贷、汇三大业务;其中存款就是用户存钱的业务,而贷款就是用户借钱的业务,而汇就是支付结算业务;有钱存到银行用,没钱从银行借,有了钱以后进行支付。

而支付就需要各类支付工具和结算方式,例如银行卡、票据、汇兑、托收承付、网络支付、移动支付等

以上业务都离不开相应的业务系统做支撑,存款系统、信用卡核心系统、客户账户系统、会计系统等等,而跟支付结算相关的系统主要是两个。

支付的两大处理就是清算指令处理和资金处理,分别由支付系统和账务系统完成;从各交易平台、清算机构、央行等组织内的系统建设也可以看出来,信息的处理和资金的处理都是分开进行

1.1.5. 银行支付系统

银行支付系统通过交易处理实现各联机交易业务,并推动账务核心完成客户账户的动账操作。

可以实现所有外围系统(如柜面系统、ATM、网银等)的业务请求;以及来自网联银联转接的外部机构的清算指令,行内客户操作的转账、充值、提现等支付请求;实现清算业务、结算业务、代理收付、转接与转发等等。

1.1.6. 账务核心系统

就是登记内部账、表外账、通用记账、会计总账、计提与损益、客户账等等账务的系统,用户的钱放在这里,可以实现支付结算、存款、转账等支付业务的用户银行账户的账务处理。

1.2. 账户基础

现代电子支付或者非现金支付离不开各类账户的参与,而因为支付体系中存在众多机构参与者,因此也必将存在种类繁多的资金账户;要想悟透支付,参透账户体系非常重要。

从不同的视角看,账户有不同的分法;例如从财务视角看账户的要素属性,账户可分为资产类、负债类、所有者权益类、损益类、共同类等。

因为要研究支付,所以我们更关注跟支付相关的账户,也就是跟货币-银行存款相关的账户,这类账户又可以从账户用途和机构归属去划分。

从账户用途的角度去划分,在整个清结算链路上可以将账户划分为“存款账户、中间过渡户(清算往来、已清算、待结算)、客户虚拟账户等。

从机构归属的角度去划分,又可以分为央行清算账户、银行结算账户、支付机构支付账户、普通企业虚拟账户等;而每个机构的账户又可以进行二次多级分类,例如银行账户又可以分为个人结算账户、企业结算账户;支付机构的账户可以分为个人支付账户、企业支付账户;而银行个人结算账户又可以分为一二三类户等等。

而金融监管的本质实际上就是对不同的机构的不同账户分类进行个性化监管,例如银行的个人结算账户和单位结算账户分别适用于不同的监管条例;而个人结算户的一类三类户又拥有不同的账户交易权限。

这样的账户体系,支撑起了如此庞大的支付清算体系,使得各类资金在不同机构、不同账户之间进行流转,也在这样庞大的账户体系之上,使得现代支付成为可能。

1.2.1. 清结算5类账户原理

从功能上可以将账户分为如下5类:客户账户、结算过渡户、清算往来户、已清算应收付账户、XX存款户;各类机构会基于实际情况选择设定这5类账户中的一种或者多种用于自己的清结算业务。

不同的机构这5类账户的性质会有所不同,客户的账户就是我管别人的钱,而XX存款就是我的钱被管在XX那。

例如:对于银行来说客户账户就是个人或企业结算账户属于资金账户,而存款多指在央行的存款或者在其他金融机构开立的存款账户;而对于支付机构来说,客户账户就是支付账户,而存款多指在央行的备付金存款账户。

同样清算往来关系登记的也有差别,支付机构的清算往来是指与网联银联的往来;而交易平台的清算往来指的是交易平台与支付机构的支付往来等等。

有了这个基本原理的认知,那再理解各类机构的账户设定就容易理解多了。

1.2.2. 支付机构支付账户

支付账户可以分为个人支付账户和企业支付账户;该账户实际上是一种虚拟记账账户,真实的资金存放在央行。

而企业支付账户多是用于登记其商户的代收预付的款项,最终会结算至企业绑定的同名银行单位结算账户中。

而个人支付账户主要是用于零售消费使用,可以通过绑定的个人银行结算户进行资金充值,同样也是一个虚拟记账账户,真实的资金存放支付机构在央行的备付金账户中。

1.2.3. 银行结算账户

银行结算账户也就是我们所熟悉的银行卡的底层账户基础;可以分为个人结算账户和单位结算账户。这类账户是整个社会的金融基础,个人存款、消费等的资金存放处。

1.2.4. 央行机构备付金及清算账户

央行的账户与支付比较密切的就是三方备付金账户以及银行和网银联的清算账户;跨机构支付清算在这些账户之间完成最终的资金清算。

1.2.5. 清算机构清算虚拟账户

断直连以后,网银联为支付机构在其前置系统内开设清算用途的虚拟账户,用于央行备付金的映射管理、机构间清算往来登记、可用额度管理等等职能。

这里的所有余额都只是虚拟记账,是机构间交易的清算结果,真实的资金存放在各机构在央行的备付金账户中,只有在结算场次将各机构的清算净额提交央行完成最终清算以后,央行备付金余额才会发生变动。

1.3. 支付工具基础

有了不同的组织,建立了不同的系统,开设了不同的账户,但是万事俱备只欠东风,账户是看不见摸不着的,怎么去转移账户里的资金——支付工具。

用户发起支付离不开各类支付工具,因为钱都在账户里,而请求支付就需要发“信号”,用什么发,就是支付工具,比如银行卡刷卡发信号、支票等等。

支付工具是传递收付款人支付指令,实现债权债务关系清偿和资金转移的载体。所以说支付工具是一个载体,用于传递支付指令,就如银行卡就是支付工具,其本身并不是货币,只是作为工具发起资金转移的支付请求。

为了满足不同场景下的支付需要,产生了不同种类和用途的支付工具,比如我们坐公交使用的公交卡就是支付工具,替代了人工投递实物货币,大大提升了乘车的支付效率,我们可以回忆一下在没有公交卡之前,我们遇到过多少次因为没有零钱或者排队买票而出现的不便。

支付工具可以划分为现金支付工具和非现金支付工具;

  • 现金支付工具就是我们的纸币了,非现金支付工具我们可以称其为新型支付工具,更多的是以账户货币为基础,用于高效转移账户货币资金的工具。
  • 最常见的有卡基支付工具,包括银行卡、信用卡、预付卡,票据支付工具,包括支票、汇票、本票,如表中罗列了常见的支付工具。

这里要特别说一点,支付工具和支付方式的区别:支付工具是资金的载体,支付方式是支付工具的使用形式。

例如银行卡是支付工具,刷卡,绑卡快捷支付,银行卡代扣等都是支付方式,都是建立在银行卡支付工具之上;就像汽车是出行工具,打车、乘车、拼车、开车等是出行方式。

1.4. 支付系统基础

现代支付离不开账户,当然也离不开各类处理数据和收发信息进行通讯的现代化信息系统。

前面的组织基础部分介绍了各个组织的一些系统,整体来看我们应该掌握系统建设的最基础分类理念和建设方法。

1.4.1. 支付系统分类

一个企业或者机构的支付清算系统建设大体可以分成3大范畴;每类系统承担不同的事务处理;不同机构可以有选择性的集成和拆分,例如人行将支付系统拆分成大额、小额、超级网银三大系统。

但无论多少系统,最核心的系统层从宏观层去看都可以归集为3类的大处理:交易信息的处理、支付指令的处理、资金的处理;如网联有支付清算平台EPCC来处理支付指令,而前置系统RCMP来处理账务信息(机构的各类余额)。

1.4.2. 交易系统

这是处理业务的系统,商品服务的选购及订单、账单的生成,这是支付的前置事项;有了交易才会有后面的支付,不然,要支付什么?这也就是我们前面所说的“交易场景”,交易系统在电商类企业非常重要,是对交易场景的分类处理。

而在支付机构的交易层,更多会以支付业务种类进行交易模式的划分,例如收单交易、打款交易、充值交易、提现交易、鉴权交易等。

1.4.3. 支付清结算系统

这是支付指令生成的处理系统,支付多少钱、用什么方式支付等等信息的处理;对外要将支付指令提交给渠道进行资金清算,对内要将支付指令提交给账务进行内部账务登记;可以将该系统一分为二:“支付清算系统”对外,“清结算系统”对内,共同实现全链路的支付业务。

1.4.4. 账务核心系统

这是管理各类账务和账户的系统,不同机构的账务系统的架构存在很大差别,管理的账户种类和适用于的监管条例也不同,例如支付机构的账务系统主要管理支付账户,银行的账务系统主要管理结算账户等,而网联的账务模块管理机构的虚拟账户等等。

1.4.5. 系统间的通讯模式

这么多组织的众多系统之间在内外构建起来了一个支付清算网络,通过各种各样的渠道和模式以及技术手段进行链接和通讯。

直接对接的叫直联,例如交易平台直接接入微信支付;通过中间机构转接的叫间联,例如支付机构通过清算机构与银行进行通讯。

1.5. 清算的模型基础

就是上面我们讲的那么多组织、系统、账户、工具,要以什么样的“规矩”运转起来;我们把这种运转规矩或者说模型划分成几个维度去看。

1.5.1. 支付流程划分的模型

可以依据信息内容的不同将整个支付链路划分成三大部分,交易、清算、结算,其实就是“业务流、账务流、资金流”。

其中交易环节是对支付发起者的支付原因、身份、支付工具等一系列支付前置事项的确认过程;清算是对支付指令的生成、清分、发送、接收的处理过程;而结算是对本次支付的实际资金的处理过程。

在这个过程中形成了业务流、账务流、资金流;也就是经济活动的登记、账务的登记、资金的划付。

1.5.2. 清算分阶段执行的模型

支付从发起到结束在几秒内经历了一个漫长的链路,涉及到众多的处理环节,将这些环节的边界拆分清楚是设计好支付清结算系统的关键;这些环节可以分成2大类7个环节。

  1. 4个主线支付环节:支付交易、渠道清算、渠道结算、商户结算;
  2. 3个差错处理环节:客户差错、支付差错、资金结算差错。

其中每个环节关注的内容会有差别,例如支付交易环节是支付指令的提交和结果接收环节,如果是跨机构交易,就会涉及到与网银联的通讯,网银联将支付请求转发给收付款行的过程,该环节是后续6大环节的基础,如果该环节失败,那便没有后续的环节了。所以,每个环节我们可以单独去分析,这样有利于研究清楚该环节的机制。

1.5.3. 多层清结算模型

正因为一次支付需要众多组织的参与,就意味着,每个组织内部都有一套清结算处理机制,他们相互独立又存在关系,理解这一点非常重要。这种多层的清结算模型,依赖各类账户的账务处理,在账户基础部分介绍了这种庞大的账户矩阵。

跨机构的支付清算,在每一层机构内的处理时效存在错配,例如网联和支付机构以及银行对客户的账户是实时进行处理的,支付结果几秒内就得到了;但是机构之间的账务处理往往是分场次进行的,就如支付机构T+1给商户进行结算,而机构之间在人行要一天内结算一个或者多个场次。

至于选择几个场次,这跟清算系统的处理能力,实际的经济效益关系,能力越强、市场对清算时效要求越高,设立的场次就越多。

在这样的机制下,彼此的信任至关重要,机构之间相信对手方一定有足够的资金和信用进行资金的兑付;例如收款行已经增加了收款人账户余额,其实此时收款行可能并没有收到付款行的资金,一切都是基于信任,这类收款业务对于收款行来说存在信用风险,比如收款人把钱取走了,而付款行倒闭了,虽然概率极小,但依然存在可能!

1.5.4. 不同清算模式的模型

根据实际清算需要,可以选择不同的清算模式,例如实时全额清算,延迟净额清算;大额支付多选择实时全额,一般金额较大,对资金时效性要求较高;而高频小额的零售支付,多选择延迟净额清算,又可以分为双边净额和多边净额。

实时全额清算延迟净额清算延迟全额清算 都是不同的清算方式,特别是在金融和支付领域中,它们指的是在不同时间点、不同计算方式下完成的交易清算。

实时全额清算 (Real-Time Gross Settlement, RTGS)

定义:实时全额清算(RTGS)是一种支付清算方式,指的是在交易发生时立即对交易进行清算和结算。这意味着每笔支付都立即以全额方式结算,不存在延迟。

特点:

  • 全额结算:每一笔交易都会被单独结算,结算金额不被净化或汇总。没有"暂时欠款"或"对冲"。
  • 实时处理:支付和结算在交易发生的同时进行,不存在延迟。
  • 高流动性需求:由于是全额清算,这种方式要求银行系统或支付系统必须有足够的资金或信用来完成每笔交易。
  • 风险较低:由于即时结算,减少了交易对手风险。

适用场景:

  • 高价值、重要的金融交易,如银行间大额支付。
  • 政府机构和大型金融机构之间的资金转移。

举例:如果公司 A 向公司 B 转账 1,000,000 元,在使用实时全额清算系统时,系统会立即将这 1,000,000 元从公司 A 的账户转到公司 B 的账户,且交易一旦完成就不能撤销。

延迟净额清算 (Deferred Net Settlement, DNS)

定义:延迟净额清算是指在一定时间内,多个交易会先暂时“冻结”或“记录”,不立即进行结算,而是将所有交易的净额(即差额)进行清算。系统会在一定周期(如一天、每小时等)之后对所有交易进行净额清算。

特点:

  • 净额结算:所有交易会先被累计计算出一个净额,只有该净额会被清算,而不是每笔交易的全额。
  • 延迟结算:结算并不是实时的,而是在一个预定的时间点或者周期后进行,通常是几小时或一天结算一次。
  • 资金使用效率高:因为采用了净额结算,同一期间内的相互交易会进行对冲,减少了需要结算的总额。
  • 风险较高:延迟结算会增加交易对手的信用风险,尤其是当一方无法履行结算时,可能会影响所有交易。

适用场景:

  • 小额支付系统或者日常的银行间交易。
  • 证券、期货等交易市场的结算。
  • 适用于交易量较大但单笔金额较小的支付系统。

举例:假设公司 A 向公司 B 转账 100 万元,之后公司 B 向公司 A 转账 50 万元。在延迟净额清算中,系统不会在每笔交易发生时立即结算,而是在结束时计算净额,例如两者的净额为 50 万元,系统在结算时只需要转移这一部分净额的资金,而不是每笔交易的全额。

延迟全额清算 (Deferred Gross Settlement, DGS)

定义:延迟全额清算是指每笔交易都需要在结算时全额结算,但结算是延迟的,而不是实时进行。即每笔交易在发生时并不立即清算,而是在一定的时间周期内进行全额结算。

特点:

  • 全额结算:与实时全额清算类似,每笔交易都需要结算其全额。
  • 延迟结算:结算不是即时的,而是延迟至某个周期(例如每天结算一次)。
  • 资金流动性要求高:由于每笔交易都需要全额结算,延迟清算仍然要求有足够的资金支持。
  • 相较于延迟净额清算,风险较低:因为每笔交易都是全额结算,不存在净额对冲的风险。

适用场景:

  • 适合需要确保每笔交易全额清算的场景,但结算可以延迟的情况。
  • 比如一些跨国交易的清算系统,或者一些支付系统的结算。

举例:如果公司 A 向公司 B 转账 100 万元,而公司 B 向公司 A 转账 50 万元,在延迟全额清算的模式下,系统将在结算周期(比如一天后)进行清算,此时仍然会对每笔交易进行全额结算,而不仅仅是净额。

清算方式

结算方式

特点

风险

适用场景

实时全额清算 (RTGS)

全额结算,实时

每笔交易立即全额结算,资金实时流动,减少对手风险

风险较低

高价值、大额交易

延迟净额清算 (DNS)

净额结算,延迟

多笔交易累计后结算净额,延迟结算,提高资金效率,可能增加对手风险

风险较高

小额支付,银行间支付

延迟全额清算 (DGS)

全额结算,延迟

每笔交易全额结算,但结算延迟,资金流动性要求较高

风险较低

大额跨国交易,支付系统

总结

  • 实时全额清算提供即时清算,适用于大额和高价值的交易,确保交易的即时性和资金安全。
  • 延迟净额清算适用于小额和大量交易的系统,通过计算净额提高资金效率,但风险相对较高。
  • 延迟全额清算结合了全额结算和延迟结算的特点,适合需要全额结算但能够接受结算延迟的场景。

全额清算指在资金转账前并不进行帐户金额的对冲,以实际的支付金额进行转账的清算方式。比如我要给你100,你要给我50,全额结算下我先给你100,你再给我50,发生了2笔转账。

净额清算及根据清算对手之间的支付往来进行正方向冲抵以后,将净额部分进行一次性清算,双边净额是两两之间进行;而多边清算是将整个清算范围的所有参与者的收付情况进行整体计算每个参与者的净额,净收金额,净付金额,然后先借记全部净付方以后,再贷记全部净收方的清算模式。

2. 跨机构清算原理

所谓跨机构即收款人和付款人账户分属于不同的机构,例如小宇宙用微信扫码向微信商家支付了100元,但是用的是绑定的招商银行卡;这时候,用户的资金账户在招商银行,商家的收款账户在微信,分属于两个机构;那么这类场景的支付的清算就属于跨机构清算;跨机构清算就会涉及到清算机构(以网联为例)的信息转接以及清算业务。

机构内清算仅涉及到收付款双方的机构支付账户,但跨机构清算因为涉及到机构之间的清算,因此会涉及到机构的清算账户或者备付金账户,机构之间的清算在人行进行。

上图是以收款为例,商家提现的付款业务与之类似,只不过要将付款行改为收款行,要先进行前置系统的账务处理(扣减可用额度),再将付款指令发往收款行。

2.1. 联机交易

消费者在交易平台下单,使用绑卡支付,交易平台将支付请求提交到支付机构,支付机构请求网联进行协议支付;网联将协议支付指令转接给消费者付款行。

消费者付款行校验签约无误以后,发往银行核心扣除卡余额,并将处理成功的结果返回给网联。

2.2. 实时清算

网联收到付款行处理成功的回执以后,对交易信息实时进行清算,请求前置系统进行账务登记,记录机构间的交易信息,并更新支付机构的可用余额;完成账务处理以后反馈给清算平台处理成功。

清算平台将结果回执给支付机构,支付机构回执给交易平台;至此,联机交易结束。

交易成功后2个小时,即H+2,网联向支付机构下发本清算批次的清算文件,一天24个批次,每个批次为整数小时的交易明细(银联为48个批次,每半小时1批);明细记录了往来机构之间的收付交易明细。

如图中所示,2018060401,代表的是6.4号的第一个清算批次,是00:00-0:59:59之间的交易明细,在3点提供(H+2)给支付机构。

这里要注意:实时清算场次内,支付机构的映射额度不会发生变化,可用额度根据收付净额实时增减;付款清算基于可用额度进行。

2.3. 定时结算

网联根据机构间的收付金额,每天9:00和15:00向人行提交清算净额进行结算;并向支付机构下发备付金动账通知。

这里的净额指的是一个结算周期内,“收款-付款”的轧差净额,为正值则为资金净流入,如果为负值则是资金净流出。

央行结算成功以后,此时付款行清算账户资金划出,支付机构备付金划入;完成机构之间的资金清算。

这里要注意:结算成功后,网联会自动将支付机构的映射额度更新为上个清算周期末的可用余额,此时新可用余额=新映射额度=上一个清算末可用额度。

2.4. 日终处理

网联和人行将一个清算日内所有的结算结果进行汇总,将结算对账文件下发给支付机构和参与的银行进行各方对账;支付机构和银行根据拿到的结算文件执行内部的对账工作。

特别注意:其实交易当日已经拿到了几乎全部的24个批次的清算明细;结算账单主要用于确认央行收款,做备付金的收付入账处理。而支付机构还需要根据实际的备付金资金结算情况向自己的商户进行资金结算,并向商户下发对账文件。

至此,整个跨行的清算业务全部完成。

3. 支付清算全局实现

支付不是凭空发生的,需要发生在一定的交易场景中,例如我们常在京东购物,在美团点外卖,用支付宝转账,到去哪儿网买机票,这些都是交易场景,这些好产品让生活变得更加便捷。我们将这些平台称为互联网应用层,也就是交易平台。

这一层为用户直接提供商品、服务的交易场所和完成交易所需要的支付能力,是直接面向用户的互联网应用;用户在平台上购买服务,平台就需要有自己的支付体系来协助用户完成支付,例如收银台、交易体系、服务履约等。

这一层,最关键的是——做好“买卖”,卖好东西给用户,收好用户的钱,结好商家的账。

3.1. 平台全环节

要想做好一个交易平台,至少要实现以下7大环节,涵盖交易购物线、交易、支付、清结算、账务等。

3.1.1. 选购

用户在平台选择自己需要的商品或者服务,并添加至购物车,并可以享受各类营销活动,该环节商品、购物车处理、优惠计价是重中之重。

3.1.2. 交易处理

用户确认购买意愿,计算选购商品最终价格,生成签约订单,生成待支付账单的过程,这是支付的前置基础。

3.1.3. 支付处理

要想“收好钱”,平台就需要签约合适的支付产品,为用户提供优秀支付体验的支付服务,完成账单的支付,支付能力就是通道的能力,要什么能力就签什么通道。

3.1.4. 履约处理

用户支付成功后,平台按照订单约定,交付商品或者服务;商家发货,或者服务人员上门完成交付;用户最终进行确认;可以将常见的履约形式分成4类:

3.1.5. 清结算处理

支付成功后及履约完成后,开始对交易的最终结果进行计算各方权益,并将各方权益按约定结算至指定账户或者卡。

3.1.6. 账务处理

所有经济活动都需要记账;账务是记录交易、支付、资金处理相关的业务事项,并以固定的格式计入账户的业务。

3.1.7. 财税票资

财务核算、税务计扣、发票接收和开具,是企业支付处理的最后一环。

4. 支付全流程

从上一部分知道了一个交易平台的交易支付体系主要涉及到7大环节,他们之间相互协同和联系,其中的支付所涉及的链条主要是从用户选购到支付成功和账务登记;以支付为主线看一下整个支付流程是这样的。

横向看,代表支付的进程,包含了交易处理环节、收银台处理环节、支付处理环节、支付应答环节;该4大环节分别解决了交易单的生成、收银台的封装和展示、请求支付渠道完成支付、支付后的各方应答反馈。

4.1. 支付机构五大业务

可以将支付机构的业务分成5大类,三大支付业务“收款、付款、退款”,2的资金处理业务“清算、结算”;这5大业务的协调运转让三方支付机构这样一个庞大的支付服务平台为市场提供优秀的支付能力。

4.1.1. 收款业务

代商户向用户收款的业务,常见的业务类型有零钱支付、快捷支付、网关支付等等,商户将支付请求提交给支付机构,支付机构处理完以后提交给网联或者银联渠道进行资金清算;假设商户请求方式为H5收银台。

收单业务中的整体处理主要分4个阶段

  1. 第一阶段是联机交易阶段,进行支付指令的接收、发送、支付结果的接收;
  2. 第二阶段是收单流水账务登记和分账、分润、各应入金额的清算阶段;
  3. 第三阶段是渠道清算对账和渠道资金确认的阶段;
  4. 第4个阶段就是商户结算的阶段并发起结算出款。

第4阶段的结算出款是出金业务很重要的一种。

4.1.2. 付款业务

出款业务是支付机构将备付金资金向外付出的业务处理;涉及到商户的结算出款,商户代付代发以及主动发起提现的出金业务,以及退转付的出金业务等几大类;不同的出金业务发起方不同,业务层有所差别,但出款处理层相似。

这里要注意每类出金业务的发起方,失败后的处理方式,是余额退回还是自动重出;另外要特别注意:因为打款时高危的资金操作行为,需要设定资金处理规范和底线,例如统一由账务中心调用,必须先扣账再出款,而且对于重出的操作严格把控。

4.1.3. 退款业务

退款业务主要是收单业务的逆向,这里可以根据不同的收单方式设计退款的处理,例如网络支付、POS、银行单边的退回等。

从产品架构上,退款中心以各退款产品为主线进行构建,每一种退款产品在退款处理流程上存在差异。

例如原路退和退转付,前者是基于原支付调用原支付通道提供的退款服务,而后者是需要基于原退款调用可用付款通道处理退款业务,并且需要进行用户账户的采集等处理环节。

4.1.4. 清算业务

支付机构的清算一方面是与渠道的资金清算,另一方面就是与内部商户、渠道上之间的收款、分账、分润、手续费等的清算。

4.1.5. 结算业务

支付机构的结算业务主要是预收商户交易款向商户的结算;为了迎合商户对资金的需求,一般会提供可选择的多样的结算产品,例如T1、D1、D0、S0等。对结算业务流程的把握,主要是把握不同结算产品的处理逻辑,例如:

4.2. 支付系统总架构

虽然有非常多的平台类型,例如出行、电商、家政、外卖、二手车等,他们的交易支付体系建设存在差异,但依然可以在底层架构上实现统一化。

剥离出行业差异化和交易特征的差别,以及同类交易平台的个性化属性,将一个交易平台的支付体系抽象出一个典型的支付清结算架构,使其可以应用于更多的业务场景,做为支付建设的底层认知。

4.3. 收付全渠道

交易平台要想实现向用户收款,向商家结算付款,就需要接入适合自己的支付产品,这些产品由支付机构提供。

线下收款场景可以接入聚合支付, 此类产品相对比较成熟。

线上交易平台根据自己的交易特征,是B2B业务,还是B2C业务,交易金额大不大,用户的支付使用习惯怎么样,来选择合适的支付产品;例如一般的面向个人用户的交易平台一般可以选择“2+1”的渠道模式,即“微信+支付宝+银行卡快捷”,基本可以覆盖90%以上的支付诉求。

每一个支付产品都对应着一个功能列表,这个列表其实就是接口的集合,在对应的业务处理时调用相应的功能接口接口。

这样根据业务需求接入了所有要的所有渠道的所有支付产品,也就获得了所有的支付接口,每个接口的协议也就明确了,这样就形成了全渠道的支付能力矩阵。

可以通过四层法来管理渠道:渠道-产品-接口-协议;该方法同样适用于支付机构、四方支付机构来管理自己的渠道。

不同的支付产品也就决定了平台处理支付时应该如何与渠道进行交互。

4.4. 支付机构-“收付退清结”

交易平台的收付请求提交到了支付机构,这笔请求在支付机构内部系统之间会怎么流转和处理呢?

支付机构作为拥有支付牌照,为交易平台提供支付解决方案的企业,也有着自己复杂而庞大的支付体系,其中常见的部分包括各类收银台、支付产品、支付路由、支付通道、支付核心、账务核心、清算核心、风控核心、商户入网等等。

机构的业务主要是帮助商户收款付款的收付退业务,为商户结算的打款业务,从中获取商户手续费收入,并支付通道成本,之间形成的价差就是机构的主要利润来源;当然直联时代还有备付金利息,现在没有了。

4.5. 支付机构系统矩阵

支付机构以银行支付通道为业务基础,封装出适用于各类交易场景的支付产品,为商户提供支付能力,这是支付机构的产品主线,围绕该主线又会产生其他类系统的诉求,例如资金处理、对账、计费等。

下图是的支付机构的典型支付清结算系统框架:

接入层:是三方支付机构直接面向客户的入口,包括个人客户、商户、渠道商等,为个人客户提供消费支付产品,为商户提供支付能力服务,为渠道商提供分销合伙的平台。

业务层:是支付机构所打造出来的适用于各类支付场景的支付产品,例如航旅支付解决方案、生活缴费支付解决方案、银行卡支付、资金合规、分账类产品、商户结算类产品等。

交易层:是对各类业务交易请求的处理层,处理上游各业务线下发的支付订单,例如收款类交易、付款类交易、鉴权类交易等。

支付处理层:提供收银台和支付核心,还将构建各类支付的核心处理流程,例如快捷支付、网关支付、分账支付等。

风控层:对支付安全负责,包括客户信用安全、交易安全、支付安全、数据安全等等。

渠道层:是底层对接的提供各类支付通道的服务商,其中包括一些消金类机构、银行、清算机构等。是集中管理接入的各类支付通道,以及为支付层筛选最佳通道的路由系统。

5. 支付清算案例

5.1. 全局支付流程

交易平台向用户收款产生支付收款业务;交易平台本身提现或者其商家发起提现均产生付款业务,整个支付的流程如下图所示:

特别注意:支付业务是用户付款行完成用户扣款是成功的基础,即意味着支付指令成功,而支付机构、网联、支付机构的商户、商户的店家等以收到成功指令为成功标志,而不是以实际的资金到账;因为各方的资金清算一般都是T+1到账。

5.1.1. 支付收款

我们看收款的业务流程,为了便于理解和全文的信息一致性,将相关局部图例的业务流程串起来看,从用户在交易平台选购商品以后开始,然后交易平台将支付请求提交给支付机构,也就是支付机构接收到的“1.商户下单请求”,支付指令正式进入支付机构。

5.1.2. 提现付款

交易平台、交易平台的商家都可以向支付机构发起提现业务,从而形成支付机构的付款业务,支付机构将付款请求提交至网联进行出款申请。

这里要明确一点,可以发起提现的前提是交易平台的支付账户中,或者商家的二级账簿中存在可用余额。

特别注意:交易平台上商家的提现出款有两种常见形式:

  1. 一种是采用监管模式,通过交易平台发起分账,分账至商家的二级账簿中;
  2. 第二种是直接走支付机构的代付,付款给商家指定的银行卡中。

5.2. 实时清算

当然这里的清算工作,在网联、支付机构、交易平台、首付款行都在同时进行,他们都是以网联的清算指令结果为依据。

5.2.1. 网联的清算

网联执行实时清算的模式,在前置系统模块完成,其实就是清算平台请求前置系统,在轧差模块实时计算收支净额,并实时更新支付机构的可用余额,以此来完成清算场次内的基于虚拟账户的清算工作。

5.2.2. 收款清算

即支付机构发起的协议支付、网关支付等收款指令时进行的清算,等到付款行返回成功回执以后,网联便开始执行收款的清算账务登记,主要是增加收款发生额和调增可用额度,假设支付机构在一个清算场次内发起了2笔10元的收款,都成功了。

期初可用额度=映射额度=100;收了两笔钱以后,可用额度变为120,映射额度没有变化。

5.2.3. 付款清算

即支付机构发起的付款业务,网联接收到付款请求以后,实时轧差处理,扣减可用额度,然后才会请求收款行进行收款,假设支付机构发起了2笔50元的付款,均成功。

两笔出款后可用额度减少了100,变成20,映射额度依然没有变化。

5.2.4. 轧差净额

网联实时轧差各机构的交易的净额,并生成机构该场次内的总清算净额。

5.2.5. 账户更新

如上面表格所示,实时清算,指令实时登记,实时轧差净额,可用额度实时更新,映射额度不变。

5.2.6. 下发清算文件

整个日间会有24个清算批次,每个小时下发一次2个小时前的一个小时的清算文件,一共24批清算文件;支付机构可以根据该清算文件进行对账和对商户的清算工作,清算明细内容如下。

5.2.7. 其他机构的清算

以网联为核心,银行、支付机构、交易平台分别根据支付结果、清算文件的通知,根据自己平台的清算协议向各方进行清算,例如支付机构收到支付成功通知以后进行账务登记和清算处理,登记清算往来账务及商户待结算。

此时因为净额没有提交人行,所以不涉及人行相关机构账户的变动;所以全局账户的资金变动如下图所示:

5.2.8. 定时结算

到了结算场次以后,网联是每天9:00和15:00;将各机构的清算净额提交央行进行机构间的资金清算;根据机构净额情况分别提交付差方和收差发。

根据交易情况,本结算场次内各机构的清算净额如下:

5.2.9. 提交央行资金清算

到了结算场次向人行发起即时转账指令,即将发起借记A支付机构80、借记B银行20、贷记C银行100的即时转账指令。

更新机构额度: 资金在人行清算成功以后,网联即开启下一个清算场次的工作,此时根据央行的结算结果,会更新支付机构的相关额度。

映射额度更新为上个场次末的可用额度,即20;可用额度=映射额度=20。

下发动账通知: 结算完成后,网联向各机构下发动账通知,告知央行备付金、映射额度、可用额度的变化情况;

特别注意:支付机构可以根据实际需要对映射额度进行调整,以满足下一个清算周期的清算业务。

日终结算文件:大额日终以后,向各机构下发结算文件,支付机构可以根据结算文件确认央行备付金资金收付情况,以完成备付金存款的账务登记。

各清结算处理:拿到结算文件以后,各机构进行多方的资金对账,无误后确认央行存款变动;各方的

博文参考

《支付生态》

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2264079.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

javaEE-线程的常用方法-4

目录 一.start():启动一个线程 调用start()方法 start()方法只能调用一次: java中的API: start()和run()的区别: 二.中断一个线程 中断线程方法1:引入标志位 中断线程方法2:调⽤interrupt()⽅法 抛出的异常: 三.等待一个线程 join() 四、获取线程引用 五…

uniapp小案例---趣味打字坤

当点击输入框时出现小鸡打字 当输入框失焦时打字鸡沉下去 原图自取 这里运用了一个三元 :class"isActive?active:"&#xff0c;当聚焦时isActivetrue从而让class绑定&#xff0c;当失焦时isActivefalse <template><view class"out"><inp…

JS使用random随机数实现简单的四则算数验证

1.效果图 2.代码实现 index.html <!DOCTYPE html> <html lang"en"> <head><meta charset"UTF-8"><meta name"viewport" content"widthdevice-width, initial-scale1.0"><title>Document</ti…

vue3项目结合Echarts实现甘特图(可拖拽、选中等操作)

效果图&#xff1a; 图一&#xff1a;选中操作 图二&#xff1a;上下左右拖拽操作 本案例在echarts​​​​​​​示例机场航班甘特图的基础上修改​​​​​​​ 封装ganttEcharts组件&#xff0c;测试数据 airport-schedule.jsonganttEcharts代码: 直接复制粘贴可测​​​​…

【已解决】黑马点评项目jmeter高并发测试中用户数据的生成

具体实现见此篇文章的第3章 运行 test 程序后&#xff0c;生成以下用户名 以下文件名改成自己的地址 成功

VScode 查看linux 内核代码

0&#xff0c;安装c.c 1&#xff0c;查看linux 目录下的linux代码&#xff0c;安装remote ssh 2&#xff0c; 输入服务器IP 3 选择服务器为linux

【游戏设计原理】21 - 解谜游戏的设计

你想象一下&#xff0c;刚坐下准备玩游戏&#xff0c;想着“今天得挑战一下我的智商极限&#xff01;”可结果碰上一个谜题&#xff0c;傻眼了&#xff0c;心里默念&#xff1a;“这啥玩意儿&#xff1f;这游戏是在玩我吗&#xff1f;”如果这个谜题太简单了&#xff0c;你可能…

解析交通事故报告:利用 PDF、AI 与数据标准化技术构建智能分析系统

在交通事故处理中&#xff0c;数据的准确性与完整性至关重要。传统上&#xff0c;交通事故报告通常以 PDF 格式呈现&#xff0c;这使得手动提取数据成为一项繁琐且容易出错的任务。随着人工智能与数据处理技术的发展&#xff0c;如何自动化这一过程并提升数据质量&#xff0c;成…

基于Python+Vue开发的体育用品商城管理系统,实习作品,期末作业

项目简介 该项目是基于PythonVue开发的体育用品商城管理系统&#xff08;前后端分离&#xff09;&#xff0c;这是一项为大学生课程设计作业而开发的项目。该系统旨在帮助大学生学习并掌握Python编程技能&#xff0c;同时锻炼他们的项目设计与开发能力。通过学习基于Python的体…

7.C语言 宏(Macro) 宏定义,宏函数

目录 宏定义 宏函数 1.注释事项 2.注意事项 宏(Macro)用法 常量定义 简单函数实现 类型检查 条件编译 宏函数计算参数个数 宏定义进行类型转换 宏定义进行位操作 宏定义进行断言 总结 宏定义 #include "stdio.h" #include "string.h" #incl…

【LeetCode】906、超级回文数

【LeetCode】906、超级回文数 文章目录 一、通过数据量猜解法 枚举 数学 回文1.1 通过数据量猜解法 枚举 数学 回文1.2 多语言解法 二、打表法 一、通过数据量猜解法 枚举 数学 回文 1.1 通过数据量猜解法 枚举 数学 回文 减小数据规模: 先构成回文, 再平方, 再判断是否是范围…

SpringBoot的创建方式

SpringBoot创建的五种方式 1.通过Springboot官网链接下载 注意SpringBoot项目的封装方式默认为Jar 需要查看一下&#xff0c;自己的Maven版本是否正确 创建成功 2.通过 aliyun官网链接下载 修改服务路径为阿里云链接 创建成功 3.通过Springboot官网下载 点击&#xff0c;拉到最…

Android Studio AI助手---Gemini

从金丝雀频道下载最新版 Android Studio&#xff0c;以利用所有这些新功能&#xff0c;并继续阅读以了解新增内容。 Gemini 现在可以编写、重构和记录 Android 代码 Gemini 不仅仅是提供指导。它可以编辑您的代码&#xff0c;帮助您快速从原型转向实现&#xff0c;实现常见的…

物理信息神经网络(PINN)八课时教案

物理信息神经网络&#xff08;PINN&#xff09;八课时教案 第一课&#xff1a;物理信息神经网络概述 1.1 PINN的定义与背景 物理信息神经网络&#xff08;Physics-Informed Neural Networks&#xff0c;简称PINN&#xff09;是一种将物理定律融入神经网络训练过程中的先进方…

双臂机器人

目录 一、双臂机器人简介 二、双臂机器人系统的组成 三、双臂机器人面临的主要挑战 3.1 协调与协同控制问题 3.2 力控制与柔顺性问题 3.3 路径规划与轨迹优化问题 3.4 感知与环境交互 3.5 人机协作问题 3.6 能源与效率问题 3.7 稳定性与可靠性问题 四、双臂机器人…

日期区间选择器插件的操作流程

我们知道&#xff0c;在开发过程中&#xff0c;为了能够在规定时间内完成项目&#xff0c;有时候我们都会使用插件来大大提高我们的开发效率&#xff0c;有些插件是可以直接拿来用&#xff0c;但是有些插件拿过来之后是需要进行修改&#xff0c;在使用插件的时候还有很多的注意…

以ATTCK为例构建网络安全知识图

ATT&CK&#xff08;Adversarial Tactics, Techniques, and Common Knowledge &#xff09;是一个攻击行为知识库和模型&#xff0c;主要应用于评估攻防能力覆盖、APT情报分析、威胁狩猎及攻击模拟等领域。本文简单介绍ATT&CK相关的背景概念&#xff0c;并探讨通过ATT&a…

“年轻科技旗舰”爱玛A7 Plus正式发布,全国售价4999元

12月18日&#xff0c;备受行业瞩目的“A7上场 一路超神”爱玛旗舰新品发布会在爱玛台州智造工厂盛大举行。 作为年末“压轴产品”的“两轮豪华轿跑”爱玛A7Plus重磅上场&#xff0c;以“快、稳、帅、炫、智、爽”六大超神技惊艳四座&#xff0c;不仅践行了爱玛科技的精品战略&…

精通Redis(一)

目录 1.NoSQL 非关系型数据库 2.Redis 3.Redis的java客户端 4.Jedis 4.1Jedis快速入门 4.2Jedis连接池及使用 5.SpringDataRedis和RedisTemplate 1.NoSQL 非关系型数据库 基础篇-02.初始Redis-认识NoSQL_哔哩哔哩_bilibili NoSQL与SQL的区别就在于SQL是结构化的、关联…

研发效能DevOps: Vite 使用 Element Plus

目录 一、实验 1.环境 2.初始化前端项目 3.安装 vue-route 4.安装 pinia 5.安装 axios 6.安装 Element Plus 7.gitee创建工程 8. 配置路由映射 9.Vite 使用 Element Plus 二、问题 1.README.md 文档推送到gitee未自动换行 2.访问login页面显示空白 3.表单输入账户…