Posted in

两条耦合链路,支付架构_AI阅读总结 — 包阅AI

包阅导读总结

1. 关键词:支付架构、耦合链路、分层架构、业务架构、流程处理

2. 总结:本文深入探讨了第三方支付结算系统的架构,包括核心的两条耦合链路、分层架构、业务架构、处理流程等,指出支付系统以账务为核心,通过联机交易链路和日终核算链路支撑运行,并对各部分做了详细介绍。

3. 主要内容:

– 两条耦合链路

– 联机交易链路:指令从网关到渠道跨行收付款,过程中使用收银台和会员系统,结果在账务系统记账,资金待结算。

– 日终核算链路:日终银行清算后,对账系统核对文件,给客户结算资金、渠道清算平账,完成总账汇总核算。

– 支付的分层架构

– 一个系统:通过系统转换实现资金跨行转移到收款人账户。

– 两个通道

– 网关/终端:支付系统的“接入端”,提供支付、开户和认证,需安装“密钥和证书”保证安全。

– 渠道:支付系统的“接出端”,负责对接支付接口,能进行动态路由选择。

– 三层架构

– 产品层:基础支付产品的场景化包装。

– 交易层:提供基础支付产品和服务。

– 核心层:提供原始的账务、渠道、清结算服务。

– 支付业务架构

– 收银系统:多种收银台形式,依托支付场景包装。

– 交易系统:处理支付处理需求,提供支付和交易服务。

– 客户系统:根据账户不同有不同身份,对应不同服务。

– 产品中心:配置商户相关信息,提高配置效率。

– 支付引擎:屏蔽底层复杂性,负责流程调度。

– 账务中心:包含账务、会计、总账,提供记账和核算服务。

– 对账中心:负责账务核对、差错处理等。

– 支付架构流程

– 联机交易链路:从网关到渠道形成支付请求处理流水线。

– 日终结算链路:针对日间实时交易进行对账和清结算处理。

– 联机交易链路

– 收单流程:包括快捷支付、收银台支付、小程序支付等典型场景。

– 余额支付:包括账户充值、提现、转账到卡等交易。

– 日终结算链路

– 系统对账

– 差错调账

– 渠道清算

– 商户结算

– 商户提现

– 账务核算

思维导图:

文章地址:https://www.woshipm.com/pd/6085650.html

文章来源:woshipm.com

作者:刚哥

发布时间:2024/7/19 20:07

语言:中文

总字数:4494字

预计阅读时间:18分钟

评分:80分

标签:支付系统,架构设计,联机交易链路,日终核算链路,第三方支付


以下为原文内容

本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com

在现代数字化经济中,第三方支付结算系统扮演着至关重要的角色,为线上交易提供便捷、高效的清分和结算服务。本文将深入探讨支付结算系统的架构设计,特别是其核心的两条耦合链路——联机交易链路和日终核算链路,以及它们如何共同支撑起整个支付生态系统的稳定运行。通过详细解析支付系统的分层架构、业务架构和处理流程,读者将获得对支付系统工作原理的全面了解。

我们这里说介绍的支付就是三方支付使用的支付结算系统,他能够为买卖双方进行线上的交易、清分和结算功能。很多人觉得支付架构不好画,其实还是因为不得要领,因为支付系统做的是清结算业务,因此在架构表现上就是以账务为核心的两条耦合链路。

一、两条耦合链路

之所以要设计成耦合的交易链路,是因为资金不能像指令一样在网络上传输,因此我们跨行线上交易都是采用的待结算方式。

待结算就是先实时让指令传输,并以记账的形式登记处理结果,此时客户看到的资金是待结。资金到账后支付系统根据银行清算文件,把账务信息转化成给客户结算的资金,此时客户看到的资金可用。

图1:支付架构的两条耦合链路

1. 联机交易链路

联机交易是指令从网关到渠道跨行收付款,在这过程中会使用到收银台来进行支付、会员系统验证客户身份。整个过程系统会把指令的往来收付结果在账务系统记账;此时客户查询的余额并不能提现,而是待结算。

2. 日终核算链路

日终银行清算后,对账系统将银行清算文件与支付数据进行核对,确认无误后给客户结算资金、渠道清算平账。最终完成总账的汇总核算,实现资金与账务的最终一致。‍‍

为什么是耦合的?

看到这里是不是觉得这张图很眼熟?是的,这就是银行会计的“收付实现制”;这也是我提出信息、账务、资金的支付三流合一原因。

二、支付的分层架构

支付系统是按客户订单完成‍跨行收付款,并将资金最终‍转移到收款人的账户里。因此整套系统按照“一个系统、两个通‍道、三层架构”来进行划分。

图2:支付系统架构分层

1. 一个系统

为了实现买卖双方的跨行收付款,支付平台会把支付产品包装成接口或支付页面提供给客户来使用,并通过系统的层层转换来实现资金的跨行转移到收款人账户里。

2. 两个通道

(1)网关/终端(接入端)

它是支付系统的“接入端”,将支付产品通过接口、页面、终端设备的形式提供给用户进行支付、开户和认证。同时访问网关或者使用终端设备还要安装“密钥和证书”,以此来保证你支付的安全。

(2)渠道(接出端)

它是支付系统的“接出端”,他负责对接三方、银行、清算机构的支付接口,把他转换成标准支付产品提供给上层的产品使用。如果选择对接了多家银行相同的支付产品,他能根据“订单、渠道、稳定性”进行动态的路由选择。

(3)三层架构

①产品层(场景化包装)

产品层是为了适应不同场景的支付需求,把基础支付产品包装成面向不同场景的支付产品,满足不同行业对于支付的需求。例如面向个人用户的B2C、C2C支付,面向企业的B2B支付,以及面向金融机构的消金支付等;因此产品层是基础产品的场景化包装,方便不同用户使用。

②交易层(基础支付产品)

为使用者提供基础的支付产品,包括充值、提现、收款、分账、付款等支付服务,满足多场景对支付的基本需求。他主要包括了收银台、交易系统、客户系统三部分。

③核心层(原始支付服务)

“核心层”又叫“支付层”,是为交易层提供原始的账务、渠道、清结算服务,他专注于内部账务逻辑和支付渠道的处理逻辑,并且核心层也代表了一个系统的核心能力,他决定了上层产品是否好用。这里主要包括了支付引擎、账务核心、对账中心三部分。

三、支付业务架构

图3:支付业务架构

业务架构顾名思义就是面向业务场景提供的架构图,他主要目的就是让非技术人员了解系统具有哪些能力,以及系统提供的能力是否符合期望。业务架构一般分为两张图“架构图、流程图”,架构图负责展示系统的功能结构,流程图负责展示功能之间关系。

从支付的业务架构我们可以看到,相对于分层架构,实际的业务架构有许多的辅助系统来支持支付业务的运行。不过支付业务核心闭环的还是支付服务中的8个模块当主角,下面我们来分别介绍下。

1. 收银系统

收银台系统就是以页面的形式提供给用户进行收款操作,同时它也会面向不同的支付终端提供各种类型的收银台,我们按终端类型把它们分H5收银台、SDK收银台、小程序收银台、WEB收银台、聚合收款码为五类。收银台形式有很多种了,主要还是依托于支付场景包装,让用户能够更顺畅的支付。

2. 交易系统

通过前面的介绍我们知道,交易系统是面向支付场景和用户提供的服务,因此他主要职责是处理业务场景复杂多变的支付处理需求。

图4 交易系统核心能力

(1)支付服务提供者

交易系统是支付服务的提供者,他负责给外部使用收款、付款、余额支付等交易方式,并以订单的形式记录支付的处理过程。

(2)交易服务提供者

据不同的场景它还提供担保交易、合单支付、组合支付等分账交易把资金分配给交易的参与方。因此我们使用的支付产品其实都是交易系统提供的服务。

3. 客户系统

顾名思义是为客户提供服务的系统。客户注册的时候都是会员角色。随着客户开出的账户不同就有了不同的身份。例如客户开出基本账户就是用户角色,如果申请支付产品开出特约商就是商户角色。因此在系统上表现为面向C端的用户钱包,面向B端商户平台,以及提供技术对接的开放平台。

4. 产品中心

产品中心是包装对外销售产品的一个配置中心,并且商户相关的签约产品、计费信息、交易限额等都可以通过灵活的模板来进行配置。它的作用就是提高配置效率,通过组件化的配置工具,能快速搭建一个新的支付产品出来提供给客户使用。

5. 支付引擎

支付引擎顾名思是支付的发动机,他负责所有系统与账户、渠道的支付流程处理。

图5 支付引擎核心能力

(1)支付提供者

它对交易层的“交易系统、客户系统、收银台”等屏蔽了底层支付账务、支付渠道管理的复杂性,让交易层可以专注于业务场景,即使底层渠道更换,账务进行调整,交易层也不会受到影响。

(2)流程调度者

有了支付引擎这个大当家,流程处理相关的“脏活累活”都由他来负责。账户、渠道、清结算就可以各司其职做好本职工作,如果涉及其他系统协作,通知“支付引擎”去干就可以了。

6. 账务中心

账务中心又叫账户系统、账务核心。他一般系统包含了账务、会计、总账三部分。账务对外提供记账服务,并且实时更新客户账户余额。会计部分用来登记会计账簿、更新内部账户余额。总账是日终的汇总核算服务,总账平衡后当天的业务才算结束。

7. 对账中心

又称为清结算系统,资金系统,他负责与支付渠道进行账务核对,差错处理、手续费的清分和客户资金的结算。同时对于资金归集、划拨等无法在实时交易中完成的结算操作,也是由清结算系统负责处理的。

四、支付架构流程

由于支付系统对于交易处理性能和资金结算效率要求都比较高,因此它采用的是流水线作业方式。从前面介绍的两条耦合链路我们知道,在支付架构的流程上表现出来的是联机链路、结算链路两条链路。

图6:支付系统流程图

1. 联机交易链路

联机交易链路从“网关”到“渠道”形成一条支付请求的处理流水线,客户、收银台、账户和清结算各节点按部就班的处理流水线传递过来的信息,完成客户信息校验,资金账号获取,收银台展示,账务登记,渠道路由和跨行收付款操作。

2. 日终结算链路

结算链路又叫清结算流程,他针对日间的实时交易,进行对账和清结算等处理,只有日终处理完了,一天的交易才算完毕。

下面我们就按照这两条链路来详细介绍他的处理机制。

五、联机交易链路

1. 收单流程

收单业务是第三方支付的核心业务,他场景化比较丰富,因此系统流程也会相对复杂些。我们针对“API收款”、“收银台收款”和“小程序收款”几种典型场景进行介绍。

(1)快捷支付(API直接支付)

快捷的API支付,首次发送短信验证码绑定开户银行卡,收单机构会提供一个协议号给商户保存;后续短信验证码可免,通过传送绑卡时的协议号就能完成免密扣款。具体流程见下图:

图7 快捷支付流程

(2)收银台支付(本地收银台支付)

收银台支付包含H5支付、SDK支付(集成在APP内),由于他可以包装比较多的支付方式在收银台上,因此又叫“聚合收银台”。我们这里介绍的场景是用户在收银台上选择本地绑定的银行卡,因此,通过快捷支付就能完成扣款,无需跳转到第三方。具体流程见下图:

图8本地收银台支付流程

(3)小程序支付(渠道收银台支付)

以小程序支付为代表的,APP支付、微信H5支付、公众号支付、扫码支付等,都需要跳转到渠道方收银台上输入密码并完成支付。这种支付方式对客户来说比较安全,但是也比较封闭,因此在交互体验上也复杂了不少。具体流程见下图:

图9 渠道收银台支付流程

从上图可以看到以“交易”和“支付”为流程调度者的优势就出来了,他们可以任意的定制支付流程,从而满足复杂场景对于支付的处理要求。

2. 余额支付

余额支付就是以账户余额为基础的“充值、提现、转账到户、转账到卡”的交易。

(1)账户充值(充值API)

账户充值与收单流程基本类似,就是在充钱需要判断账户和绑定银行卡是实名认证后的同名账户。具体流程见下图:

图10 账户充值流程

(2)账户提现(代付API)

提现是充值的反向交易,因此他获取计费信息、校验绑卡同名与充值基本是相同的,区别在于它记账方式不一样。他采用先扣客户余额,然后发送渠道付款,这样资金处理比较安全。

图11 账户提现流程

(3)转账到银行卡(代付API)

转账到卡又称为“代付业务”,它和“提现”在支付、账务和渠道处理上是类似的,区别在于它的收款人不是本人。

图12 转账到卡付款流程

六、日终结算链路

日间实时支付交易完成后,日终清结算开始上场了。我们前面收单交易、充值交易等跨行收款交易资金还要结算给客户和商家,并且要给商家提供账单,这样一天的业务才算完成,下面我们来介绍下日终的清结算处理流程。

图13 日终清结算流程

1. 系统对账

下载渠道、支付系统、交易系统对账文件进行对账。先核对渠道账务,再对交易账务并按商家账户维度进行交易清分和手续费扣收。

2. 差错调账

完成对账后如果有差错,以渠道为准在“账户系统”内调平本方账务差错。

3. 渠道清算

当日对账无误后,根据当日的应收应付的轧差金额和渠道银存账户的期末余额,在账户系统内登记当日清算账务。

4. 商户结算

当日对账无误后,根据每个商户、客户的待结算资金进行结算,收款资金在他们账户上就可以使用了。(因为是以渠道方为准,渠道清算和商户结算没有必然的先后顺序,所以只要账务对平就可以进行)

5. 商户提现

商户结算完成后如果商户设为自动提现,系统在T+1日自动完成商户的打款操作,并生成商户结算账单。

6. 账务核算

渠道清算和商户结算完成后,账户系统的核算模块对当天的账务进行总分核算、汇总平衡,最终生成报表。当日的交易也就处理完成了。

七、总结

最后我们来总结下,支付系统架构层面的表现出来的就是“联机链路、日终链路”联调链路。由于跨行收付款时,指令和资金到账时效的不匹配,采用了日间记账的方式来记录待结算资金,通过日终清结算来给客户结算跨行资金。

联机交易通过“网关、交易、收银台、客户、支付、渠道”6个模块是了跨行收付款和账务登记。日终链路通过“支付、对账、账务、会计”这6个模式完成跨行资金的清结算。

本文由人人都是产品经理作者【刚哥】,微信公众号:【刚哥白话】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。