⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7101522332883091463 「六脉神剑」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

前言

种一棵树最好的时间是十年前，其次是现在

中国互联网支付总架构

今天这篇文章就是想带大家来了解下一个从点到点，从端到端，从始到终的支付链路，最近三只松鼠的坚果不是挺火的嘛，那六六就以从京东买三只松鼠为例，带大家从整个宏观的角度来看看中国的互联网支付！

小六六要买三只松鼠，那么首先我得找一个电商平台，这边用的是京东，所以最开始的话我们接触的可能是一个电商平台
选好东西之后，六六这边就要去下单，下单完成之后，进入到了京东的收银台了，京东的收银台，包含了京东支付，微信支付，云闪付等等，支付宝目前还没看到，这些属于第三方支付，这些支付方式在中国都是需要支付牌照的。
那么这些支付方式其实接的是我们商业银行的支付通道，然后通过支付通道到了我们的银联和网联
最后到达我们的中国人民银行，也就是我们常说的央妈！绝对的食物链的顶端，所以一笔小小的支付都是经过这么多的参与方的

来看看京东支付的架构

其实这几秒钟整个支付的链条跋山涉水，翻山越岭经历千险，

支付架构解析

我们看上面的架构图，对于一个服务平台的支付架构，一般有图中的相关系统组成：直面用户的收银台，记录业务的订单系统，推动交易的交易系统，对支付指令进行处理的支付系统，支付指令传送通道的支付通道子系统。

另外支付成功后还有一条线清结算线：支付成功以后交易将数据提交清算中心完成数据的清分计算，然后提交账务系统完成记账；再通知会计核心完成内部账的记录；最后通知资金平台对交易向商家进行货款的结算……

这样对于一个服务平台来说，一个支付的骨架就出来了！

其实很多第三方支付公司都是这么玩的你比如说国内的京东支付，微信支付，海外的Paypal,Strip checkout等等

支付系统架构

支付系统的主要职责是处理业务系统发起的所有交易请求，包含收银台、交易系统、支付核心等模块，根据各模块不同的功能职责，可以将支付系统分为业务层和支付层两部分。

业务层负责为业务系统提供收付款的操作界面以及处理业务系统提交的交易请求；
支付层负责通过支付渠道实时处理完成资金的收付款、记录参与交易的账户间资金流转情况并按照预定规则对账户所属资金进行拆分与合并。

收银台

收银台即用户日常付款前选择渠道的页面，是支付平台提供的基本功能之一， 主要职责是协助业务平台完成支付交易，向用户提供一致的交易体验。一般情况下，根据不同终端类型定制标准化的收银台给到外部进行调用，保证各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。

收银台的业务场景（边界） 一般分为付款与充值两部分：

付款即通过各类支付方式针对业务订单发起付款，例如：用户在天猫店购买一件衣服，确认订单后自动跳转至支付宝，引导用户选择对应的方式（余额、花呗、银行卡等）进行付款。
充值即用户对账户进行余额充值，例如：用户登录支付宝、微信或其他商户自有钱包系统对账户余额进行充值。

交易核心

交易系统本身是作为支付系统外部处理业务逻辑的外围系统。由于支付核心系统本身并非面向业务端且业务逻辑的多变性与复杂性，支付系统为了兼顾稳定并能够为业务端提供灵活支持，因此需要在支付系统外层搭建面向业务端处理交易逻辑的交易系统。交易系统处理业务端的各种交易类型后，将业务信息转化为支付系统可识别的支付订单并导入。

以担保交易为例，C 端用户在天猫购买一件商品，成功支付后商家进行发货，用户确认收货后平台将货款结算给商家。此处设计到「担保交易支付」以及「确认收货」环节，与支付系统内部的支付与结算步骤一一对应：

用户付款成功后对应交易的付款成功状态；
用户确认收货后对应交易的成功状态。

从支付和收货缓解可以看出，担保收单交易就是讲支付系统的支付基础能力包装后对外支持业务的一款产品。

会员系统

会员系统是完整的支付平台内极其重要的基础模块之一，负责管理支付系统内部的交易主体。会员系统保存了客户在支付系统内部账号的实体信息，为客户建立了统一的、以会员 ID 为标识的会员基本信息、关系信息（会员和账户、会员和操作人、会员与银行卡）视图。

一般情况，会员在支付系统内部分为个人会员和企业会员（默认企业会员有商户权限），以电商平台为例，C 端用户为个人会员，B 端商户为企业会员：

通常，企业会员会配置一定的业务参数，比如结算周期、接口权限、支付方式配置等（开通商户权限的情况下）；
在大多数互联网公司，支付系统仅需要对接支付渠道的模块，在没有独立平台化的情况下，不太会出现需要独立的账户体系。

支付核心

支付系统的职责为通过支付核心与后端清结算、会计、账务等系统的统一协作，让前端支付产品可以更关注产品本身的逻辑，而减少对清分、对账、储值等后端服务的考量及动作；同时通过标准化的支付指令定义，统一前端支付产品的支付请求接口，提供适应各类产品使用的基础支付服务。

支付核心的边界：

支付服务：负责对后端支付系统的接口进行业务包装，同时实现使用多个支付方式进行组合支付的功能；
支付服务流程：对各支付类型的支付服务流程进行定义，具体定义为充值、提现、内转支付（转账）、退款等原子类型，并实现对基础服务的流程编排；
支付指令：发起订单后，通过协议和协议明细项加工得出支付指令，需具备进行后续操作处理的全部要素信息；
支付协议：根据产品设立支付协议，因此支付协议的关键要素包含产品码及支付编码，定义着产品的处理流程、收付款信息、对应的支付渠道信息。

账务核心

账务核心的功能为，根据前端业务系统的要求设计相匹配的账户类型、管理各类账户、记录账户资金变动等，同时，按照公司内部的财会规范提供反映各账户间交易资金变化情况的会计数据；并且负责将自身记录账务流水与支付渠道结算资金和结算流水进行核对，对对账结果中出现的差错交易进行差错处理。

清算核心

清算核心负责维护客户参与交易时的清分、结算规则，并按照已配置的规则完成交易资金的清分与结算操作。

结束

由此可见如果你要做一个第三方支付公司的，大大小小估计得建设几十个系统呢？所以来说，支付并不简单！

芋道源码 —— 纯源码解析博客

支付设计白皮书：支付系统的总架构

前言