转自 聊聊电商平台的支付交易系统

一、关于定位

今天和大家分享支付交易相关的系统,这是一个和资金打交道的系统,承载着电商平台的购物车、下单、支付渠道网关、订单管理、虚拟资金账户、营销优惠等重要业务,是电商平台不可或缺的系统。在不同的业务发展阶段,支付交易系统需要的架构和投入的人力也不大一样。

二、架构演进

1. 初期:单核阶段

在平台发展初期,业务相对比较简单,业务量也很小,一个系统就囊括了所有功能,很可能连部署都和其他功能混布。
聊聊电商平台的支付交易系统 - 图1

这个阶段的特点是:

  • 系统简单开发快,
  • 可扩展性差,无法快速满足新商品支付的接入
  • 各个节点耦合度高,节点间多为事务性依赖,导致交易链路很长
  • 代码越来越多,各个节点并行开发越来越困难

为了解决这些问题,决定将各个节点进行服务化,采用分布式系统架构,把支付交易的各个节点服务化到后端,用来支撑多个前端应用。

2. 中期:服务化

除了服务化,这个架构里还加上了交易订单,把订单拆分为商品订单和交易订单,主要目的是让支付和商品解藕,让网关更加独立,同时解决由于订单信息变更带来的触发第三方渠道风控策略,导致无法支付的情况 ( 比如点击过第三方支付,然后发生了订单改价,那么同一个订单号在第三方就不允许再次支付了 )
聊聊电商平台的支付交易系统 - 图2

这个阶段的特点是:

  • 缓解了1.0的问题
  • 分布式系统,保障分布式事务的数据一致性是难点,这里不做深入介绍,可参考

系统幂等以及常用实现方式
分布式事务演进

  • 跟着业务走
    3. 后期:面向业务规则
    3.0的支付交易系统应该是面向业务规则的系统,能够满足平台大多数的支付场景需要,业务规则可抽象,通过配置规则就能快速订阅底层的支付基础服务。
    但这需要等业务发展到一定阶段才可行。

    三、支付网关

    市面上有很多的渠道网关,那么渠道网关如何做选择呢?我归结为3个关键词:主流、稳定、手续费

首先是主流,就是满足大多数用户的支付需求,市面上的网关巨头如支付宝、微信基本就是标配
然后是稳定,一般主流的支付渠道稳定性都没有问题,但为了更好的容错容灾,多接入一些渠道进行备份也是好的选择
最后是手续费,当交易量达到一定量级,你会发现每笔交易支付的手续费也是一笔不菲的支出,降低手续费就成了需要去解决的问题
如何降低手续费呢?

  1. 通过商务手段进行谈判,同时接入一些中小渠道,一般这些渠道为了发展会有较高的谈判空间;
  2. 在界面上可以降低高手续费渠道的展示位置,当然不能影响交易额
  3. 对于有交易额阶梯价的渠道,通过渠道引擎自动调整交易渠道,对用户无感知,但这需要交易有一定渠道特点才能达到效果

    四、财务清算

    财务清算包括对账并产出会计报表,它的设计有一定会计知识门槛,在系统初期,一般团队都会因为快速支撑业务发展,而遗漏了这方面的设计。
    财务清算系统和支付交易系统在交易数据上是紧耦合的,为了让两个系统有比较清晰的系统边界,尽可能的解藕,我们的思路可以是这样的

  4. 建立会计科目体系,结合自身平台的特性,在这些主科目下建立分科目 资产 = 负债+待清算+(收入-费用)

  5. 支付交易系统产生交易流水
  6. 财务清算系统把交易流水录入到科目体系
  7. 财务清算系统和第三方对账单对账