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

1、关于定位

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

2、架构演进

1. 初期：单核阶段

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

这个阶段的特色是：

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

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

2. 中期：服务化

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

这个阶段的特色是：

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

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

分布式事务演进

• 跟着业务走

3. 后期：面向业务规则

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

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

3、支付网关

市面上有不少的渠道网关，那么渠道网关如何作选择呢？我归结为3个关键词：主流、稳定、手续费

 

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

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

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

如何下降手续费呢？

1. 经过商务手段进行谈判，同时接入一些中小渠道，通常这些渠道为了发展会有较高的谈判空间；
2. 在界面上能够下降高手续费渠道的展现位置，固然不能影响交易额
3. 对于有交易额阶梯价的渠道，经过渠道引擎自动调整交易渠道，对用户无感知，但这须要交易有必定渠道特色才能达到效果

4、财务清算

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

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

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

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

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

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

4. 财务清算系统和第三方对帐单对帐