一张小票看透支付清结算架构

支付清结算相关的系统写了很多了，单模块介绍的也不少；虽然有几个架构性质的文章，但是有不少朋友反馈说无法串起来；今天我们就从一次美团外卖的小票来看，将支付清结算串起来会是什么体验！准备好了么，抓好扶手，走起！

一、一张小票

我们看下面外卖盒上的小票，牛肉拌饭1份一共39元，餐盒费1元，没有配送费，合计40元，优惠了19元，实付21，实收17元。

我们再看美团订单的信息，烤肉饭1分39元，打包费1元，配送费原价7元现价2元，美团会员15元；美团红包减7元，满减优惠14元；总优惠26元，合计36元。

我们发现商家的小票和美团的订单信息之间有不少的差异，特别是优惠的明细展示以及优惠总额和应付总额之间存在差异；下面我们就来顺藤摸瓜，分析背后的玄机。

我们先认清一个关系，订外卖的陈老师跟商家没有直接的关系，美团跟商家直接是结算关系，也就是美团帮助商家代收餐费，并进行结算；简而言之就是陈老师付给美团综合的外卖钱，美团抽一部分然后给商家结算餐费。

我们先粗略的假想一下，这个过程是怎么完成的。

1. 我们先到美团平台选择喜欢的“商品”；

2. 然后“下单”并生成交易“账单”；

3. 选择支付方式进行“支付”；

4. 支付成功后美团要履行承诺把餐送到“履约”；

5. 完成以后美团就开始进行各方利益的“清分”计算了；

6. 算清楚应给给各方多少钱时并计入账簿“记账”；

7. 然后就是进行“结算”。

按照这个思路，我们来看，上面的小票在每个环节都是怎么处理的呢？

二、商品

商品广泛用于电商系，在O2O领域我们可能叫“服务”多一点，这里其实站在吃货的角度来看，订外卖，买了一份商品也没什么问题。商品模型这里我们不过多介绍，简而言之就是下面这样一个高度抽象的结构：

那么这一单外卖的商品有哪些呢，有4个（这里我们将配送服务看做商品）：