小常识，大学问，一张小票带你看透支付清结算架构明天上线共 2566字，需浏览 6分钟 ·2022-08-16 16:12支付清结算相关的系统写了很多了，单模块介绍的也不少；虽然有几个架构性质的文章，但是有不少朋友反馈说无法串起来；今天我们就从一次外卖的小票来看，将支付清结算串起来会是什么体验!准备好了么，抓好扶手，走起！1.一张小票我们看下面外卖盒上的小票，牛肉拌饭1份一共39元，餐盒费1元，没有配送费，合计40元，优惠了19元，实付21，实收17元我们再看订单的信息，烤肉饭1分39元，打包费1元，配送费原价7元现价2元，美团会员15元；美团红包减7元，满减优惠14元；总优惠26元，合计36元我们发现商家的小票和美团的订单信息之间有不少的差异，特别是优惠的明细展示以及优惠总额和应付总额之间存在差异；下面我们就来顺藤摸瓜，分析背后的玄机我们先认清一个关系，订外卖的陈老师跟商家没有直接的关系，美团跟商家直接是结算关系，也就是美团帮助商家代收餐费，并进行结算；简而言之就是陈老师付给美团综合的外卖钱，美团抽一部分然后给商家结算餐费我们先粗略的假想一下，这个过程是怎么完成的我们先到美团平台选择喜欢的“商品”然后“下单”并生成交易“账单”选择支付方式进行“支付”支付成功后美团要履行承诺把餐送到“履约”完成以后美团就开始进行各方利益的“清分”计算了算清楚应给给各方多少钱时并计入账簿“记账”然后就是进行“结算”按照这个思路，我们来看，上面的小票在每个环节都是怎么处理的呢2.商品商品广泛用于电商系，在o2o领域我们可能叫“服务”多一点，这里其实站在吃货的角度来看，订外卖，买了一份商品也没什么问题；商品模型这里我们不过多介绍，简而言之就是下面这样一个高度抽象的结构那么这一单外卖的商品有哪些呢，有4个（这里我们将配送服务看做商品）这里我们要说一下美团会员，这是美团推出的一个会员服务，相当于花钱买了多张优惠券，所以购买美团会员获得优惠券也是一次交易，而且本交易要先与外卖单，因为外卖单的支付用到了这批券，交易层处理很有意思，大家可以思考一下3.订单选购好了商品，那么就需要下单了，这时候订单会去营销系统获取可以使用的活动优惠或者卡券，本小票我们可以看出来，有这些优惠我们可以使用因为目前我们还不清楚美团和商家之间的清结算协议，所以暂且认为所有优惠由美团提供给用户，后续美团再基于协议跟商家之间做优惠的分摊，这部分不是本文的重点，大家可以私下思考交流这样我们就得到了订单信息了其实我们发现，其中的美团红包是基于15元购买了优惠券以后才能使用的优惠，相当于这一单，你要先买会员获得优惠券，然后在本单同时使用优惠券进行优惠，虽然是同一个订单，但我们可以想象出来，在交易处理层，至少需要做2次处理，一个是对美团会员的处理，另一个是对本单整单的优惠处理；所以订单需要拆成2个子单，一个是外卖单，一个是美团会员单我们看到商家的小票，商品总价是40，总优惠是19；跟订单11101之间的7元差额是什么呢，其实就是配送费，那么将配送费抛出后跟商家小票一致，我们可以推断出商家承担了5元的配送优惠成本，加上满减优惠14，商家总优惠成本是19；但最后我们发现商家实收17元，那么这4元是什么呢？其实我们有2个推断，一是美团抽佣4元，另一个可能是商家承担美团红包7元优惠中的4元；如果是取中间可能的话那么实际可能是4元=x+yx=美团抽佣；x属于[0-4]元y=分摊美团红包优惠；y属于[0-4]元4.交易完成了订单以后就需要创建支付账单了，基于以上分析交易处理是非常复杂的，因为要先处理美团会员的购买，然后处理外卖订单，这里因为有2个子单，所以我们生成2个交易账单，但是在支付的时候我们进行合并支付基于账单生成支付请求5.支付账单生成以后，我们进行支付处理，微信支付请求支付系统，优惠类支付我们等待微信支付成功以后请求营销系统，完成优惠券的核销，这样我们就完成了账单的支付了，这时候账单变为已支付，订单支付状态变为已支付，订单状态变为待配送6.履约订单变为待配送时，会生成服务订单，也就是配送订单，由骑手小王01抢单了然后的过程大家都熟悉，取了餐，送餐，确认已送达，服务单完成，将订单推送至清算中心进行清分计算7.清算清算系统接收到的清算订单信息包含，订单信息，账单信息，支付信息，履约信息在清分计费环节有几个关键的模块，我们可以设定为一下模型计费模型就是基于订单业务我们就知道应该计算出什么样的费用出来，比如本单其实有2个业务，一个是外卖业务，一个是美团会员业务我们假设有计费模型是这样的，美团外卖业务需要计算商家应结算金额，抽佣金额，优惠分摊金额；美团会员计费模型需要计算出美团会员费给平台业务的分成，那么简单起见我们的模型如下我们再基于业务类型，去查找计费规则，什么是计费规则呢，就是计费参数，计费基数，计费模式，计费规则；我们设定规则如下那么计费规则，我们可以计算出以下清分结果所以我们得到以下清分结果剩下的就是优惠成本的分摊了8.账务完成清分计费以后就需要请求账务系统完成记账了，为了简单我们只对商家的结算和骑手的结算进行记账；这时先生成账务记录账务流水去操作账户更新余额，这部分内容大家可以看账户系统设计从入门到精通入账成功后账户余额变为9.结算商家和骑手都可以在钱包里看到账户里入账了，然后可以对余额发起提现；生成提现订单，请求打款中心完成出款，这个我们就不详细介绍了10.这里涉及到的各个系统这里面涉及到了11个系统，我们之前都有文章详细介绍过，大家可以看一下收银台设计方法论支付路由设计详解-我见过的最美算法支付通道介绍和接入订单系统设计解析详解|交易核心设计指南账户系统设计从入门到精通结算系统设计对账系统从入门到精通11.综合架构从上面的案例，并结合之前的一些文章，我们抽象出一个清结算的通用架构，我们称之为“311架构模型”，即分3层，11个系统；所以叫311架构模型；大家记住这个架构，基本可以解决绝大部分平台的订单支付交易清结算业务模型“一张小票看透支付清结算架构（下）”将从平台内部视角出发，详细讲解一笔外卖订单从商品、订单、活动营销、详细计价过程、商家和骑手的清分计费过程、业务记账过程、会计事件设定、业务账到财务账转化的过程，从更精细的链路梳理清楚清结算业务流程和架构声明：以上内容均为案例讲解设定，推测，并非美团真实系统设计，请悉知浏览 18点赞 评论 收藏 分享 手机扫一扫分享分享 举报 评论图片表情视频评价全部评论推荐 一张小票看透支付清结算架构薛老板产品派0一张小票看透支付清结算架构PMCAFF0一文带你看透 Chrome 浏览器架构前端桃园0维金账户及支付清结算系统 严选资金收付、自动化账户管理、业务交易对账、资金合规、场景内金融解决方案。 帮助企业提升中后台资金管理效率。同时助力企业构建自己的支付及科技金融体系，实现企业业务的战略升级。一张图，详解大数据技术架构新机器视觉0一张图，详解大数据技术架构Java技术驿站0支付结算之路由系统设计产品刘0一张图解释清楚大数据技术架构肉眼品世界0一张图区分产品架构、技术架构产品与体验0一张图带你了解大疆无人机测绘解决方案泰伯网0点赞 评论 收藏 分享 手机扫一扫分享分享 举报
