支付路由设计

  • 支付路由，即根据支付请求选择合适的支付通道完成支付。选择的要素通常有：
    • 通道稳定性，优先使用成功率更高的通道，提升客户体验，一旦某些通道成功率过低，进行自动熔断。比如第三方通道合作商通道出现成功率过低的情况下，换用直连通道进行交易。
    • 成本，在其他差别不大的情况下，优先使用手续费低的通道，以得到最大的盈利。
    • 流量分配，即多个通道合作商都需要引入一些交易量，通过权重等因素将交易分配到各个通道。
    • 安全性，满足风控要求。

支付渠道的封装
  • 银行接口->银行通道->支付渠道->支付产品->支付解决方案

银行接口
  • 银行提供的服务接口，如某银行支付宝支付扫码支付接口

银行通道
  • 对银行接口的封装，如某银行通道

支付渠道
  • 对银行通道的业务封装，包含了费率等信息，如某银行扫码支付渠道

支付产品
  • 对支付渠道的打包，一个支付产品包括多个支付渠道，满足某个支付场景的使用

路由方式

人工切换
  • 由业务人员手工控制使用的支付通道，实现简单

自动切换
  • 基于规则
  • 基于权重

支付路由完整流程

  1. 客户端 =》 上送请求 =》 请求校验 ||=》 根据商户ID查找商户配置信息 =》 IP黑白名单校验  =》 IP黑白名单校验成功 =》 接口权限校验（例如是否可使用退款） =》 拥有接口使用权限 =》 获得密钥 =》 验签 =》 验签通过 =》 必要参数校验 =》 必要参数完整且合规 =》 参数业务合规校验（例如 支付金额必须大于0）=》请求校验完成|| =》支付风控开始|| =》金额风控 =》 支付风控结束|| =》 支付路由开始|| =》 获取商户支付路由信息 =》 有可选择支付路由 =》 根据规则选择使用的支付通道  =》 进入支付通道 =》 支付路由完成|| =》 用户上送参数和支付路由配置信息获取 =》 进入支付类型统一代码（支付类型极少变动，且为对外提供的产品，作为第一层分流）=》 进行实例化（查询不需要实例化，支付和退款分表）=》 从Bean工厂获得支付渠道实例 =》 进入支付渠道（支付渠道相对固定，且部分通道进行整合，因此作为第二层分流，但为薄层，不进行实际业务处理，仅用来IOC使用）=》 调用实际通道实现代码 =》 拼接通道参数 =》  向通道端发起请求 =》 获得通道端响应 =》 解析响应参数 =》 返回统一响应参数 =》 支付类型层进行返回处理（包括改变订单状态等）=》组装返回参数 =》 继续像上层返回 =》 上层进行返回参数验证 =》 对返回参数进行签名，包装 =》 向客户端响应。

博文