見字如面，我是軍哥！

我很少推薦別人的公眾號，因為我能看上的原創(chuàng)公眾號并不多，讓我主動推薦就更難了。

今天這位朋友叫宇宙，認識有兩年了，在支付行業(yè)里非常有名氣，最近閑著無聊翻了他多篇原創(chuàng)文章之后，我發(fā)現(xiàn)他對支付這種極其復雜領域的業(yè)務架構/產(chǎn)品架構已經(jīng)到了爐火純青的地步了，推薦給各位，我相信你一定會回頭來感謝我的！

下面是他的一篇原創(chuàng)，本文頭部和尾部都有他的公號卡片，文章不長，請認真看完～

從一次美團外賣的小票入手進行分析，研究支付微觀層面的業(yè)務流轉(zhuǎn)、單據(jù)的生成等支付微觀細節(jié)。

1.一張小票

看下面外賣盒上的小票，牛肉拌飯1份一共39元，餐盒費1元，沒有配送費，合計40元，優(yōu)惠了19元，實付21，實收17元；再看美團訂單的信息，烤肉飯1分39元，打包費1元，配送費原價7元現(xiàn)價2元，美團會員15元；美團紅包減7元，滿減優(yōu)惠14元；總優(yōu)惠26元，合計36元，如圖1所示：

圖1：美團外賣小票和訂單信息

圖中可以看出商家的小票信息和美團的訂單信息之間有不少的差異，特別是優(yōu)惠的明細展示，以及優(yōu)惠總額和應付總額之間存在差異；下面我們就來順藤摸瓜，分析背后的玄機。

我們先認清一個關系，訂外賣的用戶跟商家沒有直接的關系，美團跟商家直接是結算關系，也就是美團幫助商家代收餐費，并進行結算；簡而言之就是用戶付給美團綜合的外賣錢，美團抽一部分然后給商家結算餐費，如圖2所表達的關系：

圖2：交易關系

粗略的假想一下，這個過程是怎么完成的，用戶先到美團平臺選擇喜歡的“商品”，然后“下單”，生成交易“賬單”，用戶選擇支付方式進行“支付”，支付成功后美團要履行承諾把餐送到，“履約”完成以后美團就開始進行各方利益的“清分”，計算了算清楚應給給各方多少錢時并計入賬簿“記賬”，然后就是進行“結算”，這個過程如圖3所示：

圖3：業(yè)務流程

下面，基于上面的業(yè)務流程，分析小票在每個環(huán)節(jié)是怎么處理的，都生成了什么單據(jù)，單據(jù)中包含哪些信息。

2.商品信息

商品廣泛用于電商，在o2o領域可能叫“服務”多一點，站在吃貨的角度來看，訂外賣，買了一份商品也可以說的通；商品模型這里就不過多介紹，簡而言之就是圖4所示的信息結構。

圖4：商品信息結構

案例中的這單外賣的商品有4個（這里我們將配送服務看做商品），如表1所示：

表1：外賣單的商品信息

這里需要說一下美團會員，這是美團推出的一個會員服務，相當于花錢買了多張優(yōu)惠券，如圖5所示，所以購買美團會員獲得優(yōu)惠券也是一次交易，而且本交易要先與外賣單，因為外賣單的支付用到了這批券。

圖5：美圖會員詳情

3.訂單信息

選購好了商品，接下來就是下單了，這時候交易系統(tǒng)會去營銷系統(tǒng)獲取可以使用的活動優(yōu)惠或者卡券，本小票可以看出來，有這些優(yōu)惠可以使用，見表2：

表2：使用的優(yōu)惠信息

因為目前還不清楚美團和商家之間的清結算協(xié)議，所以暫且認為所有優(yōu)惠由美團提供給用戶，后續(xù)美團再基于協(xié)議跟商家之間做優(yōu)惠的分攤，這部分不是本節(jié)的重點，大家可以私下思考，這樣我們就得到了訂單信息了，如表3所示：

表3：外賣訂單信息

訂單信息中美團紅包是基于15元購買了優(yōu)惠券以后才能使用的優(yōu)惠，相當于這一單，用戶要先買會員獲得優(yōu)惠券，然后在本單同時使用優(yōu)惠券進行優(yōu)惠，雖然是同一個訂單，但我們可以想象出來，在交易處理層，至少需要做2次處理，一個是對美團會員的處理，另一個是對本單整單的優(yōu)惠處理；所以訂單需要拆成2個子單，一個是外賣單，一個是美團會員單，如表4所示：

表4：父子訂單信息

商家的小票中顯示商品總價是40，總優(yōu)惠是19；跟訂單11101之間的7元差額是什么呢？其實就是配送費，那么將配送費刨除后跟商家小票一致，可以推斷出商家承擔了5元的配送優(yōu)惠成本，加上滿減優(yōu)惠14，商家總優(yōu)惠成本是19。

但是，發(fā)現(xiàn)商家實收17元，那么這4元是什么呢？這里有2個推斷，一是美團抽傭4元，另一個可能是商家承擔美團紅包7元優(yōu)惠中的4元；如果是取中間可能的話，那么實際的清分結果可能是如下模型：

4元=x+y

x=美團抽傭；x∈[0-4]元

y=分攤美團紅包優(yōu)惠；y∈[0-4]元

4.交易處理

完成了訂單以后就需要創(chuàng)建支付賬單了，基于以上分析交易處理相對比較復雜，因為要先處理美團會員的購買，然后處理外賣訂單，這個過程如圖6所示：

圖6：交易處理過程

因為有2個子單，所以我們生成2個交易賬單，但是在支付的時候我們進行合并支付，賬單信息如表5所示：

表5：賬單信息

有了賬單信息以后，基于賬單生成支付請求，這里的支付渠道是廣義的，優(yōu)惠券、滿減等都視為一個支付渠道，也就是在支付信息層都算做一個支付方式，如表6所示：

表6：賬單中的支付信息

5.支付信息

賬單生成以后，請求支付系統(tǒng)生成支付單，用戶在端上通過收銀臺發(fā)起支付請求，其中微信支付請求支付系統(tǒng)；優(yōu)惠類支付我們等待微信支付成功以后請求營銷系統(tǒng)，完成優(yōu)惠券的核銷，這樣就完成了賬單的支付了，這時候賬單變?yōu)橐阎Ц?#xff0c;訂單支付狀態(tài)變?yōu)橐阎Ц?#xff0c;訂單的履約狀態(tài)變?yōu)榇渌?#xff0c;支付信息如表7所示：

表7：支付流水信息

6.履約過程

訂單變?yōu)榇渌蜁r，會生成服務訂單，也就是配送訂單，由騎手小王01搶單了，這里的服務單信息如表8所示：

表8：服務單信息

之后的過程包含了取餐，送餐，確認已送達，服務單完成等，服務單完成以后將訂單推送至清算中心進行清分計算，以最終結清各方利益。

7.清算環(huán)節(jié)

清算系統(tǒng)接收到的清算訂單信息包含，訂單信息，賬單信息，支付信息，履約信息。在計費環(huán)節(jié)有幾個關鍵的模塊，如圖7：

圖7：計費模型

計費模型就是基于訂單業(yè)務應該計算出什么樣的費用出來，比如本單其實有2個業(yè)務，一個是外賣業(yè)務，一個是美團會員業(yè)務。

假設計費模型是這樣的，美團外賣業(yè)務需要計算商家應結算金額，抽傭金額，優(yōu)惠分攤金額；美團會員計費模型需要計算出美團會員費給平臺業(yè)務的分成，如圖8：

圖8：應計算費用

再基于業(yè)務類型，去查找計費規(guī)則，即計費參數(shù)，計費基數(shù)，計費模式，計費規(guī)則；設定規(guī)則如圖9：

圖9：計費規(guī)則

那么計費規(guī)則，我們可以計算出以下清分結果，如圖10：

圖10：計費結果

從而得到以下清分結果，如表9：

表9：清分明細

優(yōu)惠成本的分攤?cè)绫?0所示：

表10：優(yōu)惠分攤結果

8.賬務

完成清分計費以后就需要請求賬務系統(tǒng)完成記賬，為了簡單這里只對商家的結算和騎手的結算進行記賬；這時先生成賬務記錄，如表11所示：

表11：賬務流水明細

入賬成功后賬戶余額發(fā)生變化，如表12所示：

表12：賬戶余額信息

9.結算

商家和騎手都可以在錢包里看到賬戶余額了，然后可以對余額發(fā)起提現(xiàn)；生成提現(xiàn)訂單，請求打款中心完成出款，以上整個清結算的流程框架，可以簡化成圖11：

圖11：清結算業(yè)務流程

10.從微觀到宏觀

從上面的案例，并結合宏觀部分《上帝視角看支付》，最終我們從宏觀看到了微觀，最后又從微觀收斂到宏觀，至此我們抽象出一個典型的支付清結算架構，如圖12所示：

圖12：支付清結算架構

更多精彩，關注他的公號

總結

以上是生活随笔為你收集整理的一张美团外卖的小票看透支付清结算架构！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。