其他分享
首页 > 其他分享> > C端 支付清结算系统

C端 支付清结算系统

作者:互联网

支付清结算系统在现实生活中十分常见,并在多个场景中被应用。本篇文章里,作者结合生活中的现象对支付清结算系统的整体架构进行了梳理,抽象出“311架构模型”。假如你想系统地了解支付清结算系统的话,不妨一起看一下吧。     打开腾讯新闻,查看更多图片 > 支付清结算相关的系统写了很多了,单模块介绍的也不少;虽然有几个架构性质的文章,但是有不少朋友反馈说无法串起来;今天我们就从一次美团外卖的小票来看,将支付清结算串起来会是什么体验!准备好了么,抓好扶手,走起! 一、一张小票 我们看下面外卖盒上的小票,牛肉拌饭1份一共39元,餐盒费1元,没有配送费,合计40元,优惠了19元,实付21,实收17元。 我们再看美团订单的信息,烤肉饭1分39元,打包费1元,配送费原价7元现价2元,美团会员15元;美团红包减7元,满减优惠14元;总优惠26元,合计36元。   我们发现商家的小票和美团的订单信息之间有不少的差异,特别是优惠的明细展示以及优惠总额和应付总额之间存在差异;下面我们就来顺藤摸瓜,分析背后的玄机。 我们先认清一个关系,订外卖的陈老师跟商家没有直接的关系,美团跟商家直接是结算关系,也就是美团帮助商家代收餐费,并进行结算;简而言之就是陈老师付给美团综合的外卖钱,美团抽一部分然后给商家结算餐费。 我们先粗略的假想一下,这个过程是怎么完成的。 我们先到美团平台选择喜欢的“商品”; 然后“下单”并生成交易“账单”; 选择支付方式进行“支付”; 支付成功后美团要履行承诺把餐送到“履约”; 完成以后美团就开始进行各方利益的“清分”计算了; 算清楚应给给各方多少钱时并计入账簿“记账”; 然后就是进行“结算”。 按照这个思路,我们来看,上面的小票在每个环节都是怎么处理的呢? 二、商品 商品广泛用于电商系,在O2O领域我们可能叫“服务”多一点,这里其实站在吃货的角度来看,订外卖,买了一份商品也没什么问题。商品模型这里我们不过多介绍,简而言之就是下面这样一个高度抽象的结构:   那么这一单外卖的商品有哪些呢,有4个(这里我们将配送服务看做商品):   这里我们要说一下美团会员,这是美团推出的一个会员服务,相当于花钱买了多张优惠券,所以购买美团会员获得优惠券也是一次交易。而且本交易要先与外卖单,因为外卖单的支付用到了这批券,交易层处理很有意思,大家可以思考一下。 三、订单 选购好了商品,那么就需要下单了,这时候订单会去营销系统获取可以使用的活动优惠或者卡券,本小票我们可以看出来,有这些优惠我们可以使用:   因为目前我们还不清楚美团和商家之间的清结算协议,所以暂且认为所有优惠由美团提供给用户,后续美团再基于协议跟商家之间做优惠的分摊,这部分不是本文的重点,大家可以私下思考交流。 这样我们就得到了订单信息了:   其实我们发现,其中的美团红包是基于15元购买了优惠券以后才能使用的优惠,相当于这一单,你要先买会员获得优惠券,然后在本单同时使用优惠券进行优惠。 虽然是同一个订单,但我们可以想象出来,在交易处理层,至少需要做2次处理,一个是对美团会员的处理,另一个是对本单整单的优惠处理。所以订单需要拆成2个子单,一个是外卖单,一个是美团会员单。   我们看到商家的小票,商品总价是40,总优惠是19;跟订单11101之间的7元差额是什么呢,其实就是配送费。那么将配送费抛出后跟商家小票一致,我们可以推断出商家承担了5元的配送优惠成本,加上满减优惠14,商家总优惠成本是19。 但最后我们发现商家实收17元,那么这4元是什么呢?其实我们有2个推断,一是美团抽佣4元,另一个可能是商家承担美团红包7元优惠中的4元;如果是取中间可能的话那么实际可能是: 4元=x+y; x=美团抽佣;x属于[0-4]元; y=分摊美团红包优惠;y属于[0-4]元。 四、交易 完成了订单以后就需要创建支付账单了,基于以上分析交易处理是非常复杂的,因为要先处理美团会员的购买,然后处理外卖订单。   这里因为有2个子单,所以我们生成2个交易账单,但是在支付的时候我们进行合并支付。   基于账单生成支付请求。   五、支付 账单生成以后,我们进行支付处理。微信支付请求支付系统,优惠类支付我们等待微信支付成功以后请求营销系统,完成优惠券的核销,这样我们就完成了账单的支付了。这时候账单变为已支付,订单支付状态变为已支付,订单状态变为待配送。   六、履约 订单变为待配送时,会生成服务订单,也就是配送订单,由骑手小王01抢单了。 然后的过程大家都熟悉,取了餐、送餐、确认已送达、服务单完成,将订单推送至清算中心进行清分计算。 七、清算 清算系统接收到的清算订单信息包含,订单信息、账单信息、支付信息、履约信息。       在清分计费环节有几个关键的模块,我们可以设定为一下模型:   计费模型就是,基于订单业务我们就知道应该计算出什么样的费用出来,比如本单其实有2个业务,一个是外卖业务,一个是美团会员业务。 我们假设有计费模型是这样的,美团外卖业务需要计算商家应结算金额、抽佣金额、优惠分摊金额;美团会员计费模型需要计算出美团会员费给平台业务的分成,那么简单起见我们的模型如下:   我们再基于业务类型,去查找计费规则。什么是计费规则呢?就是计费参数、计费基数、计费模式、计费规则;我们设定规则如下: 那么计费规则,我们可以计算出以下清分结果: 所以我们得到以下清分结果:   剩下的就是优惠成本的分摊了。 八、账务 完成清分计费以后就需要请求账务系统完成记账了,为了简单我们只对商家的结算和骑手的结算进行记账;这时先生成账务记录: 账务流水去操作账户更新余额,这部分内容大家可以看《账户系统设计从入门到精通》。 入账成功后账户余额变为: 九、结算 商家和骑手都可以在钱包里看到账户里入账了,然后可以对余额发起提现;生成提现订单,请求打款中心完成出款,这个我们就不详细介绍了。 十、这里涉及到的各个系统 这里面涉及到了11个系统,我们之前都有文章详细介绍过: 十一、综合架构 从上面的案例,并结合之前的一些文章,我们抽象出一个清结算的通用架构,我们称之为“311架构模型”,即分3层、11个系统,所以叫311架构模型。大家记住这个架构,基本可以解决绝大部分平台的订单支付交易清结算业务模型。   十二、思考题 这张打车小票,司机手机的结算信息与用户订单的结算信息,你能想象出来系统层的实现方式以及业务流转么?用户、滴滴、司机三者之间的清结算结果是怎么样的呢?滴滴这一单是挣钱了还是赔钱了呢?   声明:以上内容均为案例讲解设定、推测,并非美团真实系统设计,请悉知。   https://xw.qq.com/cmsid/20210517A0774B00  

标签:结算,美团,系统,订单,外卖,支付,优惠
来源: https://www.cnblogs.com/SlashOut/p/15498610.html