一張小票看透支付清結算架構
支付清結算相關的系統寫了很多了，單模塊介紹的也不少；雖然有幾個架構性質的文章，但是有不少朋友反饋說無法串起來；今天我們就從一次美團外賣的小票來看，將支付清結算串起來會是什麼體驗! 準備好了麼，抓好扶手，走起！
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+y
x = 美團抽傭；x 屬於 [0-4] 元
y = 分攤美團紅包優惠；y 屬於 [0-4] 元
4. 交易
完成了訂單以後就需要創建支付賬單了，基於以上分析交易處理是非常複雜的，因爲要先處理美團會員的購買，然後處理外賣訂單，
這裏因爲有 2 個子單，所以我們生成 2 個交易賬單，但是在支付的時候我們進行合併支付
基於賬單生成支付請求
5. 支付
賬單生成以後，我們進行支付處理，微信支付請求支付系統，優惠類支付我們等待微信支付成功以後請求營銷系統，完成優惠券的核銷，這樣我們就完成了賬單的支付了，這時候賬單變爲已支付，訂單支付狀態變爲已支付，訂單狀態變爲待配送
6. 履約
訂單變爲待配送時，會生成服務訂單，也就是配送訂單，由騎手小王 01 搶單了
然後的過程大家都熟悉，取了餐，送餐，確認已送達，服務單完成，將訂單推送至清算中心進行清分計算
7. 清算
清算系統接收到的清算訂單信息包含，訂單信息，賬單信息，支付信息，履約信息
在清分計費環節有幾個關鍵的模塊，我們可以設定爲一下模型
計費模型就是基於訂單業務我們就知道應該計算出什麼樣的費用出來，比如本單其實有 2 個業務，一個是外賣業務，一個是美團會員業務
我們假設有計費模型是這樣的，美團外賣業務需要計算商家應結算金額，抽佣金額，優惠分攤金額；美團會員計費模型需要計算出美團會員費給平臺業務的分成，那麼簡單起見我們的模型如下
我們再基於業務類型，去查找計費規則，什麼是計費規則呢，就是計費參數，計費基數，計費模式，計費規則；我們設定規則如下
那麼計費規則，我們可以計算出以下清分結果
所以我們得到以下清分結果
剩下的就是優惠成本的分攤了
8. 賬務
完成清分計費以後就需要請求賬務系統完成記賬了，爲了簡單我們只對商家的結算和騎手的結算進行記賬；這時先生成賬務記錄
賬務流水去操作賬戶更新餘額，這部分內容大家可以看賬戶系統設計從入門到精通
入賬成功後賬戶餘額變爲
9. 結算
商家和騎手都可以在錢包裏看到賬戶裏入賬了，然後可以對餘額發起提現；生成提現訂單，請求打款中心完成出款，這個我們就不詳細介紹了
10. 這裏涉及到的各個系統
這裏面涉及到了 11 個系統，我們之前都有文章詳細介紹過，大家可以看一下
11. 綜合架構
從上面的案例，並結合之前的一些文章，我們抽象出一個清結算的通用架構，我們稱之爲 “311 架構模型”，即分 3 層，11 個系統；所以叫 311 架構模型；大家記住這個架構，基本可以解決絕大部分平臺的訂單支付交易清結算業務模型
12. 輔助學習
大家可以加入微信交流羣與我交流；或者加入陳老師的產品寶藏星球獲取相關係統的設計原型和資料，也可以去星球專屬在線課堂看每個系統的視頻講解
思考題：這張打車小票，司機手機的結算信息與用戶訂單的結算信息；你能想象出來系統層的實現方式以及業務流轉麼？用戶，滴滴，司機三者之間的清結算結果是怎麼樣的呢，滴滴這一單是掙錢了還是賠錢了呢？歡迎微信羣或者星球內打卡交流。
聲明：以上內容均爲案例講解設定，推測，並非美團真實系統設計，請悉知
10 年產品設計經驗，4 年社交，2 年電商，5 年支付；曾任職於某頭部金融，某頭部支付機構；雲對賬創始人獲千萬融資；PMCAFF 專欄作者；把所見 · 所聞 · 所想 · 所做，在夜深人靜處沉澱成文字留給這個世界！
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tImlxD85LrmAN8aTApyKMw