【支付系统设计从0到1】支付系统流程和典型架构设计

支付业务的核心流程

1.支付应用根据用户选择的支付工具来调用对应的支付产品来执行支付。

2.支付产品通过支付网关根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付。

3.支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作，最终落地资金转移。

支付系统的典型架构

支付工具

支付工具是由银行或者其他支付机构发行的，能够发起支付指令，用于债务清偿或者资金转移的证件，比如支票、汇票、本票、银行卡等。

在金融机构中，支付工具一般分为三类：

贷记支付工具：资金被划入银行应收账户

借记支付工具：结算资金转移反映在银行账户上是债务的减少

通用支付工具：银行卡、电子支付(例如微信、支付宝)

支付应用

狭义来讲是指提供给最终用户在特定场景下使用的产品。

比如扫码收银、二维码支付、打赏、众筹、POS支付、生活缴费、信用卡返款、手机充值等。 这些应用是建立在支付产品的基础之上，直接面向最终的用户提供服务。

广义来讲支付系统安全，可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI和风控后台等。

支付核心系统设计原则

支付网关、支付产品和支付渠道的职责分工为：

1.按照支付能力来划分支付产品。

2.同一支付能力的公共支付流程，在支付产品中实现。 支付产品提供的是和支付渠道无关的、和支付能力流程相关的功能。

3.支付产品中，和支付能力无关的公共功能，在支付网关上实现。

支付网关

支付网关是对外提供服务的入口，它将支付产品接口中和业务无关的功能提取出来，在这里统一实现，支付网关本身并不执行任何支付相关的业务逻辑。

在支付网关上实现的主要功能：

API路由。在聚合支付场景下，当有多个支付产品可以提供支持时，使用支付网关可以让接入方对接时无需考虑支付产品的部署问题。

接口安全： 熔断、限流与隔离。 这对支付服务来说尤为重要。 这是微服务架构的基本功能，本文不做描述。

支付产品

支付产品模块是按照支付场景来为业务方提供支付服务，在架构上位于支付网关之后，支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口，通过支付网关来对外提供服务。所以，从微服务的角度，支付产品本身也是一个代理模式的微服务，它透过支付网关响应业务方请求， 进行一些统一处理后，分发到不同的支付渠道去执行，最后将执行结果做处理后，通过支付网关再回传给业务方。

支付产品中实现的主要功能：

风控拦截： 风控是和支付产品有关，不同产品的风控措施、处理对策也是不同的，所以风控是在产品层实现。

支付路由： 路由也是和产品有关。不同产品路由策略也不同。

参数校验： 这也是和支付产品相关的，不同的产品接口其参数也不同。

支付流程： 生成交易记录、落地渠道执行支付、同步和异步通知等操作。

如下功能，可以在产品层也可以在网关层实现：

身份验证： 确认付款方、收款方、渠道是否有执行当前操作的权限。 在那一层实现取决于这些信息是否有提炼为公共行为。

验签： 对接口参数进行签名并验证其签名。这是为了避免接口被盗刷和篡改的必要手段。如果对各个接口采用统一的签名规则，则可以在网关层实现。

支付渠道

支付渠道模块是调用支付渠道接口执行真正的资金操作。

支付核心系统交易请求数据流

1.支付请求被发送到支付网关。网关对这个请求进行一些通用的处理，比如QPS控制、验签等，然后根据支付请求的场景（网银、快捷、外卡等），调用对应的支付产品。

2.支付产品对用户请求进行预处理，包括执行参数校验、根据支付路由寻找合适的支付通道、评估交易风险、生成订单、调用渠道落地执行支付、响应渠道的结果并将交易结果通知到商户侧。

3.支付产品调用支付渠道执行支付。这个请求并不是直接落地到渠道上，而是通过支付渠道前置来封装，由支付渠道前置来完成和渠道的交付。 支付产品是按照可以提供的支付服务来设计的。

4.支付渠道前置，负责和支付渠道之间的通讯，调用支付渠道接口完成最终的支付操作。

本文参考“凤凰牌老熊”、“梁川”、“路杨”、“叉一”等相关支付系统架构设计文章结合自己支付系统设计经验整理。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!