前端流程

用户进到收银台列表，支付系统会当前的业务订单生成一笔自己的支付订单，用户每选择一次支付方式，支付系统会请求第三方创建一笔交易，交易中的交易号用来跟第三方网关交互，同时支付系统也会创建一些参数向第三方网关发起支付（发起支付成功，第三方页面才会打开），若用户支付成功，支付系统还会将该笔交易流水推送给财务系统，供财务进行对账查询。

image.png

信息流与资金流

当你用农行卡在星巴克刷卡消费时，资金流与信息流如图：

image.png

简单介绍整个流程：

• 你在收单行（建行）的POS机上刷卡消费（信息流）
• 建行将消费信息发送给银联（信息流）
• 银联记录交易数据，将消费信息给你的发卡行（农行）（信息流）
• 农行从你的卡中实时扣费，完成实时结算，并通知银联（资金流）
• 农行发送消费扣款短信给你，提醒余额减少（信息流）
• 银联更新交易数据，通知建行的POS机已完成扣款（信息流）
• 日终后银联在其清算系统完成清分，先把账算好（信息流）
• 清分完毕后，银联通过央行的清算系统，完成农行与建行清算账户的资金划拨（跨行清算）（资金流）
• 进行银行内部结算，完成建行和星巴克结算账户的资金划拨（收单清算）（资金流）

在这个过程中，银联提供两种清算：

• 建行和农行的清算叫“跨行清算”，一般为T+1日凌晨。
• 建行和星巴克的建行账户之间的清算叫“收单清算”，在跨行清算之后。

你在每日优鲜通过在微信支付绑定的农行卡消费为例：

image.png

简单介绍整个流程：

• 你在每日优鲜上通过微信支付的农行卡支付订单（信息流）
• 第三方支付平台将消费信息发送给网联（信息流）
• 网联记录交易数据，将消费信息给你的发卡行（农行）（信息流）
• 农行从你的卡中实时扣费，完成实时结算，并通知网联（资金流）
• 农行发送消费扣款短信给你，提醒余额减少（信息流）
• 网联更新交易数据，通知第三方支付平台（微信）已完成扣款（信息流）
• 第三方支付平台（微信）通知商户平台（每日优鲜），支付成功（信息流）
• 每日优鲜通知你订单已支付成功（信息流）
• 日终后网联在其清算系统完成清分，先把账算好（信息流）
• 清分完毕后，网联通过央行的清算系统，将收单金额结算给第三方支付平台的备付金银行账户。（资金流）
• 第三方支付平台（微信）按照一定的结算周期（一般为T+1）结算资金给每日优鲜在微信开设的虚拟账户。（信息流）
• 商户平台可通过自动或者手动的形式，将资金提现到实体银行卡。（资金流)

订单的生命周期

image.png

后台系统流程

image.png

完整系统架构

image.png

架构概述

支付基础设施

支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统：
运维监控： 支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件作出响应，又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。
日志分析： 日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。
短信平台： 短信在支付系统中有重要作用： 身份验证、安全登录、找回密码、以及报警监控，都需要短信的支持。
安全机制：安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。
统计报表： 支付数据的可视化展示，是公司进行决策的基础。

支付核心系统

支付核心系统指用户执行支付的核心流程，包括：
用户从支付应用启动支付流程。
支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付。
支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付。
支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作，最终落地资金转移

支付服务系统

支持支付核心系统所提供的功能。服务系统又分为基础服务系统、资金系统、风控和信用系统。

基础服务系统

提供支撑线上支付系统运行的基础业务功能：
客户信息管理：包括对用户、商户的实名身份、基本信息、协议的管理；
卡券管理： 对优惠券、代金券、折扣券的制作、发放、使用流程的管理；
支付通道管理: 通道接口、配置参数、费用、限额以及QOS的管理；
账户和账务系统： 管理账户信息以及交易流水、记账凭证等。这里的账务一般指对接线上系统的账务，采用单边账的记账方式。 内部账记录在会计核算系统中。
订单系统： 一般订单系统可以独立于业务系统来实现的。这里的订单，主要指支付订单。

资金系统

指围绕财务会计而产生的后台资金核实、调度和管理的系统，包括：
会计核算： 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。
资金管理： 管理公司在各个支付渠道的头寸，在余额不足时进行打款。 对第三方支付公司，还需要对备付金进行管理。
清算分润： 对于有分润需求的业务，还需要提供清分清算、对账处理和计费分润功能。

风控系统

是支付系统必备的基础功能，所有的支付行为必须做风险评估并采取对应的措施；

信用系统

是在风控基础上发展的高级功能，京东的白条，蚂蚁花呗等，都是成功的案例。

支付核心系统详细说明

支付简略的流程如下

image.png

1. 交易系统用发起支付请求。注意，这个请求一般是从服务器端发起的。比如用户在手机端提交“立即支付”按钮后，商户的服务器端会先生成订单，然后请求支付网关执行支付。

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

3. 支付产品对用户请求进行预处理，包括执行参数校验

4. 支付产品调用支付路由寻找合适的支付通道、生成订单、调用通道落地执行支付、响应通道的结果并将交易结果通知到商户侧。

5. 支付产品可能还会同时调用风控系统评估交易风险

支付核心模块

支付网关

我们知道,我们最终的支付行为是通过支付渠道来落地的,但不同的支付渠道可能是有差异的.而支付网关的核心职责之一就是封装各个渠道的差异，渠道交互的公共操作封装到网关中,对外呈现统一的接口。

网关的一般功能

1. 身份验证： 确认付款方、收款方、渠道是否有执行当前操作的权限。
2. 验签： 对接口参数进行签名并验证其签名。这是为了避免接口被盗刷和篡改的必要手段。如果对各个接口采用统一的签名规则，则可以在网关层实现。
3. 还可以做一些限流熔断

支付产品

就是我们常见到的快捷支付,网银支付等
支出产品根据其支付能力，对外提供不同的功能。

支付产品的主要接口：

image.png

签约和解约
在快捷支付、代扣等产品中，用户在使用前，需要先完成签约。签约可以在渠道侧进行，一般第三方支付采用这种方式，当电商需要接入时，让第三方给授权。 银行和银联的签约一般是在电商侧进行， 电商侧负责收集用户的信息，调用银行和银联的接口进行签约。签约后，后续的支付行为就使用签约号来进行，无需再输入个人信息。 和签约相对应，解约则是取消签约关系。

支付
支付是少不了的操作。 不同产品中支付行为不一样。快捷支付是在电商服务器上发起，请求渠道进行支付；网银支付则是跳转到银行支付网关上进行; 而账户支付、虚币支付，则是在本地进行的。

撤销和退款
有些渠道区分撤销和退款，比如银联、农行等，撤销指取消当天在渠道侧未结算的交易； 而退款仅针对已经结算的交易。有些渠道则不作区分。

查询签约状态
对于需要签约的交易，可以通过这个接口来查询签约状态。

查询订单状态
通过这个接口来查询支付清单状态以及退款的订单状态。

预授权
预授权交易用于受理方向持卡人的发卡方确认交易许可。受理方将预估的消费金额作为预授权金额，发送给持卡人的发卡方。

预授权撤销
对已成功的预授权交易，在结算前使用预授权撤销交易，通知发卡方取消付款承诺。预授权撤销交易必须是对原始预授权交易或追加预授权交易最终承兑金额的全额撤销。

预授权完成交易
对已批准的预授权交易，用预授权完成做支付结算。

预授权完成撤销
预授权完成撤销交易必须是对原始预授权完成交易的全额撤销。预授权完成撤销后的预授权仍然有效。

对账
通过FTP或者HTTP方式提供对账文件供商户侧对账。

余额查询
查询商户的交易账户的余额，避免由于余额不足导致交易失败。 注意，不是客户的余额。 当然，不是所有的银行或者第三方支付都提供这个接口。

支付产品的主要功能

风控拦截： 风控是和支付产品有关，不同产品的风控措施、处理对策也是不同的，所以风控是在产品层实现。
支付路由： 路由也是和产品有关。不同产品路由策略也不同。
参数校验： 这也是和支付产品相关的，不同的产品接口其参数也不同。
支付流程： 生成交易记录、落地渠道执行支付、同步和异步通知等操作。

1. 执行参数校验
所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击。

• 验证输入参数中各字段的有效性验证，比如用户ID,商户ID,价格，返回地址等参数。
• 验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态。
• 验证订单：如果涉及到预单，还需要验证订单号的有效性，订单状态是未支付。为了避免用户缓存某个URL地址，还需要校验下单时间和支付时间是否超过预定的间隔。
• 验证签名。签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密，然后作为一个参数随其他参数一起提交到服务器端。如[支付网关设计]所介绍，签名验证也可以在网关中统一完成。

2. 根据支付路由寻找合适的支付服务
根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付，但是我们没有实现和工行的对接，而是可以通过第三方支付，比如支付宝、微信支付、易宝支付，或者银联来完成。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。

3. 评估交易风险
检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。

阻断交易，说明该交易是高风险的，需要终止；
增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。
放行交易，即本次交易是安全的，可以继续往下走。

4. 生成交易订单
将订单信息持久化到数据库中。

5. 调用支付渠道提供的服务
所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单，可以直接返回结果。一些第三方支付，支付宝，微信支付等，会通过异步接口来告知支付结果。

6. 更新订单
对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。

7. 发送消息
通过消息来通知相关系统关于订单的变更。风控，信用BI等，都需要依赖这数据做准实时计算。

8. 异步通知
如上述流程，其中涉及到调用远程接口，其延迟不可控。如果调用方一直阻塞等待，很容易超时。引入异步通知机制，可以让调用方在主线程中尽快返回，通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口，也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址，一般以http或者https的方式。这就有技术风险，如果调用失败，还需要重试。而重试不能过于频繁，需要逐步拉大每一次重试的时间间隔。 在异步处理程序中，订单根据处理结果变更状态后，也要发消息通知相关系统。

支付路由

支付路由存在的意义包括但不限于：
A. 降低公司的支付成本：不同支付通道有着不尽一致的支付成本，支付路由旨在尽可能择出一个对于公司而言节省成本的方案。
B. 保证支付成功率：对于投资用户而言，支付成功率是用户体验的重要组成部分。良好的支付成功率可以使用户投资顺畅，对于借款用户而言，支付成功率是投资用户的投资收益，以及借款按时计划还款的重要组成部分。
C. 支持个性化的支付定制：例如对于渠道灰度切换，特定银行特定渠道优先，或是渠道每日限额控制，A/B 测试，脚本定制。这些个性化的渠道方案定制策略都希望可以在路由系统中被考虑和实施。
D. 计算支付整体方案的能力：不仅仅计算单一的支付通道，而是拥有计算一个完成支付方案的能力。
E. 闭环控制：设计良好的支付路由系统应该有闭环控制的能力，能够根据外界环境的变化（比如渠道/银行维护，断路）而对于相同的输入参数给出不同的输出结果。从而降低公司整体的运营成本。

路由的一般考虑因素

image.png

说明

产品类型
当然，路由时首选需要考虑渠道可以支持的支付产品。

费率
费率是路由最重要的一个指标。一般银行是按照额度来收费，部分是按照交易笔数来收费，复杂点的是阶梯收费，比如10万一个费率档次，100万一个费率档次。

优惠活动
银行、第三方支付为了延揽客户，经常也会提供一些补贴给对接的商户，对于使用该渠道的交易进行补贴。而优惠的策略也是多种多样。

交易限额
不同通道会限制每次交易的金额上限，以及针对每个账户每天的额度限制。超过这个额度，需要变换通道。

卡类型
通道支持的信用卡或者借记卡。

通道的QOS
掉单率、网络延迟以及接口能支持的TPS，是路由的一个重要衡量因素。

资金头寸
电商公司在银行或者第三方平台的资金头寸。如果资金头寸不足，则不能使用这个通道来执行。

到账时效
对于转账，资金什么时候到目标账户上，也是影响路由选择的一个因素。

商户类型
不同类型的商户可以选择不同的通道。 比如高性能、费率高的通道，预留给高级商户。

路由算法

路由系统是否可以支持费率优先，或者成功率优先

经典的常用算法
锦标赛算法
锦标赛赛决出优胜者的方式是，通过一轮又一轮的比赛，在每一轮的比赛中，失败者淘汰，优胜者晋级直至最终冠军的产生。

示例
一个锦标赛的路由算法配置：[费率优先，渠道成功率优先]. 表示这次比赛，所有的候选方案都先进行费率优先的比较，而后进行成功率优先的比较。

在A中张三投资2000元有三个方案参与了比赛，分别是S1: （张三， 银行卡A, 2000元，连连支付），S2: （张三， 银行卡A, 2000元，宝付支付），S3（张三， 银行卡A, 2000元，易宝支付）。 S1费率0.5元，S2费率0.5元，S3费率0.8元。则第一轮在费率上的比赛 S3出局，继续S1和S2的成功率比赛。S1成功率99.1%, S2成功率99.9%。则优胜者为S2. 最终张三收到连连支付发送的短信验证码. 锦标赛算法本质上这是一个偏序比较的算法。

循环赛算法
循环赛决出优胜者的方式是：所有候选者都参与每一轮的比赛，根据排名座次分别取得一定的积分。最终所有候选人根据总积分决定优胜者。

示例：

一个循环赛的配置是：费率排名第一的得3.5分，第二得2分，第三得1分。成功率第一得4分，第二得2分，第三得1分。在这种设置下，假设S1在费率得1分，成功率得4分。总得分5分。而S2在费率得2分，在成功率得2分。总得分4分。则最终S1胜出。说明虽然S1费率最差，但是成功率的领先让其在路由中被择出。而如果S2在费率中排名第一，则S2的成绩从4分变为5.5分。则S2胜出了。说明在巨大的费率优势下，整个路由系统判定S2虽然成功率低一点但是也值得一试。循环赛算法本质上是一个权重比较的算法。

补充

绑卡签约

快捷支付指用户在电商网站上执行支付时，不需要输入卡信息，仅根据短信或者其他的验证方式确认身份后，就可以执行扣款的支付方式。 这是目前电商网站采用的主要支付方式。 在快捷支付中，用户首次支付，需要提供卡的信息，之后就可以凭短信验证码，甚至不需要密码，也可以执行扣款。绑卡是将用户卡信息提供给电商，以后电商就用这个信息去银行完成支付。绑卡实际上是一个授权，让用户允许商家自动从他的账户上扣除资金。所以绑卡也叫签约，用户和银行，商家的三方签订的支付合约。

绑卡流程
针对用户不同状态，绑卡流程上有区别。当然，绑卡是安全操作，要求用户必须登录到系统中。为了避免和服务器端的交互被劫持，所有操作必须在安全链接中进行，即使用https。当用户开始绑卡时：流程图如下

image.png

1. 输入卡号
用户输入卡号，系统对卡号执行初步验证。 验证的依据是卡bin和LUHN算法。 当然，还有些系统会提供扫卡识码的功能，比如微信支付。 扫码识别的准确率可以达到99%，有些卡的卡号颜色和背景色一致的，就会识别出错。 如果用户没细看，进入下一步，就会报告错误了，这种错误还比较难发现。自动识别卡号，还需要考虑在识别错误时如何圆过去的问题。

2. 获取卡信息
首次绑卡需要提供卡信息。借记卡需要卡号，用户真实姓名和身份证，这个所有银行都一样。(有不一样的，留言告知，谢谢) 信用卡就复杂点。大部分信用卡还需提供CV码和有效期。但是如果和银行关系好，拿到合适的接口，把这两个因素都免了，也是有可能的。

3. 要素验证
首先在服务器端做验证。主要是验证卡是否已经被绑过。 如果一个用户有多个账户，系统还需要考虑是否支持这些账户都绑到一个卡上。 接着调用银行绑卡验证接口进行绑卡。这里有一个四要素验证的概念。由于国内要求实名制，所有银行卡都是实名办理的，所以银行可以验证姓名，身份证号，银行卡号和手机号是不是一致的。如果没问题，则会发短信到手机上。
这里还有几个注意点:
1.关于手机号。大家都知道，银行预留的手机号一般都是办卡的时候留的，过了几年，换手机了，很多人就忘了同步到银行。所以很多银行就不验证手机号。
2.关于验证短信，手机号都不是必须的，那短信就可能都不发了。这在流程设计时需要统一处理。银行不发短信就的自己发。
3.重复绑卡问题。如果系统支持多账户，那不可避免的出现一个人绑卡到多个账号上。渠道侧绑卡，有接口支持重复绑卡，有些是不支持的。所以如果需要重复绑卡，还得在服务器端处理。

4. 执行绑卡
用户输入短信验证码并确认绑卡，服务器端将用户实名信息以及短信验证码组合形成报文，发送给银行，执行签约操作。银行侧签约成功后，返回签约号给商户。 这一个处理逻辑放在支付渠道侧介绍。银行会返回如下结果：

1. 签约成功：这意味着可以建立签约关系。而签约关系在支付系统中则通过虚拟账户来表示。 具体的账户设计参见[账户模型]
2. 重复签约： 按照业务考虑是否支持重复签约。 一般针对一个银行卡仅保留一个签约关系，建立一个虚拟账户。
3. 签约失败： 需要提示具体失败原因。

解约流程

解约流程一般是由用户自己发起。当然，存储在本地的签约信息只是被设置为无效，而不是实际删除。 解约时，还需要注意相关的订单是否都已经完成。

image.png