整理一下在开发支付系统中的mind

常年被迫混杂在支付的业务之中，但是接触却不全面，整理一下。
有直接对接过微信支付宝的开发，有接入过第三方的支付上，有做过支付商的开发，按道理我也是个成熟的支付人，但是好像还是什么都不懂，fuck

基本第三方支付系统结构

1. 应用管理：能开放给多个业务系统进行调用。
2. 商户管理（CRM）：商户进驻，公司业务部门收集到的新客户录入到CRM中，走审批，当审批通过后向平台方（微信/支付宝等等）提供资料备案开通支付权限。
3. 支付交易：生成订单，接入支付渠道开放的支付方式
4. 对账管理：实现自己的支付系统（也就是我们支付商）与交易数据的交易数据的核对（T+1,T+2之类的），确保数据正确。
5. 清算系统：计算商户应收和我们干的活的收益。
6. 结算管理：根据清算出来的结果，或者是有什么特殊设置的抽成方式，再将资金划拨到商户的账户中。

其实大多数需要处理的东西上一级的大爹（支付宝微信等等）已经帮我们搞定了，我们只需要结合自身系统来进行优化就可以了。

对现有系统的思考

现在公司的业务接入了很多第三方支付商，在公司的业务内有时候需要进行内部的调用，这个情况需要再套一层加密验证吗？

在接入到第三方支付商的时候，根据不同的支付商规则，需要对参数进行不同的加密，所以我在内部加密的时候，就只做一些简单的验签操作了，减少工作量。还有一种情况是加入假如在微服务的开发模式下，把支付系统拆分出来，再拆分一个对外的开放平台，就能解决是否需要加密的问题。

之前公司接入了很多的公司，将支付系统单独拆分出来成立一个后台，为每一个不同的支付商都加一个后台的模块进行配套，之前用的若依的低代码平台进行整合。将需要的参数整合到后台里面去，让业务部门的人员对商户进行配置，并对不同的支付商加上模版的功能，因为会有大量的重要性不是很高的参数需要处理，可以降低业务部门的操作难度。

支付掉单

一般外部调用我们的系统会经过几个流程

1. 调用者创建一张订单，向支付的系统发起支付请求
2. 然后支付的系统内部也创建一张订单，并且向供应商（微信/支付宝/银行）发起支付请求
3. 供应商完成了扣款的操作之后，再返回给我们的支付系统
4. 我们的支付系统完成订单，修改状态后将结果返回给调用者
5. 调用者最终再改变支付的状态

在这个过程中，就会碰到一个问题
当供应商已经扣款的时候，调用者的支付状态却还是待支付的状态，这种情况就叫做掉单
外部掉单：不是供应商返回给我们系统就是我们的系统没有返回给调用者，中间出了问题就会出现外部掉单
内部掉单：在自身的内部系统中，更新订单状态的时候出现了问题就会出现内部掉单

外部掉单解决方案

1. 增加超时时间：外部掉单有可能是网络超时的问题，也有可能是系统的性能太慢，所以可以适度增加网络的超时时间。
2. 订单查询：以前我们公司刚开始的时候就有一个叫单条订单查询的功能，我们可以设计一个定时掉单查询的功能，将这类出现问题的订单保存到一个掉单表中，然后通过定时任务，对这些掉单的订单数据进行处理，若成功则重新对订单状态进行更新，如果结果未知则再进行进一步的处理。但是这样处理会有一个问题，可能会频繁的重复操作几张订单的数据，所以当时我们对最大值进行了一个限定，实在处理不了的时候会通过邮件通知开发人员进行手动处理。
3. 异步通知：现在一般支付接口返回的信息通知都是使用异步方案解决，在生成订单参数的时候，送上一个用于接收回调的参数，当支付的系统处理完成后，将这些信息推送到这个接口中，只需要解析这个接口的状态，再更新支付的状态就可以解决。
4. 对账处理：当问题无法解决的时候就可以采用对账处理的方式，最激进的方式就是内部手动处理了。

内部掉单解决方案

在我见过的情况中，我们在设计的时候，支付的订单表跟商户的订单表并不是一个表，每一个商户会单独拆分出一个订单表，所以有时候掉单是因为并没有同时更新到状态。

• 用分布式事务来解决：解决无法使用数据库事务的问题保证两者同时更新或失败
• 异步容错更新：在发生了无法更新支付状态的时候，简单的理解就是出现异常的时候，把这些异常的数据存放到一个掉单的表里面，保存完了处理，也就意味着还得挂一个定时的程序来处理这些异常，跟上面外部掉单的处理方法类似，缺点就是如果失败的数据比较多的时候，性能就会变差，这些操作最好放在备机上面来进行进行，减少对主库性能的消耗。

如何防止支付订单重复提交？

这是个比较常规的问题，在网上会看到有一大堆的cv方案。
创建订单的时候可以拿订单的信息生成出一个哈希值，然后用redis来判断这个key是否存在，如果存在的话就不允许再重复提交这个订单，key不存在的时候就生成一个新的key，并将这个key存到redis中并设置一个过期时间（这不就顺手完成了一个订单超时的功能了吗），再创建一张新的订单。

对账业务的流程整合

1. 对账一般都是存在于T+1或者以上的，so需要建立任务来定时进行处理对账任务
   • 管理任务批次
   • 记录任务是否成功的信息
   • 提供重启任务的功能（或提供就处理某条订单数据的功能）
2. 对账单下载，对账单大多数情况是通过ftp的情况搞回来的
   • 需要接入到ftp的相关功能
   • 判断需要的对账单是否存在
   • 下载到本地
3. 拿到对账单文件后进行解析
   • 首要是先对来源进行安全的验证
   • 一些基础的文件校验，判断文件是否为常规的文件而不是一些文件类型
   • 解析文件，对对账单的里面的数据以及公司内部的数据库进行一个对比
   • 将解析的结果入库
4. 对账处理
   • 要先拿到商户和我们系统的账单
   • 还要拿到挂帐相关功能的账单，这些需要单独处理
   • 然后进行校验匹配
     • 判断订单是否存在
     • 交易状态是否匹配
     • 交易金额是否匹配
     • 手续费金额是否匹配
   • 对挂帐的订单进行销账处理
     • 挂帐订单入库
     • 将那些需要销账的订单进行处理匹配
5. 错误处理
   • 异常情况，可入库也可以做一些提示邮件操作
   • 修正
   • 平账