银企支付-概要设计文档
1、背景
本文介绍一般银企支付的相关流程。一个支付体系需包括校验，风控，支付路由、支付网关模块、具备基本支付，退款，转账能力，可查询支付记录，还应具备相关的支付监控模块和差错处理模块。
2、基本概念
2.1、支付校验
在业务受理前，为了保证接口的安全性，受理接口要依次验证支付请求报文的安全性、用户的权限、参数的合法性。尽量保证受理接口只做基础验证，对其他复杂的的验证流程，进行异步处理，受理无法通过的，设置交易为失败状态，直接同步反馈给调用方。
2.2、风控
风险控制，是识别异常交易并加以额外验证的模块，在支付系统中是不可缺少的一环。风控并不能完全避免资金损失，只能尽量减少损失。不同业务的风控要素不同，一般风控包括如下要素：
- 交易量风控，可设置交易金额区间，对不合规的交易请求直接驳回。
- 交易频率风控，设置不同交易分类的交易频率阀值，对过高频率的请求，直接驳回。
- 交易习惯性风控，针对单个或某组用户群体，做用户画像行为分析，对反常的交易请求，做二次确认验证（如手机验证码）。
2.3、支付路由
对支付系统来说，支付路由是指一个三方支付公司分配的一个商户号，当然它也可以更细地划分，如添加卡类型、银行等维度。客户端选择不同的支付路由，涉及到最终不同的支付交易逻辑。举例：
- 路由1：客户端选择支付宝支付，支付路由为客户->支付宝交易流程。
- 路由2：客户端选择浦发银行支付，支付路由为客户->浦发银行。
2.4、支付网关
支付网关是支付系统与三方系统的交互接口，支付网关的设计要考虑的重点是报文的交互。除了普通系统要进行的参数验证、内外系统参数映射、各种请求类的包装外，支付系统要额外考虑的有报文签名和加密，系统交互详细日志。
2.5、监控
支付系统的监控主要是在业务层面上的监控。一般监控交易异常、路由异常等影响正常交易的状况，并及时报警告知运营或技术人员。监控还可提供一条交易信息的完整交易流程，方便运维人员查看交易在不同节点的明细情况。监控方式一般有：
- 统计法：定时对比统计数据与监控阈值，在统计数据的异常比例超出监控阈值时触发报警。
- 试探法：以测试交易来定时试探系统的稳定性和三方通道的稳定性。
- 埋点法：在支付关键节点埋点，并检验交易状态是否在期望状态。
2.6、差错处理
监控出异常的交易记录后，可对部分交易异常数据，在不同节点做补偿修正。通过程序或人为的重新启动该条数据在错误节点的交易支付请求，从而修正异常交易流水。
2.7、对账
对账是对前一日交易在全局上的对照，不同于账务和资金管理系统，对账是在数据流上确定交易的正确性，一般的对账流程如下：
- 下载对账文件 针对各三方系统的下载方式：FTP/HTTP 获取到对账文件
- 标准化处理：将格式为 txt/xml/cvs/zip 的三方系统对账文件处理成一种选用格式；
- 本地对账准备：可以根据数据量的大小，从源库/从库/nosql/文件方式准备与三方系统对账文件的对比
- 两个账务数据对比。
- 差异数据修复(人工/后续)
3、银企支付流程说明
3.1、流程分段
-
划分一个支付流程为三部分，分别为支付前置（初始化支付相关参数），支付路由和支付实现（第三方系统对接，如银行，支付宝对接），支付后的业务结果处理。
-
整个支付流程独立支付路由和支付实现模块。支付路由和支付实现板块为通用模块，不和具体业务相关。
-
业务与支付，与后续结果处理采用适配的模式，不同业务发起支付，需要配置对应的支付路由，配置对应的结果处理。三个支付流程，可自由组合配置。
如：订单支付，设置支付路由为支付宝，结果处理为订单完善的相关业务。
如：报销处理，设置支付路由为银企处理，结果处理为报销相关业务。
3.2、流程明细
-
1.客户端根据业务需求，发起支付请求。
-
2.业务受理模块接收到客户端发起的支付请求，依次做支付基础数据校验，风控验证，并根据业务选择的支付类型（如银企或转账）做路由选择。业务受理成功后，同步回执受理结果给客户端。
-
3.业务受理模块，采用多线程模式，根据支付请求参数，设置不同的路由，组装支付参数，构建一个支付请求mns消息(或者发起Spring boot事件)，发起一个支付任务。
-
4.银企系统封装模块接收到事件通知后，开启一个线程，做业务支付与银行对接任务。在银行与企业对接时，需根据银行的要求组装支付网关数据（数据格式，签名认证），并异步等待银行回执结果或主动获取银行反馈的终态结果。整个请求需保证幂等性并记录交互流程的明细日志（如请求参数，反馈参数，请求耗时）。银企系统封装层流程处理完成后，通过事件模式，发起一个异步任务给结果处理模块。
-
5.支付流水与第三方系统的支付流程完成后，流转到结果处理模块，根据与银行处理的结果，记录交易流水，并记录最终该笔支付请求的终态结果（一次请求到底是失败还是成功）。同时，完善该笔交易的业务状态。
-
6.结果处理板块完成后，反馈终态结果给客户端。
监控：各个环节，需记录该环节的详细日志，便于在交易失败时，做问题定位和修正。一条交易记录，最终应具备在不同环节都有详细流程信息，可查询到交易信息的完善生命周期。若交易量大，可先记录日志到缓存Redis中，通过Redis同步数据到关系性数据库中。若交易量小，可直接存储到关系型数据库中。
差错处理：一次交易失败可能在不同的环节出现的问题，一次失败，不应该是所有流程都重新来过，需要根据交易的不同节点，系统定时修复或人为参与做交易失败记录的差错处理。如：银企系统封装模块已经执行成功，结果处理模块执行失败，可调用银企封装模块再次推送最终结果，该条支付请求仅对结果处理模块重新处理。（要完成这种基于节点模式的修复，需记录不同节点向下一节点请求时的关键逻辑参数，同时提供启动接口）。
对账：根据财务需求，定期导出系统中的交易流水，方便银行流水与系统流水做数据对比。