详解 | 关于交易的核心设计指南

交易？······清晰记得那年冬天，一屋子人吵到不可开交，购物车让订单算应该付多少钱，订单让购物车自己算；我斜眼一看，交易系统同学藏在角落瑟瑟发抖，似乎在祈祷“这不关我的事！！！”

是啊，什么是交易呢？整个体系都可以称为交易，那什么又是交易系统呢？交易核心呢？似乎我也迷茫了，为了要写，那么暂且这么定义吧——“那个夹在订单系统，支付系统和账务系统之间的那个少年，他帮助订单记录了账单，对各支付方式进行支付的加工和请求以及处理，并且将支付系统返回的收银台返给用户端，以及将支付结果告知各方，最后再告诉账务系统要记账了…..。”

我想说“少年您辛苦了”，您还是那个青涩的少年，从来不曾改变！

先看个案例：

陈老师在外卖平台买了一个鸡腿100块，微信支付了60元，用了一张20的代金券，又使用了10元的积分，参与了分享立减10元的活动的权益。

陈老师啃了一口发现是个鸭腿，以实物不符为由将骨头退还给商家，申请退货，商家同意退货，但是要罚40元精神损失费，所以只退了20到微信，代金券，积分，立减活动因为不退，所以陈老师最后只收到20元退款。

01 什么是交易

就像电影台词里经常说的“今晚码头交易”；我要跟你做一个交易；交易被终止了。

貌似交易不容易被定义，但也可以定义，以下来自百度词条：

交易（Transactions）是指双方以货币为媒介的价值的交换。

看起来交易是这件事情本身，但是我们今天讲的交易可能是交易这件事情中的一个环节，交易处理。

02 什么是交易系统

交易系统就是在支付体系当中，对交易进行记录和处理的应用系统，而交易我们在开头已经将范围界定在了对各支付方式进行加工处理的范畴了；所以交易的实体是账单和支付流水，核心服务是对各支付方式的请求处理以及支付流水的记录，并推动交易完成的核心模块。

03 什么是交易核心

交易核心我们暂且定义为交易服务的“核心处理引擎”，就是交易核心的部分，对各支付方式的支付加工以及请求，驱动各环节促使交易的完成；以及逆向交易的完成。

04 交易在支付体系的位置和作用

交易处在支付体系的核心位置，就像支付的中央枢纽一样，推动着整个支付流程的进程；一方面接受订单的账单创建请求，另一方对各类支付方式进行加工处理，并完成账务记账推动。

05 交易核心的业务实体结构

一个订单可以创建多条账单，比如一个订单分2次支付则创建2个账单；一个账单又可以进行组合支付，比如三方支付+卡券+活动优惠；分别针对不同支付方式请求各系统完成支付处理；最后基于各渠道的支付结果推动清结算完成费用计算清分以及账务记录。

06 正向交易流程

用户购物车选好商品后去结算进行订单的填写；

提交订单后完成订单的生成；

用户去支付订单完成账单的创建和支付请求的封装；

交易核心请求支付核心获得收银台链接返回给用户端；

用户完成支付；

交易核心完成各类支付方式的支付结果处理并通知订单支付成功；

交易核心基于支付结果通知清结算进行相关计费和记账；

07 交易账单的创建

订单通知交易核心进行账单的创建，我们以一对一为例，以开头的例子为交易场景。

订单信息如下：

生成如下账单记录：

08 账单支付记录

账单基于支付方式创建支付请求：

09 支付请求的处理

交易核心依托于支付记录向各个系统发起支付请求：

微信支付：封装支付参数请求支付系统进行付款，成功后通知交易核心。

代金券：封装券核销参数请求券系统锁定优惠券，待微信支付成功后核销优惠券。

积分和立减通优惠券。

交易发生逆向时要控制好处理的顺序，比如部分退款，先退谁；先退微信还是先退券，这只是个策略问题。

10 支付流水的生成

基于各系统返回的支付请求结果，更新支付流水状态；并更新账单为已支付；通知订单用户已完成付款，订单进入待发货或者待服务流程。

11 交易信息的封装

将交易信息封装成整体以后展示给各方使用。

12 交易驱动账务

交易系统基于支付结果通知账务系统进行记账：

后面讲清结算的时候我们再接着细讲账务部分。

13 交易后台

交易后要主要展示这几部分信息，每部分就不细讲了

订单信息

账单信息

支付流水信息

记账信息

感觉交易系统很薄，又感觉交易系统很厚；其实交易系统如果从后台能看到的部分看是很薄的，比不上其他系统那么多页面，那么多操作。

但是从交易系统的处理服务上去看，是非常复杂的，很多看不到的处理引擎，也印证了那句话“低调的背后永远是实力”。

希望各位读者朋友可以基于这个架子，去深究交易系统更多不为人知的一面！