編輯導語：支付清結算系統在現實生活中十分常見，并在多個場景中被應用。本篇文章里，作者結合生活中的現象對支付清結算系統的整體架構進行了梳理，抽象出“311架構模型”。假如你想系統地了解支付清結算系統的話，不妨一起看一下吧。

支付清結算相關的系統寫了很多了，單模塊介紹的也不少；雖然有幾個架構性質的文章，但是有不少朋友反饋說無法串起來；今天我們就從一次美團外賣的小票來看，將支付清結算串起來會是什么體驗！準備好了么，抓好扶手，走起！

一、一張小票

我們看下面外賣盒上的小票，牛肉拌飯1份一共39元，餐盒費1元，沒有配送費，合計40元，優惠了19元，實付21，實收17元。

我們再看美團訂單的信息，烤肉飯1分39元，打包費1元，配送費原價7元現價2元，美團會員15元；美團紅包減7元，滿減優惠14元；總優惠26元，合計36元。

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

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

我們先粗略的假想一下，這個過程是怎么完成的。

1. 我們先到美團平臺選擇喜歡的“商品”；
2. 然后“下單”并生成交易“賬單”；
3. 選擇支付方式進行“支付”；
4. 支付成功后美團要履行承諾把餐送到“履約”；
5. 完成以后美團就開始進行各方利益的“清分”計算了；
6. 算清楚應給給各方多少錢時并計入賬簿“記賬”；
7. 然后就是進行“結算”。

按照這個思路，我們來看，上面的小票在每個環節都是怎么處理的呢？

二、商品

商品廣泛用于電商系，在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架構模型。大家記住這個架構，基本可以解決絕大部分平臺的訂單支付交易清結算業務模型。

十二、思考題

這張打車小票，司機手機的結算信息與用戶訂單的結算信息，你能想象出來系統層的實現方式以及業務流轉么？用戶、滴滴、司機三者之間的清結算結果是怎么樣的呢？滴滴這一單是掙錢了還是賠錢了呢？

聲明：以上內容均為案例講解設定、推測，并非美團真實系統設計，請悉知。

#專欄作家#

陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。10年產品設計經驗，曾任職于某頭部金融，某頭部支付機構，云對賬創始人獲千萬融資。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議