见字如面，我是军哥！
我很少推荐别人的公众号，因为我能看上的原创公众号并不多，让我主动推荐就更难了。
今天这位朋友叫宇宙，认识有两年了，在支付行业里非常有名气，最近闲着无聊翻了他多篇原创文章之后，我发现他对支付这种极其复杂领域的业务架构/产品架构已经到了炉火纯青的地步了，推荐给各位，我相信你一定会回头来感谢我的！
下面是他的一篇原创，本文头部和尾部都有他的公号卡片，文章不长，请认真看完～
从一次美团外卖的小票入手进行分析，研究支付微观层面的业务流转、单据的生成等支付微观细节。
1.一张小票
看下面外卖盒上的小票，牛肉拌饭1份一共39元，餐盒费1元，没有配送费，合计40元，优惠了19元，实付21，实收17元；再看美团订单的信息，烤肉饭1分39元，打包费1元，配送费原价7元现价2元，美团会员15元；美团红包减7元，满减优惠14元；总优惠26元，合计36元，如图1所示：
图1：美团外卖小票和订单信息
图中可以看出商家的小票信息和美团的订单信息之间有不少的差异，特别是优惠的明细展示，以及优惠总额和应付总额之间存在差异；下面我们就来顺藤摸瓜，分析背后的玄机。
我们先认清一个关系，订外卖的用户跟商家没有直接的关系，美团跟商家直接是结算关系，也就是美团帮助商家代收餐费，并进行结算；简而言之就是用户付给美团综合的外卖钱，美团抽一部分然后给商家结算餐费，如图2所表达的关系：
图2：交易关系
粗略的假想一下，这个过程是怎么完成的，用户先到美团平台选择喜欢的“商品”，然后“下单”，生成交易“账单”，用户选择支付方式进行“支付”，支付成功后美团要履行承诺把餐送到，“履约”完成以后美团就开始进行各方利益的“清分”，计算了算清楚应给给各方多少钱时并计入账簿“记账”，然后就是进行“结算”，这个过程如图3所示：
图3：业务流程
下面，基于上面的业务流程，分析小票在每个环节是怎么处理的，都生成了什么单据，单据中包含哪些信息。
2.商品信息
商品广泛用于电商，在o2o领域可能叫“服务”多一点，站在吃货的角度来看，订外卖，买了一份商品也可以说的通；商品模型这里就不过多介绍，简而言之就是图4所示的信息结构。
图4：商品信息结构
案例中的这单外卖的商品有4个（这里我们将配送服务看做商品），如表1所示：
表1：外卖单的商品信息
这里需要说一下美团会员，这是美团推出的一个会员服务，相当于花钱买了多张优惠券，如图5所示，所以购买美团会员获得优惠券也是一次交易，而且本交易要先与外卖单，因为外卖单的支付用到了这批券。
图5：美图会员详情
3.订单信息
选购好了商品，接下来就是下单了，这时候交易系统会去营销系统获取可以使用的活动优惠或者卡券，本小票可以看出来，有这些优惠可以使用，见表2：
表2：使用的优惠信息
因为目前还不清楚美团和商家之间的清结算协议，所以暂且认为所有优惠由美团提供给用户，后续美团再基于协议跟商家之间做优惠的分摊，这部分不是本节的重点，大家可以私下思考，这样我们就得到了订单信息了，如表3所示：
表3：外卖订单信息
订单信息中美团红包是基于15元购买了优惠券以后才能使用的优惠，相当于这一单，用户要先买会员获得优惠券，然后在本单同时使用优惠券进行优惠，虽然是同一个订单，但我们可以想象出来，在交易处理层，至少需要做2次处理，一个是对美团会员的处理，另一个是对本单整单的优惠处理；所以订单需要拆成2个子单，一个是外卖单，一个是美团会员单，如表4所示：
表4：父子订单信息
商家的小票中显示商品总价是40，总优惠是19；跟订单11101之间的7元差额是什么呢？其实就是配送费，那么将配送费刨除后跟商家小票一致，可以推断出商家承担了5元的配送优惠成本，加上满减优惠14，商家总优惠成本是19。
但是，发现商家实收17元，那么这4元是什么呢？这里有2个推断，一是美团抽佣4元，另一个可能是商家承担美团红包7元优惠中的4元；如果是取中间可能的话，那么实际的清分结果可能是如下模型：
4元=x+y
x=美团抽佣；x∈[0-4]元
y=分摊美团红包优惠；y∈[0-4]元
4.交易处理
完成了订单以后就需要创建支付账单了，基于以上分析交易处理相对比较复杂，因为要先处理美团会员的购买，然后处理外卖订单，这个过程如图6所示：
图6：交易处理过程
因为有2个子单，所以我们生成2个交易账单，但是在支付的时候我们进行合并支付，账单信息如表5所示：
表5：账单信息
有了账单信息以后，基于账单生成支付请求，这里的支付渠道是广义的，优惠券、满减等都视为一个支付渠道，也就是在支付信息层都算做一个支付方式，如表6所示：
表6：账单中的支付信息
5.支付信息
账单生成以后，请求支付系统生成支付单，用户在端上通过收银台发起支付请求，其中微信支付请求支付系统；优惠类支付我们等待微信支付成功以后请求营销系统，完成优惠券的核销，这样就完成了账单的支付了，这时候账单变为已支付，订单支付状态变为已支付，订单的履约状态变为待配送，支付信息如表7所示：
表7：支付流水信息
6.履约过程
订单变为待配送时，会生成服务订单，也就是配送订单，由骑手小王01抢单了，这里的服务单信息如表8所示：
表8：服务单信息
之后的过程包含了取餐，送餐，确认已送达，服务单完成等，服务单完成以后将订单推送至清算中心进行清分计算，以最终结清各方利益。
7.清算环节
清算系统接收到的清算订单信息包含，订单信息，账单信息，支付信息，履约信息。在计费环节有几个关键的模块，如图7：
图7：计费模型
计费模型就是基于订单业务应该计算出什么样的费用出来，比如本单其实有2个业务，一个是外卖业务，一个是美团会员业务。
假设计费模型是这样的，美团外卖业务需要计算商家应结算金额，抽佣金额，优惠分摊金额；美团会员计费模型需要计算出美团会员费给平台业务的分成，如图8：
图8：应计算费用
再基于业务类型，去查找计费规则，即计费参数，计费基数，计费模式，计费规则；设定规则如图9：
图9：计费规则
那么计费规则，我们可以计算出以下清分结果，如图10：
图10：计费结果
从而得到以下清分结果，如表9：
表9：清分明细
优惠成本的分摊如表10所示：
表10：优惠分摊结果
8.账务
完成清分计费以后就需要请求账务系统完成记账，为了简单这里只对商家的结算和骑手的结算进行记账；这时先生成账务记录，如表11所示：
表11：账务流水明细
入账成功后账户余额发生变化，如表12所示：
表12：账户余额信息
9.结算
商家和骑手都可以在钱包里看到账户余额了，然后可以对余额发起提现；生成提现订单，请求打款中心完成出款，以上整个清结算的流程框架，可以简化成图11：
图11：清结算业务流程
10.从微观到宏观
从上面的案例，并结合宏观部分《上帝视角看支付》，最终我们从宏观看到了微观，最后又从微观收敛到宏观，至此我们抽象出一个典型的支付清结算架构，如图12所示：
图12：支付清结算架构
更多精彩，关注他的公号
