支付系统(一) 架构样例

银行技术架构(一) 支付清算体系
银行技术架构(二) 业务模式与银行账户
银行技术架构(三) 货币
支付系统(一) 架构样例

账务处理，分为内外两个子系统，外部子系统是单边账，内部子系统走复式记账。清结算也是基于这个模型来记账、对账和平账

• 支付记账：针对线上的账户实时更新的需求，需要让用户及时看到账户余额和订单状态，账务信息记录到用户和商户上，采用单边账的形式
• 会计记账：采用复式记帐法，满足会计记账需求，记录会计分录和余额，为对账和清结算提供支持

复式记账: 复式记账是与单式记账相对称的一种记账方法。这种方法的特点是对每一项经济业务都要以相等的金额，同时记入两个或两个以上的有关账户。通过账户的对应关系，可以了解有关经济业务内容的来龙去脉；通过账户的平衡关系，可以检查有关业务的记录是否正确

对账处理: + 渠道对账单下载 + 格式标准化 + 本地交易记录准备 + 轧帐 + 平帐

• 引导路由
  • 根据支付应用、收款商户、订单额度等信息来决定提供给用户的支付方式列表
  • 决定哪些支付方式可以提供给当前场景下的用户来使用，哪个方式应该排在前面
• 参数校验
  • 所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击
    • 验证输入参数中各字段的有效性
    • 验证账户状态：交易主体、交易对手等账户的状态是处于可交易的状态
    • 验证订单：订单号的有效性，订单状态是未支付，下单时间和支付时间是否超过预定的间隔
    • 验证签名：防止支付接口被伪造，一般签名是使用商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密。签名验证也可以在网关中统一完成
• 支付路由
  • 根据用户选择的支付方式确定用来完成该操作的合适的支付渠道，用户指定的支付方式不一定是最终的执行支付的渠道
    • 比如用户选择招行支付，除了招行自己的接口外，第三方支付公司、银联等也可以从招行卡上扣款
    • 同一家银行，除了总行的接口，各地的分行也可以提供这个接口。一般同一家银行的接口规范是一样的，不同的是提供接口的服务器、费率、性能等
  • 支付路由会综合考虑费率、渠道可用性等因素来选择最优方案来完成资金转移操作
    • 费率：单笔费率、总额费率、阶梯费率
    • 营销策略：单笔优惠金额、单笔折扣比例、补贴额度、活动时间、红包/优惠卷/额度卡
    • 交易限额：单笔上限、总额上限
    • 渠道类型：快捷支付、网银支付、支付宝、微信
    • 卡类型：信用卡、借记卡、对公/对私
    • QOS：掉单率、网络延迟、TPS
• 风控
  • 检查本次交易是否有风险
    • 阻断交易：说明该交易是高风险的，需要终止
    • 增强验证：说明该交易有一定的风险，需要确认下是不是用户本人在操作。可以通过发送短信验证码或者其他验证方式来做校验，验证通过后可以继续执行该交易
    • 放行交易：说明该交易是安全的
• 生成交易订单
  • 订单信息持久化到数据库中
• 调用支付渠道提供的服务
• 发送消息
  • 通知相关系统关于订单的变更。风控、信用BI等都需要依赖这个数据做准实时计算

利用消息机制来实现跨系统的事务处理，避免数据库锁导致的性能问题

• 内部对账
  • 核实账户系统中的账务与支付记录的一致性
  • 核实会计系统中的账务与支付记录的一致性
• 渠道对账
  • 银行、第三方支付提供T+1的对账单
  • 核对交易流水，记录资金归集的账务
• 账账核对(日结和试算平衡)
  • 总分类账各账户本期借方发生额合计与贷方余额合计是否相等
  • 总分类账各账户借方余额合计与贷方发生额合计是否相符
  • 核对各种明细账及现金、银行存款日记账的本期发生额及期末余额同总分类账中有关账户的余额是否相等
  • 科目维度
    • 科目期初余额+科目当日发生额 = 科目期末余额
    • 下级科目余额总和 = 上级科目余额(科目总分检查)
• 账实核对
  • 验证银行存款的变化和实际资金流向是否一致

参考：
支付系统设计