图解支付系统设计与实现：在线支付系统最核心的概念和设计理念

一、十年前各大公司支付系统架构图

看一下十年前各大互联网公司支付系统架构图，就会发现最基础的偏底层的那部分到现在也很有参考价值，但是性能、可用性、基础架构等已经发生了天翻地覆的变化。

比如根据公开资料，2019 年双11 支付宝的支付峰值为54.4 万笔/秒，真实承载能力应该远高于此。创新的业务也发生了极大的变化，比如京东白条的横空出世，在海外旅游可以直接用支付宝或微信扫码付款等。

晒几个网上公开的图（来源在图片右下角的水印上有，版权归原作者），图虽然有点老，但基础的产品功能到现在也适用。

某团的：

某Q旅游的：

某东金融的：

某蚁金服的：

二、基本概念

下面描述的概念大部分做了极致简化，只是用于入门，对于理解概念应该是够用的。真实的实现会复杂非常多。

这些概念如同支付核心系统拼图的一些小碎片，串起这些小碎片，就是一个完整的支付系统大图。

另：后面的描述中，经常混着用“支付系统”、“支付平台”，“支付机构”，“收单机构”，本质是一个东西。在内部来说，就是一个支付系统，但从和外部机构交互来说，就是一个支付平台。对用户来说是支付，对商户来说就是帮商户收单。

2.1. 最简支付流程

记账步骤：

说明：

1. 持牌支付机构的记账一定是复式记账法。内部开设了很多账户和科目。

• 【借记类】账户：资产，应收款等；
• 【贷记类】账户：负债，所有者权益，应付款等；

2. 借贷简要公式（不太严谨，但是够用）：

• 【借记类】账户（如资产，应收款），【增加】为【借】，【减少】为【贷】；
• 【贷记类】账户（如负债和所有者权益，应付款），【增加】为【贷】，【减少】为【借】；

3. 复式记账的专业书籍很多，这里只摘录几个重要的说明：

• 复式记账法定义：对每项经济业务按相等的金额在两个或两个以上有关账户中同时进行登记的方法。
• 记账原则：有借必有贷，借贷必相等。
• 记账依据：会计恒等式：1. 资产 = 负债 + 所有者权益；2. 利润 = 收入 – 费用。
• 账户：具有一定格式和结构，能够用来连续、系统、全面的记录反映某种经济业务的增减变化及其结果。
• 科目：同类财务交易的分类，比如资产、负债、所有者权限、收入或费用等都属于科目。一般科目会分为多级。
• 账户和科目的区别：科目只有名字，账户包括结构和格式，每个账户对应一个特定的科目。

2.12. 账户分类

1. 制定适用于公司业务的Money类来统一处理金额。
2. 在入口网关接收到请求后，就转换为Money类。
3. 所有内部应用的金额处理，强制全部使用Money类运算、传输，禁止自己手动加减乘除、单位换算（比如元到分）。
4. 数据库使用DECIMAL类型保存，保存单位为元。
5. 在出口网关外发时，再根据外部接口文档要求，转换成使用指定的单位。有些是元，有些是分（最小货币单位）

6.6. 业务ID生成规则

数据库一般都会设计一个自增ID作为主键，同时还会设计一个能唯一标识一笔业务的ID，这就是所谓的业务ID（也称业务键）。比如收单域的收单单号。

也有人采用所谓雪花算法，但其实不适用于支付场景。

下面以32位的支付系统业务ID生成为例说明。实际应用时可灵活调整。

第1-8位：日期。通过单号一眼能看出是哪天的交易。

第9位：数据版本。用于单据号的升级。

第10位：系统版本。用于内部系统版本升级，尤其是不兼容升级的时候，老业务使用老的系统处理，新业务使用新系统处理。

第11-13位：系统标识码。支付系统内部每个域分配一段，由各域自行再分配给内部系统。比如010是收单核心，012是结算核心。

第14-15位：业务标识位。由各域内部定，比如00-15代表支付类业务，01支付，02预授权，03请款等。

第16-17位：机房位。用于全球化部署。

第18-19位：用户分库位。支持百库。

第20-21位：用户分表位。支持百表。

第22位：预发生产标识位。比如0代表预发环境，1代表生产环境。

第23-24位：预留。各域根据实际情况扩展使用。

第24-32位：序列号空间。一亿规模，循环使用。一个机房一天一亿笔是很大的规模了。如果不够用，可以扩展到第24位，到十亿规模。

6.7. 状态机设计

状态机，也称为有限状态机（FSM, Finite State Machine），是一种行为模型，由一组定义良好的状态、状态之间的转换规则和一个初始状态组成。它根据当前的状态和输入的事件，从一个状态转移到另一个状态。

下图就是收单子域设计中交易单的状态机设计。

从图中可以看到，一共4个状态，每个状态之间的转换由指定的事件触发。

常见代码实现误区

经常看到工作几年的同事实现状态机时，仍然使用if else或switch case来写。这是不对的，会让实现变得复杂，且容易出现问题。

甚至直接在订单的领域模型里面使用String来定义，而不是把状态模式封装单独的类。

还有就是直接调用领域模型更新状态，而不是通过事件来驱动。

限于篇幅，这里就不给正确的示例了。有兴趣的可以去网上看看，良好的示例有很多。

6.8. 日志规范

只要在公司写过代码，就一定打印过日志，但经常发现一些工作多年的工程师打印的日志也是乱七八糟的。我曾经在一家头部互联网公司接手过一个上线一年多的业务，相关日志一开始就没有设计好，导致很多监控无法实现，出了线上问题也不知道，最后只能安排工程师返工改造相关的日志。

我们要明白日志是用来做什么的。只是先弄明白做事的目的，我们才能更好把事情做对。在我看来，日志有两个核心的作用：1）监控，诊断系统或业务是否存在问题；2）排查问题。

对于监控而言，我们需要知道几个核心的数据：业务/接口的请求量、成功量、成功率、耗时，系统返回码、业务返回码，异常信息等。对于排查问题而言，我们需要有出入参、中间处理数据的上下文、报错的上下文等。

接下来，基于上面的分析，我们就清楚我们应该有几种日志：

1. 接口摘要日志。监控接口的请求量、成功量、耗时、返回码等。使用固定格式，需要打印：时间、接口名称、结果（成功/失败)、返回码、耗时等基本信息就足够。
2. 业务摘要日志。监控业务的请求量、成功量、核心业务信息、返回码等。使用固定格式，需要打印：时间、业务类型、上一步状态、当前状态、返回码、核心业务信息（不同业务有不同的核心业务信息，比如流入，就有支付金额/退款金额，卡品牌，卡BIN等)。
3. 详细日志。用于排查问题，不用于监控。格式不固定。主要包括时间、接口、入参、出参、中间处理数据输入、异常的堆栈信息等。
4. 系统异常日志。同时用于监控。格式固定。需要打印：时间、错误码、错误信息、堆栈信息等。

6.9. 支付安全

支付安全核心关注点

支付安全是一个很大的范畴，但我们一般只需要重点关注以下几个核心点就够：

1）敏感信息安全存储。

对个人和商户/渠道的敏感信息进行安全存储。

个人敏感信息包括身份证信息、支付卡明文数据和密码等，而商户/渠道的敏感信息则涉及商户登录/操作密码、渠道证书密钥等。

2）交易信息安全传输。

确保客户端与支付系统服务器之间、商户系统与支付系统之间、支付系统内部服务器与服务器之间、支付系统与银行之间的数据传输安全。这包括采用加密技术等措施来保障数据传输过程中的安全性。

3）交易信息的防篡改与防抵赖。

确保交易信息的完整性和真实性，防止交易信息被篡改或者被抵赖。一笔典型的交易，通常涉及到用户、商户、支付机构、银行四方，确保各方发出的信息没有被篡改也无法被抵赖。

4）欺诈交易防范。

识别并防止欺诈交易，包括套现、洗钱等违规操作，以及通过识别用户信息泄露和可疑交易来保护用户资产的安全。这一方面通常由支付风控系统负责。

5）服务可用性。

防范DDoS攻击，确保支付系统的稳定运行和服务可用性。通过部署防火墙、入侵检测系统等技术手段，及时发现并应对可能的DDoS攻击，保障支付服务的正常进行。

极简支付安全大图

支付安全是一个综合性的系统工程，除了技术手段外，还需要建立健全的安全制度和合规制度，而后两者通常被大部分人所忽略。

下图是一个极简版的支付安全大图，包含了支付安全需要考虑的核心要点。

说明：

1）制度是基础。

哪种场景下需要加密存储，加密需要使用什么算法，密钥长度最少需要多少位，哪些场景下需要做签名验签，这些都是制度就明确了的。制度通常分为行业制度和内部安全制度。行业制度通常是国家层面制定的法律法规，比如《网络安全法》、《支付业务管理办法》等。内部安全制度通常是公司根据自身的业务和能力建立的制度，小公司可能就没有。

2）技术手段主要围绕四个目标：

1. 敏感数据安全存储。
2. 交易安全传输。
3. 交易的完整性和真实性。
4. 交易的合法性（无欺诈）。

对应的技术手段有：

• 敏感信息安全存储：采用加密技术对个人和商户/渠道的敏感信息进行加密存储，限制敏感信息的访问权限，防止未授权的访问和泄露。
• 交易信息安全传输：使用安全套接字层（SSL）或传输层安全性协议（TLS）等加密技术，确保数据在传输过程中的机密性和完整性。
• 交易的完整性和真实性：采用数字签名技术和身份认证技术确保交易信息的完整性和真实性，对交易信息进行记录和审计，建立可追溯的交易日志，以应对可能出现的交易篡改或抵赖情况。
• 防范欺诈交易：通过支付风控系统，及时识别和阻止可疑交易行为。
• 服务可用性：部署流量清洗设备和入侵检测系统，及时发现并阻止恶意流量，确保支付系统的稳定运行和服务可用性，抵御DDoS攻击。

七、结束语

所谓提纲挈领，就是先掌握核心主干，有了这个前提，再去深入了解细节，才不至于“乱花渐欲迷人眼”，解决问题时才能如庖丁解牛，行云流水。伟人邓公提倡的“抓住主要矛盾”，也是这个道理。

本文主要讲了一些支付核心系统相关的基本概念，希望能为大家在学习在线支付系统相关知识时能提供一些有益的参考。

犹记得N年前那天早上，我穿上最帅的衬衣、笔挺的西装裤、贼亮的皮鞋，推开房门，清风徐来，朝阳灿烂，一如我的心情，意气风发。那是我进入正值蓬勃发展的第三方支付行业的第一天。

入职当天老板扔了很多文档给我，看了一周，没看懂。想起老祖宗说的“读书百遍，其义自见”，继续苦读一周，仍然是雾里看花。不幸中的万幸，是挺过了试用期。直到多年后的一天，整理老旧硬盘的资料，才发现一方面是自己愚钝，另一方面也是那些资料写得过于晦涩难懂。于是萌发一个念头：要不我自己也总结总结？这是其中的一篇。

斗转星移，外面的阳光依然灿烂，衬衣、西装裤、皮鞋却已不知何处去了。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！