一、支付系统结构
上图为某支付系统的模块结构图，一般来说，支付主流程会涉及到如下模块：
流程大致为：
- 商户侧应用发起支付请求。注意，这个请求一般是从服务器端发起的。比如用户在手机端提交“立即支付”按钮后，商户的服务器端会先生成订单，然后请求支付网关执行支付。
- 支付请求被发送到支付（API)网关上。网关对这个请求进行一些通用的处理，比如QPS1控制、验签等，然后根据支付请求的场景（网银、快捷、外卡等），调用对应的支付产品。
- 支付产品对用户请求进行预处理，包括执行参数校验、根据支付路由寻找合适的支付通道、评估交易风险、生成订单、调用通道落地执行支付、响应通道的结果并将交易结果通知到商户侧。
- 支付产品调用支付通道执行支付。这个请求并不是直接落地到通道上，而是通过支付通道前置来封装，由支付通道前置来完成和通道的交付。 支付产品是按照可以提供的支付服务来设计的。
- 支付通道前置，负责和支付通道之间的通讯，调用支付通道接口完成最终的支付操作。
下面分别叙述各个模块。
二、支付网关
支付网关是直接对接业务系统的接口，它本身并不执行任何支付相关的业务逻辑，它的主要功能是：
- API路由。在聚合支付场景下，当有多个支付产品可以提供支持时，使用支付网关可以让接入方对接时无需考虑支付产品的部署问题。
- 接口安全： 熔断、限流与隔离。 这对支付服务来说尤为重要。
三、支付产品
即图2中的“账户支付”、“外卡支付”等支付产品。其按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后，支付渠道之前。它根据支付能力将不同的支付渠道封装成统一的接口，通过支付网关来对外提供服务。其主要功能为：
- 风控拦截： 风控是和支付产品有关，不同产品的风控措施、处理对策也是不同的，所以风控是在产品层实现。
- 支付路由： 路由也是和产品有关。不同产品路由策略也不同。
- 参数校验： 这也是和支付产品相关的，不同的产品接口其参数也不同。
- 支付流程： 生成交易记录、落地渠道执行支付、同步和异步通知等操作。
支付网关、支付产品的职责分工为：
1.按照支付能力来划分支付产品。 2.同一支付能力的公共支付流程，在支付产品中实现。 支付产品提供的是和渠道无关的、和支付能力流程相关的功能。 3.在各支付产品中，其和支付能力无关的公共功能，在支付网关上实现。
另外，身份验证和验签功能既可能做在支付网关中，也可能做在支付产品中：
1.身份验证： 确认付款方、收款方、渠道是否有执行当前操作的权限。 在哪一层实现取决于这些信息是否有提炼为公共行为。 2.验签： 对接口参数进行签名并验证其签名。这是为了避免接口被盗刷和篡改的必要手段。如果对各个接口采用统一的签名规则，则可以在网关层实现。
支付产品分类
在不同的公司由于接入渠道和应用的差异，对支付产品分类略有不同。综合支付场景和流程，支付产品可以分为如下几类：
下面分别介绍这些支付产品。
- 快捷支付
用户在完成绑卡之后（银行接口会返回token，后续使用token来作为支付凭证），在支付的时候，不需要再输入卡或者身份信息，仅需要输入支付密码就可以完成支付。对于小额度的支付，甚至可以开通小额免密，直接完成支付。 这种支付方式不会打断用户的体验，是目前主要的在线支付方式。一般快捷支付产品是通过封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。 - 网银支付
用户在支付的时候，需要跳转到银行网银页面来完成支付。在网银页面，需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验，一般仅用于PC Web上的支付。 网银支付是封装银行提供的网银支付来实现。 - 协议支付
协议支付也称代收或者代扣，代收指渠道授权商户可以从用户的银行账户中扣款，一般用于定期扣款，不用于日常消费。比如水电煤气、有线电视费。协议支付是通过封装银行、第三方支付提供的代扣或者快捷接口来实现。 - 平台支付
使用微信、支付宝等第三方支付平台来完成支付。使用时，一般需要用户预先安装支付平台系统（手机上），注册并登录到第三方支付平台，并且已经在该平台上完成绑卡等操作（平台在服务器侧保留用户的账户信息，比如身份证号，卡号，手机号）。 由于微信、支付宝已经被大量使用，用户也产生对这些平台的信任，平台支付往往是电商公司的主要支付方式。但是这种方式相对不安全，需要向平台暴露个人信息，一旦被窃取，资金就容易被盗走。 - 外卡支付
- 话费支付
- 虚币支付
不少公司会有自己的虚拟币，比如京豆、Q币等。这些虚币也可以作为一种支付方式。 - 账户支付
也成为余额支付、零钱支付等。 指为用户建立本地账户， 支持充值，之后可以使用这个账户来完成支付。 - 信用支付
如京东的白条，蚂蚁花呗等，指使用信用账户进行透支，类似信用卡支付。 - 代付
和代扣相反，代付是平台将钱打给用户。
支付产品需要提供的接口
一般来说，支付产品需要提供如下接口：
- 签约和解约
在快捷支付、代扣等产品中，用户在使用前，需要先完成签约。签约可以在渠道侧进行，一般第三方支付采用这种方式，当电商需要接入时，让第三方给授权。 银行和银联的签约一般是在电商侧进行， 电商侧负责收集用户的信息，调用银行和银联的接口进行签约。签约后，后续的支付行为就使用签约号来进行，无需再输入个人信息。 和签约相对应，解约则是取消签约关系。 - 支付
支付是少不了的操作。 不同产品中支付行为不一样。快捷支付是在电商服务器上发起，请求渠道进行支付；网银支付则是跳转到银行支付网关上进行; 而账户支付、虚币支付，则是在本地进行的。 - 撤销和退款
有些渠道区分撤销和退款，比如银联、农行等，撤销指取消当天在渠道侧未结算的交易； 而退款仅针对已经结算的交易。有些渠道则不作区分。 - 查询签约状态
对于需要签约的交易，可以通过这个接口来查询签约状态。 - 查询订单状态
通过这个接口来查询支付清单状态以及退款的订单状态。 - 预授权
预授权交易用于受理方向持卡人的发卡方确认交易许可。受理方将预估的消费金额作为预授权金额，发送给持卡人的发卡方。预授权在一定时间后会自动撤销。 - 预授权撤销
对已成功的预授权交易，在结算前使用预授权撤销交易，通知发卡方取消付款承诺。预授权撤销交易必须是对原始预授权交易或追加预授权交易最终承兑金额的全额撤销。 - 预授权完成交易
对已批准的预授权交易，用预授权完成做支付结算。 - 预授权完成撤销
预授权完成撤销交易必须是对原始预授权完成交易的全额撤销。预授权完成撤销后的预授权仍然有效。 - 对账
通过FTP或者HTTP方式提供对账文件供商户侧对账。 - 余额查询
查询商户的交易账户的余额，避免由于余额不足导致交易失败。 注意，不是客户的余额。 当然，不是所有的银行或者第三方支付都提供这个接口。
支付产品业务流程
上述操作，除了对账、查单外，每个操作实现的主流程，一般会包括参数校验，支付路由，生成订单，风险评估，调用渠道服务，更新订单和发送消息这7步，对于一些比较复杂的服务，还会涉及到异步同通知处理的步骤。
- 参数校验
- 根据支付路由寻找合适的支付服务
根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付，但是我们没有实现和工行的对接，而是可以通过第三方支付，比如支付宝、微信支付、易宝支付，或者银联来完成。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。 - 评估交易风险
检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。
- 阻断交易，说明该交易是高风险的，需要终止，不执行第5个步骤；
- 增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。
- 放行交易，即本次交易是安全的，可以继续往下走。
- 生成交易订单
将订单信息持久化到数据库中。 - 调用支付渠道提供的服务
所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单，可以直接返回结果。一些第三方支付，支付宝，微信支付等，会通过异步接口来告知支付结果。 - 更新订单
对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。 - 发送消息
通过消息来通知相关系统关于订单的变更。风控，信用BI等，都需要依赖这数据做准实时计算。 - 异步通知
如上述流程，其中涉及到调用远程接口，其延迟不可控。如果调用方一直阻塞等待，很容易超时。引入异步通知机制，可以让调用方在主线程中尽快返回，通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口，也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址，一般以http或者https的方式。这就有技术风险，如果调用失败，还需要重试。而重试不能过于频繁，需要逐步拉大每一次重试的时间间隔。 在异步处理程序中，订单根据处理结果变更状态后，也要发消息通知相关系统。
支付产品的资金流
在支付产品的支付过程中，会触发资金的流动，即资金从用户个人账户上转移到电商公司的账户，而转移分为同行转移和跨行转移：
- 同行转移
不管支付系统对接的是银行直连还是银联，都是由目标银行在内部系统完成两个账户间的转账，即时完成。 - 跨行转移
如果支付系统没有对接目标银行，那么需要走银联或者第三方支付。银联：银联发报文给两个银行，分别完成两个账户上资金的增减，在用户看来，资金已经到账，但是实际上的资金流并没有即时流动，银联会在半夜做清结算后处理这笔资金，即金融机构之间的清结算；第三方支付：对用户来说，第三方支付与银联的表现没有不同，但是在资金流方面，第三方支付一般在各个银行都有托管资金，发生交易后，资金不会跨行流动，用户A的资金流入第三方支付在银行A的托管账户，而第三方支付在银行B的托管账户会流出相应金额到用户B在银行B的账户。
四、支付路由
用户在前端选择一种支付方式，比如使用招行借记卡来支付后，系统不一定就是调用招行的接口来执行支付。支付宝、百付宝等第三方支付平台以及银联等，都支持招行借记卡支付。 这种将支付方式落地到具体的支付接口的模块，就是支付路由。
支付路由的职责
设计支付路由的目的是：
- 钱，省钱，省钱，这是支付路由选择支付通道的最主要的规则。 哪个通道省钱，基本会优先考虑这个通道。
- 提升支付产品的QOS2。这体现在系统的可靠性、稳定性、性能和可用性上。通过屏蔽掉无法连接、不稳定、性能低的通道来提升这些指标。
- 支持营销。通过优先选择有优惠活动的通道，可以帮助业务提升付费客户量。
- 降低运营成本。一个设计良好的支付路由，可以大大降低运营投入。
支付路由的架构设计如下：
支付路由并不会直接对接前端的支付产品或者后端的支付渠道，它是支付网关的一部分。
目前已知的路由规则（考虑因子）有如下这些：
- Query Per Second，每秒查询率，描述特定的查询服务器在规定时间内所处理流量的多少 ↩
- Quality of Service，指一个网络利用各种基础技术，为指定的网络通信提供更好的服务能力 ↩
