如何设计一个支付系统丨架构师系列文集

社区里缺的不是架构图，而是可供参考的架构实践。程序员缺的不是技术原理知识，而是抽象来的可供复用的方案思路。为了切实帮助技术人成长，在信息爆炸时代获取最精华的架构知识，腾讯云开发者携手腾讯云架构师技术同盟推出架构师系列文集，每期会以《如何设计一个 XX 系统》为主题，分享同盟架构师们多年经验抽象来的经典方案设计思想。

本文是系列第一篇，我们聊聊支付系统的经典设计。除了作为普适方案的本文，作者还准备了上中下三篇信息密度更丰富、细节更详实的雄文，各位读者朋友一定持续关注腾讯云开发者公众号，不错过后续更新。

概述

支付系统在电商交易平台中发挥着至关重要的作用，涵盖了支付处理、安全性保障、支付方式管理、订单管理与结算、交易记录和报告、退款与售后支持等方面。一个高效、安全、可靠的支付系统对于电商企业的顺利运营和用户体验至关重要。

02

支付系统/核心交易系统的架构特点

2.1 支付系统的作用

图片

从上图中我们可以看出真实的资金流向。首先当用户产生支付行为时，资金从用户端流向支付系统，退款时则相反，从支付系统回流至用户端。因此在整个交易过程中用户端与支付系统是双向资金的流动方式。对于支付系统而言，资金有进有出。从支付系统到商户端就比较简单了，在清算完成后支付系统负责将代收的资金结算给商户，通常结算的操作可以在线上来完成（采用支付公司代付接口或者银企直连接口来完成），也可以由公司财务通过线下手工转账的方式来完成，因此这种资金流动的方式是单向的。出于资金安全考虑，大多数公司通常这部分采用线下方式实现。

真实的资金流由支付公司按照约定期限（通常 T+1 ）结算到平台公司对公账户中，然后再由平台公司再按照交易明细进行二次清算后结算给对应的商户。

2.2 支付系统的架构

2.2.1 架构概述

图片

系统说明

1. 支付网关：支付网关是连接不同支付渠道和商户系统的中间平台，负责接收来自商户的支付请求，然后将请求传递给相应的支付渠道或支付核心，以完成支付过程。
2. 收银台：用户在进行线上购物或支付时，通过进入一个页面来完成支付的过程。用户可以在收银台上选择支付方式、输入支付信息，并进行支付操作。收银台通常是支付网关的一部分。
3. 交易系统：业务发起支付时，支付系统与业务方的前置模块，主要用于对业务的校验、接单、查询请求等处理。
4. 支付核心：支付核心是支付系统的核心引擎，负责处理支付过程中的各种交易请求，包括接收支付请求、交易处理、资金结算等。
5. 商户系统：商户系统是为商户提供的管理支付交易、查询交易数据、配置支付选项等功能的管理平台。商户可以通过商户平台来管理自己的支付业务。
6. 补偿系统：补偿系统通常用于处理支付过程中出现的异常情况，例如支付失败、订单取消等情况，需要对相关方进行补偿或调整。
7. 清结算系统：清结算系统负责处理支付过程中的结算动作，确保资金结算到位，包括向商户结算款项，同时也负责向渠道支付相应的手续费等。
8. 对账系统：对账系统用于进行不同支付系统之间的数据对账，以确保交易数据的准确性。它会对支付核心、商户平台、清结算中心等各个组件的数据进行对比，防止数据出现异常。
9. 会计系统：会计系统用于处理支付过程中产生的会计核算相关的数据，确保资金的正确流转和账务处理，保证支付过程中的财务准确性。
10. 财务系统：财务系统用于整体管理和监控支付过程中的资金流动和资金状况，帮助企业进行财务决策和管理。
11. 运营系统：运营系统负责支付系统的日常运营管理，包括系统监控、问题处理、性能优化等，确保支付系统的稳定运行。
12. 渠道管理：渠道管理用于管理支付网关连接的不同支付渠道，包括银行、第三方支付服务提供商等，以确保支付网关可以顺利地将支付请求发送到适当的支付渠道。

2.2.2 支付系统设计要点

在支付系统中，支付网关和支付渠道的对接确实是非常重要且繁琐的功能之一。支付网关作为对外提供服务的接口，扮演着将资金操作请求分发到对应支付渠道模块的角色。支付渠道模块则负责接收网关的请求，并调用相应支付渠道的接口执行真正的资金操作。

支付网关在这个过程中类似于设计模式中的“wrapper”，它封装了各个支付渠道之间的差异，为网关提供了统一的接口。这样一来，无论是哪个支付渠道，网关都能够以统一的方式与其进行交互。

支付系统对其他系统，尤其是交易系统，提供了多种支付服务，包括签约、支付、退款、充值、转账、解约等。有些地方还可能提供签约并支付的接口，以支持在支付过程中绑定银行卡的操作。这些支付服务的实现流程基本上是相似的，包括下单、取消订单、退单、查询订单等操作。

每个操作的实现通常包括以下七个步骤：

1. 参数校验：对传入的参数进行验证，确保其符合要求和规范。
2. 支付路由：根据业务规则和策略，确定使用哪个支付渠道来处理该操作。
3. 生成订单：根据业务需求，生成相应的订单信息。
4. 风险评估：对支付操作进行风险评估，以确保交易的安全性。
5. 调用渠道服务：通过支付网关调用支付渠道模块的接口，执行实际的资金操作。
6. 更新订单：根据支付结果，更新订单的状态和相关信息。
7. 发送消息：向相关系统或用户发送支付结果通知。

对于一些比较复杂的支付渠道服务，还可能涉及到异步通知和处理的步骤，以确保支付结果的及时性和准确性。

在实现支付系统时，软件工程师需要具备扎实的编程技能和对支付领域的深入理解。同时，注重细节、进行充分的测试和质量保证也是非常重要的，以确保支付系统的稳定性和安全性。此外，与团队成员和其他相关方进行良好的沟通和协作，也是成功实现支付系统的关键因素之一。

03

交易系统的链路优化

交易系统在整个支付系统中充当了连接业务前置和支付网关的桥梁，确保支付过程的可靠性、一致性和安全性。其设计和实现需要考虑各种业务场景、并发情况和异常情况，以构建一个稳定、高效的支付交易处理系统。同时交易系统还需要与其他系统进行集成，如清结算系统、风控系统等，以实现全面的支付功能和业务支持。

图片

交易系统具备如下功能：

1. 业务校验：交易核心首先会对业务方发起的支付请求进行校验，确保请求的合法性和有效性。这可能包括验证支付金额、商户信息、订单号、支付方式等，以防止恶意或错误的请求。
2. 接单：交易核心在通过校验后，会接受业务方的支付请求，即发起支付的指令。这可能涉及生成新的支付订单，将订单信息进行存储，并为后续的支付流程做好准备。
3. 查询请求处理： 除了发起支付，业务方可能还会发起查询请求，用于获取订单的支付状态、交易详情等信息。交易核心会处理这些查询请求，从数据库或缓存中检索相应的订单信息，并将查询结果返回给业务方。
4. 交互与通信：交易核心与业务方的前置模块进行通信，可能通过接口、消息队列等方式。这样的通信可以包括支付请求的传递、交易状态的更新通知等。
5. 并发和事务处理：交易核心需要处理并发的支付请求，确保数据的一致性和完整性。使用事务管理技术可以保证支付过程中的数据操作是安全的，避免数据不一致或意外的情况。
6. 异常处理：在支付过程中，可能会出现各种异常情况，如支付超时、支付失败等。交易核心需要捕获并处理这些异常，向业务前置或支付网关返回适当的错误信息，以便业务方进行相应的处理。

04

对账系统的设计

4.1 对账系统概述

对账系统或对账平台通常用于比对财务数据上的金额或订单数据的差异等，主要体现在交易的金额上。然而，这里所指的对账平台旨在成为一个更广泛的工具，一个平台化的解决方案。尽管对账的需求起源于财务对账，但目前该平台已经扩展支持多种业务领域之间不同形式的对账工作。此外，这个工具化的产品还能够支持不同业务形态下的大数据量比对。通过统一的平台建设，该对账平台使得不同业务线之间相同或相似的对账诉求能够得到统一解决，从而减少人力资源消耗和独立开发所带来的资源浪费。总体而言，这个对账平台成为一个全面且高效的工具，使得企业能够更加便捷地进行对账工作，并且满足多样化的对账需求。同时，平台化的特性也使得它更灵活适应不同业务场景，提升了数据对比的精度和效率。

对账其实就是在两个数据源当中，找出指定范围内的相同及差异的数据。对账系统都会包含三个环节：数据的采集加工，对账，以及调账。

1. 数据采集：通过将不同源的数据采集加工成标准化或易于对账的数据，为对账做准备。
2. 对账：找出两个数据源中的相同及差异化的数据输出。
3. 调账：针对对账差异化的金额结果，找出背后出现差异的原因，并进行财务上的调账操作。

图片

4.2 对账需求分析

4.2.1 对账数据间的关系

我将需要比对的两个数据源称为主数据源与目标数据源，那么通常比对的两个大数据源的数据关系会有如下的三种情况：

1. 一对一：主数据源与目标数据源表之间的数据是一对一的关系，即通过一个或多个字段的组合最多在另一张表中找到一条相应的记录。
2. 一对多：数据表中的记录是一对多的关系，即主表的记录可以在目标表中找到相应的多条记录，场景如订单表与订单明细之间的关系。
3. 多对多：主数据源表中的多条记录与目标表中的多条记录进行比对，如业务系统中的订单明细与财务系统中的结算明细数据进行比对。

当然，在不影响业务含义的情况下，针对不同的对账数据间的关系，其实都可以转化成一对一的关系进行比对。如一对多以及多对多的关系，我们都可以将数据分组汇总后，通过一对一关系进行匹配比对。

4.2.2 对账的维度

在业务的对账需求上，数据会存在下面两种情况的对账：

1. 明细对账：要求最细粒度的对账，具体到表中的每一条记录进行比对。
2. 汇总对账：只要求按照需要的维度汇总后比对总金额，总数量等汇总后的数据。

汇总对账的维度可能不只一个。例如，业务上可以按照商家和月度进行汇总后对账。也可以按照，商家及产品维度汇总后进行对账，总之汇总对账的维度其实是灵活多变的，应当完全按照不同的业务线进行配置。

4.2.3 对账结果的输出

对账结果包含了两部分，第一是交集，也就是相同的数据，第二部分是差集，也就是不同的部分，即有差异的部分。在很多的对账诉求当中，有的业务线需要输出全量的数据，即包含交集和所有差集，而有的业务线则只需要保留有差异的部分即可。因此根据不同的对账诉求，我们将对账结果输出模式设置成如下四种：

1. 全量存储：存储主数据源全量以及主/目标源之间全部差异数据。
2. 全量差异存储：仅存储两个源之间所有差异数据。
3. 主数据源差异存储：仅存储主与目标源不一致以及不存在于目标源的数据。
4. 目标数据源差异存储：仅存储不存在于主数据源以及与主不一致的目标源数据。

05

总结

支付系统的健壮性和稳定性至关重要。对于一个复杂的系统来说，监控是必不可少的。监控可以分为多个层面，包括业务监控（核心交易流程）、渠道监控（支付渠道的可用性和性能）、商户监控（商户交易状况）和账户监控（用户账户变动等）。这些监控措施可以及早发现问题，减少潜在的风险，架构设计是一个动态的过程。

作者介绍

江湖人称“山哥”，腾讯云架构师技术同盟名人堂专家、“技术方舟”主理人，专注于人工智能、互联网金融和大型电商领域，拥有丰富的架构设计和开发经验，擅长大模型调优及智能体搭建，精通TensorFlow和PyTorch等深度学习框架，具备全面的技术选型与实施能力，为企业提供高效、稳定的技术解决方案。

-End-

原创作者｜李伟山