完整的支付系统总体架构！

2017-12-04 08:57:44

整理于网络

从产品分类、模块功能和业务流程，了解支付产品服务的设计。

支付产品模块是按照支付场景来为业务方提供支付服务。这个模块通常位于支付网关以后，支付渠道以前。 它根据支付能力将不一样的支付渠道封装成统一的接口，经过支付网关来对外提供服务。因此，从微服务的角度来讲，支付产品自己也是一个代理模式的微服务，它透过支付网关响应业务方请求， 进行一些统一处理后，分发到不一样的支付渠道去执行，最后将执行结果作处理后，经过支付网关再回传给业务方。支付产品在支付系统架构图中的位置，以下图所示：

产品分类

在不一样的公司因为接入渠道和应用的差别，对支付产品分类略有不一样。综合支付场景和流程，支付产品能够分为以下几类：

支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力。总体上来讲，能够提供以下支付产品：

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 和风控后台。

近期热文推荐：

1.Java 15 正式发布， 14 个新特性，刷新你的认知！！

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！

3.我用 Java 8 写了一段逻辑，同事直呼看不懂，你试试看。。

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

以为不错，别忘了随手点赞+转发哦！