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

一、关于定位

今天和大家分享支付交易相关的系统，这是一个和资金打交道的系统，承载着电商平台的购物车、下单、支付渠道网关、订单管理、虚拟资金账户、营销优惠等重要业务，是电商平台不可或缺的系统

在不同的业务发展阶段，支付交易系统需要的架构和投入的人力也不大一样。

二、架构演进

1. 初期：单核阶段

在平台发展初期，业务相对比较简单，业务量也很小，一个系统就囊括了所有功能，很可能连部署都和其他功能混布。

1.0.png

这个阶段的特点是：

系统简单开发快，

可扩展性差，无法快速满足新商品支付的接入

各个节点耦合度高，节点间多为事务性依赖，导致交易链路很长

代码越来越多，各个节点并行开发越来越困难

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

2. 中期：服务化

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

2.0.jpg

这个阶段的特点是：

缓解了1.0的问题

分布式系统，保障分布式事务的数据一致性是难点，这里不做深入介绍，可参考

系统幂等以及常用实现方式

分布式事务演进

跟着业务走

3. 后期：面向业务规则

3.0的支付交易系统应该是面向业务规则的系统，能够满足平台大多数的支付场景需要，业务规则可抽象，通过配置规则就能快速订阅底层的支付基础服务。

但这需要等业务发展到一定阶段才可行。

三、支付网关

市面上有很多的渠道网关，那么渠道网关如何做选择呢？我归结为3个关键词

主流、稳定、手续费

首先是主流,就是满足大多数用户的支付需求，市面上的网关巨头如支付宝、微信基本就是标配

然后是稳定,一般主流的支付渠道稳定性都没有问题，但为了更好的容错容灾，多接入一些渠道进行备份也是好的选择

最后是手续费,当交易量达到一定量级，你会发现每笔交易支付的手续费也是一笔不菲的支出，降低手续费就成了需要去解决的问题

如何降低手续费呢？

通过商务手段进行谈判，同时接入一些中小渠道，一般这些渠道为了发展会有较高的谈判空间；

在界面上可以降低高手续费渠道的展示位置，当然不能影响交易额

对于有交易额阶梯价的渠道，通过渠道引擎自动调整交易渠道，对用户无感知，但这需要交易有一定渠道特点才能达到效果

四、财务清算

财务清算包括对账并产出会计报表，它的设计有一定会计知识门槛,在系统初期，一般团队都会因为快速支撑业务发展，而遗漏了这方面的设计。

财务清算系统和支付交易系统在交易数据上是紧耦合的，为了让两个系统有比较清晰的系统边界，尽可能的解藕，我们的思路可以是这样的

建立会计科目体系，结合自身平台的特性，在这些主科目下建立分科目

资产 = 负债+待清算+(收入-费用)

支付交易系统产生交易流水

财务清算系统把交易流水录入到科目体系

财务清算系统和第三方对账单对账