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