原文：https://blog.csdn.net/Peter_Changyb/article/details/88074239
交易系统更多的服务是通过后台接口来完成的，这部分占到整体系统很大的业务比重。如支付后期的资金流转、逆向操作退款等。但也有一些是用来查询一些交易订单相关性的信息。在此背景下，对于api接入层采用读写分离方式处理。如下图ares系统，将底层的各dubbo服务包装提供各种查询类服务。Odin系统是可读写，更多的关注跟核心业务相关的写，如解冻、退款、撤销等。
https://www.cnblogs.com/songbao/p/12015641.html
https://cloud.tencent.com/developer/article/1080348
支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后，支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口，通过支付网关来对外提供服务。所以，从微服务的角度来说，支付产品本身也是一个代理模式的微服务，它透过支付网关响应业务方请求， 进行一些统一处理后，分发到不同的支付渠道去执行，最后将执行结果做处理后，通过支付网关再回传给业务方。支付产品在支付系统架构图中的位置，如下图所示：
产品分类
在不同的公司由于接入渠道和应用的差异，对支付产品分类略有不同。综合支付场景和流程，支付产品可以分为如下几类：
支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力。整体上来说，可以提供如下支付产品：
1. 快捷支付
用户在完成绑卡之后，在支付的时候，不需要再输入卡或者身份信息，仅需要输入支付密码就可以完成支付。对于小额度的支付，甚至可以开通小额免密，直接完成支付。 这种支付方式不会打断用户的体验，是目前主要的在线支付方式。一般快捷支付产品是通过封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。
2. 网银支付
用户在支付的时候，需要跳转到银行网银页面来完成支付。在网银页面，需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验，一般仅用于 PC Web 上的支付。 网银支付是封装银行提供的网银支付来实现。
3. 协议支付
协议支付也称代收或者代扣，代收指渠道授权商户可以从用户的银行账户中扣款，一般用于定期扣款，不用于日常消费。比如水电煤气、有线电视费。协议支付是通过封装银行、第三方支付提供的代扣或者快捷接口来实现。
4. 平台支付
使用微信、支付宝等第三方支付平台来完成支付。使用时，一般需要用户预先安装支付平台系统（手机上），注册并登录到第三方支付平台，并且已经在该平台上完成绑卡等操作。 由于微信、支付宝已经被大量使用，用户也产生对这些平台的信任，平台支付往往是电商公司的主要支付方式。
5. 外卡支付
对于由海外支付的需求，还需要提供外卡支付支持。 国内不少支付渠道都能支持外卡支付，如支付宝全球购等。直接对接 Paypal，也是目前用的最多的外卡支付渠道。
6. 话费支付
对于有包月小额类型的支付，手机话费也是一个不错的选择。目前也有一些平台可以支持话费支付，比如虹软、联动优势等。
7. 虚币支付
不少公司会有自己的虚拟币，比如京豆、Q币等。这些虚币也可以作为一种支付方式。
8. 账户支付
也称为余额支付、零钱支付等。 指为用户建立本地账户， 支持充值，之后可以使用这个账户来完成支付。
9. 信用支付
如京东的白条，蚂蚁花呗等，指使用信用账户进行透支，类似信用卡支付。
10. 代付
和代扣相反，代付是平台将钱打给用户。
模块功能
支付产品根据其支付能力，对外提供不同的功能。整体上来说，一般支付产品需要提供如下接口：
1. 签约和解约
在快捷支付、代扣等产品中，用户在使用前，需要先完成签约。签约可以在渠道侧进行，一般第三方支付采用这种方式，当电商需要接入时，让第三方给授权。 银行和银联的签约一般是在电商侧进行， 电商侧负责收集用户的信息，调用银行和银联的接口进行签约。签约后，后续的支付行为就使用签约号来进行，无需再输入个人信息。 和签约相对应，解约则是取消签约关系。
2. 支付
支付是少不了的操作。 不同产品中支付行为不一样。快捷支付是在电商服务器上发起，请求渠道进行支付；网银支付则是跳转到银行支付网关上进行; 而账户支付、虚币支付，则是在本地进行的。
3. 撤销和退款
有些渠道区分撤销和退款，比如银联、农行等，撤销指取消当天在渠道侧未结算的交易； 而退款仅针对已经结算的交易。有些渠道则不作区分。
4. 查询签约状态
对于需要签约的交易，可以通过这个接口来查询签约状态。
5. 查询订单状态
通过这个接口来查询支付清单状态以及退款的订单状态。
6. 预授权
预授权交易用于受理方向持卡人的发卡方确认交易许可。受理方将预估的消费金额作为预授权金额，发送给持卡人的发卡方。
7. 预授权撤销
对已成功的预授权交易，在结算前使用预授权撤销交易，通知发卡方取消付款承诺。预授权撤销交易必须是对原始预授权交易或追加预授权交易最终承兑金额的全额撤销。
8. 预授权完成交易
对已批准的预授权交易，用预授权完成做支付结算。
9. 预授权完成撤销
预授权完成撤销交易必须是对原始预授权完成交易的全额撤销。预授权完成撤销后的预授权仍然有效。
10. 对账
通过 FTP 或者 HTTP 方式提供对账文件供商户侧对账。
11. 余额查询
查询商户的交易账户的余额，避免由于余额不足导致交易失败。 注意，不是客户的余额。 当然，不是所有的银行或者第三方支付都提供这个接口。
业务流程
上述操作，除了对账、查单外，每个操作实现的主流程，一般会包括“参数校验，支付路由，生成订单，风险评估，调用渠道服务，更新订单和发送消息”这 7 步，对于一些比较复杂的服务，还会涉及到异步通知处理的步骤。
1. 执行参数校验
所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击。验证输入参数中各字段的有效性验证，比如用户ID、商户ID、价格、返回地址等参数。验证账户状态，交易主体、交易对手等账户的状态是处于可交易的状态。验证订单，如果涉及到预单，还需要验证订单号的有效性，订单状态是未支付。为了避免用户缓存某个 URL 地址，还需要校验下单时间和支付时间是否超过预定的间隔。验证签名，签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的 key 来对输入参数拼接成的字符串做 MD5 Hash 或者 RSA 加密，然后作为一个参数随其他参数一起提交到服务器端，签名验证也可以在网关中统一完成。
2. 根据支付路由寻找合适的支付服务
根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付，但是我们没有实现和工行的对接，而是可以通过第三方支付，比如支付宝、微信支付、易宝支付，或者银联来完成。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。
3. 评估交易风险
检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。阻断交易，说明该交易是高风险的，需要终止，不执行第 5 个步骤；增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。放行交易，即本次交易是安全的，可以继续往下走。
4. 生成交易订单
将订单信息持久化到数据库中。当访问压力大的时候，数据库写入会成为一个瓶颈。
5. 调用支付渠道提供的服务
所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单，可以直接返回结果。而一些第三方支付，支付宝，微信支付等，则会通过异步接口来告知支付结果。
6. 更新订单
对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。
7. 发送消息
通过消息来通知相关系统关于订单的变更。风控，信用 BI 等，都需要依赖这数据做准实时计算。
8. 异步通知
如上述流程，其中涉及到调用远程接口，其延迟不可控。如果调用方一直阻塞等待，很容易超时。引入异步通知机制，可以让调用方在主线程中尽快返回，通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口，也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址，一般以 http 或者 https 的方式。这就有技术风险，如果调用失败，还需要重试。而重试不能过于频繁，需要逐步拉大每一次重试的时间间隔。在异步处理程序中，订单根据处理结果变更状态后，也要发消息通知相关系统。
支付系统架构整体设计
每个公司根据其业务和公司发展的不同阶段，所设计的支付系统也会有所不同。我们先看看互联网公司的一些典型的支付系统架构。
1. 支付宝
这个整体架构上并没有与众不同之处。在模块划分上，这个图显示的是最顶层的划分，也无法告知更多细节。 但支付宝架构文档有两个搞支付平台设计的人必须仔细揣摩的要点。 一个是账务处理，在记账方面，涉及到内外两个子系统，外部子系统是单边账，满足线上性能需求；内部子系统走复式记账，满足财务需求，如记账、对账和平账。
另一个是柔性事务处理，利用消息机制来实现跨系统的事务处理，避免数据库锁导致的性能问题。
2. 京东金融
京东金融是在网银在线的基础上发展起来的。 网银在线的原班技术人员有不少来自易宝公司，在京东收购之后，又引入了支付宝的人才，因而从架构上受这两个公司的影响很大。
3. 去哪儿
这些架构文档全部来自互联网公开资料， 对于架构是否真实反映实际系统情况，需要大家自行判断。 咱们仅是以这些文档为基础，分析支付系统应有的软件架构。
参考架构
一般来说，支付系统典型架构会包含如下模块：
支付系统从架构上来说，分为三层;
- 支撑层： 用来支持核心系统的基础软件包和基础设施， 包括运维监控系统、日志分析系统等。
- 核心层： 支付系统的核心模块，内部又分为两个部分： 支付核心模块以及支付服务模块。
- 产品层： 通过核心层提供的服务组合起来，对最终用户、商户、运营管理人员提供的系统。
1. 支撑系统
支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统：
- 运维监控： 支付系统在运行过程中不可避免的会受到各种内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有 bug 等等，运维人员必须在第一时间内对这些意外事件作出响应，又不能够一天 24 小时盯着。这就需要一个运维监控系统来协助完成。
- 日志分析： 日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。
- 短信平台： 短信在支付系统中有重要作用，如身份验证、安全登录、找回密码、以及报警监控，都需要短信的支持。
- 安全机制： 安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。
- 统计报表： 支付数据的可视化展示，是公司进行决策的基础。
远程连接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等，都是构建大型系统所必须的基础软件，这里不再一一详细介绍。
2. 支付核心系统
支付核心系统指用户执行支付的核心流程，包括：
- 用户从支付应用启动支付流程；
- 支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付；
- 支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付；
- 支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作，最终落地资金转移。
3. 支付服务系统
支持支付核心系统所提供的功能，服务系统又分为基础服务系统、资金系统、风控和信用系统。
基础服务系统提供支撑线上支付系统运行的基础业务功能：
- 客户信息管理：包括对用户、商户的实名身份、基本信息、协议的管理；
- 卡券管理： 对优惠券、代金券、折扣券的制作、发放、使用流程的管理；
- 支付通道管理: 通道接口、配置参数、费用、限额以及 QOS 的管理；
- 账户和账务系统： 管理账户信息以及交易流水、记账凭证等。这里的账务一般指对接线上系统的账务，采用单边账的记账方式，内部账记录在会计核算系统中。
- 订单系统： 一般订单系统可以独立于业务系统来实现的，这里的订单，主要指支付订单。
资金系统指围绕财务会计而产生的后台资金核实、调度和管理的系统，包括：
- 会计核算： 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。
- 资金管理： 管理公司在各个支付渠道的头寸，在余额不足时进行打款。 对第三方支付公司，还需要对备付金进行管理。
- 清算分润： 对于有分润需求的业务，还需要提供清分清算、对账处理和计费分润功能。
风控系统是支付系统必备的基础功能，所有的支付行为必须做风险评估并采取对应的措施；信用系统是在风控基础上发展的高级功能，京东的白条，蚂蚁花呗等，都是成功的案例。
4. 支付应用
支撑系统、核心系统和服务系统，在每个互联网公司的架构上都是大同小异的，都是必不可少的模块。而支付应用是每个公司根据自己的业务来构建的，各不相同。
总体来说，可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI 和风控后台。
http://www.uml.org.cn/zjjs/2021041512.asp?artid=23863
中国支付体系的塔尖是人行二代支付清算体系，人行二代支付体系塔尖是清算账户中心SAPS；支付的基础是账户，账户的账户是SAPS；为了更好的认认识支付——下面我们就从用户触发，跟着一笔支付遍历整个互联网支付网络，对支付有一个最大宏观视角的认知！
2.互联网支付总架构-看问题的宏观视野
我们对中国整个互联网支付按照参与者进行分层
4.1服务平台的支付架构
刚才我们说从京东买了一本书，那么京东商城的支付架构是怎么样的呢！刚才我买书支付的那笔钱怎么流转呢？
选好商品提交订单以后，平台在订单中心完成订单的创建，订单在交易中心完成账单的创建；我们操作去支付，交易请求支付获得收银台链接，给到订单，订单再将收银台链接返回给我们，这时候我选择了用招商信用卡支付，输入支付密码，一瞬间支付成功！
其实这几秒钟整个支付的链条跋山涉水，翻山越岭经历千险
4.2支付架构解析
我们看上面的架构图，对于一个服务平台的支付架构，一般有图中的相关系统组成：直面用户的收银台，记录业务的订单系统，推动交易的交易系统，对支付指令进行处理的支付系统，支付指令传送通道的支付通道子系统；
另外支付成功后还有一条线清结算线：支付成功以后交易将数据提交清算中心完成数据的清分计算，然后提交账务系统完成记账；再通知会计核心完成内部账的记录；最后通知资金平台对交易向商家进行货款的结算......
这样对于一个服务平台来说，一个支付的骨架就出来了！
这个架子是陈老师多年游历访学的精华沉淀；基本适用于美团，去哪儿，滴滴等，如果你要从零到一做一套支付体系，那么这么规划基本没什么问题
好我们接着往下说，我们支付商家的支付都需要接入一个支付机构的，支付系统通过支付通道将支付请求提交给了签约的支付服务提供方，我们以三方支付为例，比如京东将支付提交给了网银在线！那么网银在线内部又是怎么处理的呢？走起
5.第二层三方支付体系……好支付让交易更安全
支付机构作为拥有支付牌照，为服务平台提供支付解决方案的企业，也有着自己复杂而庞大的支付体系，我们常听说的比如各类收银台，支付产品，支付路由，支付通道，支付核心，账务核心，清算核心，风控核心，商户入网等等；对于支付机构来说支付产品的创新满足支付市场需要是至关重要的，支付产品创新主要聚焦在下面几个维度
.1支付机构的支付架构
那么对于一个支付机构来说，他们的支付架构是什么样的呢？比如刚才支付请求到了支付机构，这笔支付在支付机构会怎么流转和处理呢？
我们在网上可以看到很多支付机构的架构图，上面这个稍微简单点架构图基本涵盖了一家支付机构应该具备的基础能力；比如交易层对交易请求进行处理；支付层对支付请求进行处理；渠道层对支付请求进行提交金融机构或者清算机构完成最后的清算请求指令的提交
既然都是支付，我们可以换个思路，其实支付机构的支付架子跟服务平台的架子在某些角度看大同小异；只不过是服务用户对象一个是用户一个是商户，支付通道一个是三方机构提供，一个是银行提供
5.2支付机构架构解析
好了，我们来看支付请求来到了三方支付机构之后....
第一个门槛就是到达支付机构的网关层，通过各种风控校验通过许可，来到开放平台，开放平台将支付请求提交给交易处理层进行处理，首先到达订单系统，创建订单后请求支付系统获得收银台链接，返回给开放平台；开放平台处理支付通过收银台请求支付系统进行支付处理......
支付处理中心对支付请求进行处理，通过路由选择合适的支付渠道，然后由渠道清算封装支付指令，通过支付通道提交清算指令给清算机构或者银行
清算机构返回清算成功后，支付处理中心通知订单中心支付成功，订单中心将支付单提交给清算中心进行清结算处理，完成计费，账务记账，入账等处理操作
这样我们整个架子就出来了
经过丰富美化之后，我们就得到了一个支付机构最基本的支付流程架构
如果你不小心捡了一个支付牌照，那么拿着陈老师的图，去搭建你的支付公司吧；支付机构将支付清算指令提交给了清算机构，因为现在断直连了嘛，不能直接接入银行了；断直连后其实银联网联网关于支付清算的处理是一样的，那么我们以网联为例，看看支付指令到了网联之后会怎么样的呢！骑上小摩托走起！
6.第三层网银联清算体系……好清算让市场更和谐
陈老师有幸参与了支付机构断直连接入网联的盛世，参与了很多场网联的会议，惊叹于断直连后的清算架构！！！我们先看这张图，从宏观上认知这几个角色之间的关系
为解决备付金集中存管所形成的热点账户问题，实现对已映射额度管理，网联将构建“备付金热点账户前置系统”RCMP，用于支付机构通过网联平台（EPCC）的业务办理。前置系统分为额度管理模块及账户管理模块，网联将为各支付机构在前置系统中建立账户，用于可用额度的监控、已映射额度的管理。
支付机构的指令到了网联以后，网联进行实时清算，什么意思呢，就是实时的对支付指令进行轧差变更可用余额，针对网联的文章我们说的比较详细，这里就不过多介绍了，简单的说就是支付机构将人行备付金的余额映射分配给网联和银联形成映射虚拟额度，用于交易周期内的实时清算；然后定时提交人行进行资金的划拨结算，这个框架是这样的
6.1清算概念
其实断直连以后网银联的清算变得大道至简了很多，当然说到清算我们还是有必要说一下银联这个老牌清算机构的清算架构的，再说清算之前，我们先开个小灶课，介绍下清结算相关的之歌比较重要的概念
支付结算是指单位、个人在社会经济活动中使用票据、信用卡和汇兑、托收承付、委托收款等结算方式进行货币给付及其资金清算的行为。银行是支付结算和资金清算的中介机构。
支付清算是指支付指令的交换和计算；支付指令是指参与者以纸质、磁介质或电子形式发出的，办理确定金额的资金转账命令; 支付指令的交换是指提供专用的支付指令传输路径，用于支付指令的接收、清分和发送；支付指令的计算是指对支付指令进行汇总和轧差；参与者是指接受支付清算组织章程制约，可以发送、接收支付指令的金融机构及其他机构。
银联的支付清算包括淸分和资金划拨两个环节。淸分是指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？资金划拨是指通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。
6.2银联的清算架构
银联的支付清算包括跨行清算和收单清算。跨行清算是针对收单机构和发卡机构的清算；收单清算是代替收单机构针对商户和收单专业化服务机构的清算。
银联清算系统主要就是三个核心：跨行清算子系统，收单清算子系统，资金管理平台
6.3银联的清算关系
清算离不开一个核心，那就是清算账户，所有的支付以及清算都是基于账户进行账务处理；清算账户与结算账户不是同一概念，两者的区别源于【清算】 与【结算】的区别。银联境内清算的清算账户均开立在人民银行，跨境业务的清算账户开立在代理清算银行（中行和汇丰）。境内成员机构的清算账户均开立在人民银行。银行一般在人民银行开立有准备金账户，一般使用其备付金账户用于和银联的清算。境内商户的结算账户开在商业银行，第三方机构的结算账户均开立在人民银行。
银联如何进行资金的划拨呢；境内的跨行清算通过央行的大额支付清算系统，完成资金划拨。银联可以主动借记或贷记成员机构的清算账户账户。通俗地讲，借记就是我问别人要钱，贷记就是我给别人钱。境内的收单清算可以通过央行的小额支付清算系统完成资金划拨。
银联清算系统与大小额支付清算系统的关系，无论是跨行清算还是收单清算，银联都是作为一个特许参与者，加入大小额支付清算系统，完成银行卡交换业务的资金划拨。银联通过大额支付系统，实现与境内成员机构清算账户之间的双向资金转移。银联通过小额支付系统和当地的票据交换系统，实现与境内第三方机构和商户之间的单向资金转移。
银联清算系统与银行结算系统的关系，银联和商业银行都是作为参与者，加入大小额支付清算系统，完成跨行间的资金划拨。银联清算系统的清算对象是成员机构、第三方机构和直联商户。商业银行结算系统的结算对象是在其本行开立存款账户的单位或个人。 银联在央行开立的清算账户从本质上说应属于备付金账户；而商业银行在央行开立的清算账户分准备金账户和备付金账户。 准备金账户主要用于监管使用，用于包括存款人合法权益；备付金账户主要用于自身的资金头寸的管理。
银联清算系统与银联会计核算系统的关系，银联清算系统处理的是银行卡交换的清算资金。银联会计核算系统处理的是银联的自有资金，其中自有资金中包括了银联自己清算账户上的资金余额。银联会计核算系统是按照企业会计准则，使用总分户账，登记账户变动及资金转移信息。银联清算系统仅建立了清算资金的台账信息。
6.4清算案例
我们看一个清算案例；张三6月1日持招行贷记卡，在物美超市（直联商户，工行收单）成功刷卡购物1000元。李四用工行借记卡，在华夏银行布放的支付易终端上，成功缴付了一笔200元的电费，华夏银行收单。假设消费交易执行交换费0.7%，转接费0.1%；缴费交易执行交换费0.10元，转接费0.05元。收单行与商户的扣率实际分别为1%和0.08%(这两个数字没用到)。简化起见不计算收单专业化服务机构的手续费。淸分结果
1.6月1日晚11：00CUPS日切。将交易日志发送跨行清算系统。在6月2日凌晨首先进行跨行转接交易的淸分，然后进行收单处理业务的淸分
2.6月2日上午10：00左右，将汇总的淸分结果，通过资金管理平台和支付前置系统发出支付指令。先借记后贷记，按优先级排队。
3.通过大额系统借记银行在央行开立的备付金账户，实时完成跨行清算的资金转移（借记招行993元、借记工行197.9元）；通过小额系统贷记商户开立在银行（一般为工行）的结算账户（990元）（6月2日中午左右到账）；通过大额贷记银行在央行开立的备付金账户，实时完成跨行及收单清算（贷记华夏199.85元）。
4.华夏银行收到银联划付的资金后，通过本行的行内结算系统，贷记间联商户的结算账户（199.84元，华夏收单收益0.01元，约6月 3日到账）；工行和招行或调整持卡人的可用余额（联机交易时银行已实时扣减了持卡人的账户余额或可用额度）。
6.5通用清算机构架构
那么一个清算机构，会拥有什么样的架构呢，这个更细维度的架构大家作为了解，上面的宏观维度的认知已经足够了，虽然社群后不少来自网联银联的朋友，但我相信大部分同学是不会去这样的机构的，所以一眼带过就可以了
我们知道网联银联将支付机构的结算指令提交人行进行最终的资金划拨，完成各参与主体之间的资金实际交割；那么在将人行之前，我们先看看接入网联银联的商业银行的支付架构是什么样的呢
7.第四层银行金融体系……好金融让支付更丰富
银行相当于服务平台，三方支付机构以及网联这样的清算机构是有很大不同的，首先是业务的不同，银行处理提供互联网支付通道以外，还有门店，ATM，银行卡，存款业务，贷款业务，理财业务等等
我们简化一下
抛开繁多的银行其他业务，我们来看银行跟互联网支付相关的业务架构是怎么样呢，不用说我相信大家也猜到了，肯定会有账户，有支付核心，有通道，有前置系统
我们再看下更宏观的一个，像图中的其他渠道我们可以理解为提供给网联银联或者支付公司的支付通道，接入银行进行支付请求，然后银行请求人行
好了，下面我们要去朝圣了，到达支付的顶层设计-人民银行二代支付系统！走起
8.第五层人行支付体系……好基础让支付更
我们都知道中国支付系统经历了支付一代系统和支付二代系统；为整个中国互联网支付提供清算基础设施；那么这个神秘的支付体系拥有如何神奇的架构呢，在开始之间我们来看一个非常经典的架构图：中国清算系统
最组边的就是网联银联以及三方支付机构所处的位置，上面的就是我们要讲的人行部分，下面是商业银行所处的位置；其中网联银联和商业银行直联央行的支付清算系统；我们来看整体的业务架子就是下面这张图，各参与者连接到NPC就是国家处理中心，包含了大小额支付系统和网银互联跨行支付系统（超级网银），然后NPC经过支付指令的处理之后提交清算账户中心（SAPS）进行资金的清算划拨
8.1几个核心系统
我们来看二代支付系统最核心的几个系统，大家从我的支付体系全解析目录中也看到了，人行部分会对每个系统做详细介绍，这里我们就一带而过，主要是知道一个大概
以清算账户管理系统为核心，大额支付系统、小额支付系统、支票影像交换系统、网银互联子系统为业务应用子系统，公共管理控制系统和支付管理信息系统为支持系统。我们来认识一下这几个系统
清算账户管理系统(SAPS)：是支付系统的核心系统，通过集中存储和管理清算账户，完成支付系统各类业务的资金清算，并为中央银行办理现金存取、再贷款、再贴现等业务提供清算服务；各银行，支付机构，网联银联都会在这里开通清算账户，进行资金的清算
大额支付系统，小额支付系统，网上支付跨行清算系统就是我们所理解的支付系统，接受参与者的清算支付指令，进行指令的处理并提交给清算账户管理系统完成资金划拨
支付信息管理系统：是中国现代化支付系统的辅助支持系统，由行名行号管理子系统、参数管理子系统、计费管理子系统、支付业务统计分析子系统、支付业务监控子系统等六个子系统组成，是一个多功能模块的、集中式的支付信息共享平台。
8.2系统的运行控制
各系统的运行时序图
我们来看一下各系统之间的运行是如何进行控制的
8.3支付清算处理
然后我们来看网联将结算请求提交给人行支付系统之后，支付系统对指令进行处理之后提交清算账户系统完成最终的资金划拨；也就是这个时候陈老师买书的钱才真正从招商的清算账户进入到网银在线的备付金账户中
到这里我们就将整个支付大厦的每一层参与者的架构都做了一个宏观的认识，现在你是不是已经知道了，一笔支付要经历多么漫长的链条了吧，最后我们将所有的参与者架构拼接到一起，来看这座美丽奢华的支付大厦
9.遨游支付
我们将所有的支付参与者，也就是每一层的职能和架构都做了介绍，那么跟着陈老师来遨游一下一笔支付的神奇之旅吧！
