一文搞懂 “支付 · 清結算 · 賬務” 全局
大家對外賣都很熟悉，因爲會經常點外賣，我們以外賣場景爲例，分析外賣的整個交易鏈路，從用戶下單、商家接單、分配騎手、騎手取餐、配送到用戶取餐，從訂單、計價、配送、清分、記賬、結算到付款，講清楚每個環節的邏輯和內容。
從一張外賣的小票入手進行分析，研究支付微觀層面的業務流轉、單據的生成等支付細節，最後抽象出一個可通用的支付清結算體系架構出來。
4.1 一張小票
看下面外賣盒上的紙質小票：牛肉拌飯 1 份一共 39 元、餐盒費 1 元，沒有配送費，合計 40 元，優惠了 19 元，實付 21，實收 17 元；
再看外賣平臺（以下簡稱 “平臺”）APP 中的訂單信息：烤肉飯 1 分 39 元、打包費 1 元、配送費原價 7 元現價 2 元、平臺會員 15 元；其中紅包減 7 元、滿減優惠 14 元，總優惠 26 元，訂單合計 36 元，如圖 4-1 所示：
圖中可以看出來，商家的小票信息和平臺的訂單信息之間有不少的差異，特別是優惠的明細展示、優惠總額和應付總額之間存在差異。下面我們就順藤摸瓜，分析背後的玄機。
4.1.1 外賣單據
外賣過程中會產生很多的單據，不同環節的單據會提供給不同的參與者使用，不同單據記載着不同的但又相互關聯的信息，我們需要了解這些主要的單據，並知道其用途、相互之間的關聯關係和設計方法。這些單據主要包括用戶訂單、商家小票、商家後臺賬單、騎手賬單、平臺內部單據等，接下來逐一分析。
用戶訂單：在外賣的客戶端裏，用戶的外賣訂單信息記錄了購買的商品、商品價格、優惠信息、支付信息、配送信息、商家信息等全部內容，這些信息是外賣平臺給用戶提供的交易記錄，如圖 4-2 所示。
圖 4-2 用戶的外賣訂單信息
商家小票：用戶收到的餐盒上都會附帶一個紙質小票，也記載着該單商品的基本信息，這個信息是出餐商家給用戶提供的本單餐品的服務內容以及收費情況，如圖 4-1（右）所示。
商家賬單：是平臺提供給商家的在平臺上的經營數據，例如賣了多少餐、掙了多少錢、給商家付了多少款等信息，如圖 4-3 所示。
騎手賬單：是平臺提供給騎手的在平臺的上的服務信息，包括接單信息、收入信息、獎懲信息、付款情況等內容，如圖 4-4 所示。
圖 4-4 騎手賬單
平臺內部單據：是平臺自己內部存在很多業務系統，這些系統協同完成整個外賣業務。例如訂單系統記錄訂單，計費系統記錄計費結果，賬務系統記錄賬務信息等，這些系統依賴各種單據完成記錄以及推動流程的進行，並通過各種單據互相傳遞信息，如圖 4-5 所示爲後臺訂單管理。
4.1.2 外賣業務模型
我們先明白一個關係，訂外賣的用戶跟商家沒有直接的關係，平臺跟商家是結算關係，也就是平臺幫助商家代收餐費，並向商家結算收入。簡而言之，用戶付錢給平臺，平臺抽一部分佣金，剩餘部分結算給商家，如圖 4-6 所示。
圖 4-6 交易關係
這個過程大致是這樣的，用戶先到平臺選擇喜歡的 “餐品”，然後“下單”，生成交易“賬單”，用戶選擇支付方式進行“支付”，支付成功後平臺要履行承諾把餐送到，“履約” 完成以後平臺就開始進行各方利益的 “清分”，計算清楚應給誰多少錢，並“記賬”，最後將款項“結算” 給商家，這個過程如圖 4-7 所示。
圖 4-7 外賣交易鏈條
當然，一次外賣業務會涉及到非常多的參與者和過程，每個參與者都有自己的一個子流程，這些子流程共同串起整個外賣交易。比如用戶選品、下單、支付、取餐、評價；商家接單、製作；騎手接單、到店、取餐、配送、確認送達；平臺創建訂單、計價、支付處理、分配騎手、記賬結算等。
將上述的不同角色、不同行爲、不同節點所形成的一個複雜的流程繪製出來，以方便我們動態地審視整個交易鏈條的全部事件，這也將有利於後續我們去設計抽象清結算的業務節點，如圖 4-8 所示。
圖 4-8 外賣個角色的操作流程
基於上面的業務分析，接下來分析開頭那張小票在每個環節是怎麼處理的，都生成了什麼單據，單據中包含哪些信息。
4.2 用戶下單
用戶下單是一次外賣旅程的開始，我們對這個過程再熟悉不過了。用戶選擇菜品，平臺計算本單相應的優惠，計算應該支付的金額等內容，用戶完成支付。
爲了便於分析，我們讓訂單更加簡單一些，僅分析展出最核心的字段，但是所涉及到的訂單結構是完整的；本單用戶看到的訂單信息如圖 4-9 所示。
圖 4-9 本次下單的訂單信息
4.2.1 商品
商品概念廣泛應用於電商，在 o2o 領域可能叫 “服務” 多一點，站在喫貨的角度來看，訂外賣，買了一份商品也可以說的過去；一個簡單的商品模型如圖 4-10 所示。
圖 4-10 商品信息結構
本案例中的這單外賣共有 3 個商品以及配送費，我們將商品信息、商品原價、購買數量、配送費等內容整理到表格中，如表 4-1 所示：
表 4-1：外賣單的商品信息
這裏需要特別說一下平臺會員，這是平臺推出的一個會員服務，相當於花錢買了多張優惠券，如圖 4-11 所示，所以購買平臺會員獲得優惠券也是一次交易，而且本交易要先與外賣單，因爲外賣單的支付用到了這批券。
圖 4-11 平臺會員詳情
4.2.2 優惠
選購了商品以後，需要知道這一單有什麼優惠，本單的優惠主要有 3 個：配送費 5 元減免、平臺紅包減 7 元、滿減優惠減 14。把優惠信息增加到表 4-1 中得到了包含了優惠信息的表格，該訂單的優惠比較簡單，都是針對整單的優惠，沒有針對單品的優惠，未來完整起見我們將單品優惠也放進去，只不過優惠金額爲 0，如表 4-2 所示。
4.2.3 計價
該過程是要計算出本單應該付多少錢，計價包含很多內容，比如計算優惠、計算商品總價、計算配送費、結算優惠後的訂單金額、計算用戶應付金額等，計算完成以後反饋給交易，常見的計價模塊架構如圖 4-12 所示。
圖 4-12 計價模塊架構圖
對於例子中訂單的計價相對比較簡單，有時候點的外賣菜品多，計價會複雜一些，從而計價過程也相對複雜很多，但無論計價場景複雜還是簡單，基本原理是一樣的。我們將計價結果增加到表格中，如表 4-3 所示。
用戶完成了訂單信息的填寫和提交，內部系統完成了交易的計價，接下來就是下單了，交易系統請求訂單系統完成訂單的創建。
4.2.4 訂單生成
交易系統請求訂單系統創建訂單，因爲不清楚平臺和商家之間的清結算協議，所以暫且認爲所有優惠由平臺提供給用戶，後續平臺再基於協議跟商家之間做優惠的分攤，將上述商品、優惠、計價等信息集成到一起，就得到了完成的訂單信息了，如表 4-4 所示。
訂單信息中平臺紅包是基於 15 元購買了平臺會員以後才能使用的優惠，因此這一單，需要用戶先購買會員獲得優惠券，然後在本單使用從而獲得紅包優惠。雖然在用戶看來是同一個訂單，但在交易處理層，至少需要做 2 次處理，一個是對購買平臺會員的交易處理，另一個是對本單整單的交易處理；所以訂單需要拆成 2 個子單，一個是外賣單，一個是平臺會員購買訂單，如表 4-5 所示：
商家的小票中顯示商品總價是 40，總優惠是 19；跟訂單 11101 之間的 26 元優惠存在 7 元的差額，是什麼呢？其實就是平臺紅包 7 元，本單配送費的 5 元優惠和滿減 14 是商家優惠，所以商家總優惠 19 元，而平臺紅包優惠 7 元，本單總優惠 26 元。
但是，發現商家實收 17 元，那麼這 4 元是什麼呢？這裏有 2 個推斷，一是平臺抽傭 4 元，另一個可能是商家承擔了 7 元平臺紅包優惠中的 4 元；如果是取中間可能的話，那麼實際的清分結果可能是如下模型：
4 元 = x+y
x = 平臺抽傭；x∈[0-4] 元
y = 分攤平臺紅包優惠；y∈[0-4] 元
4.2.5 交易處理
完成了訂單創建以後就需要創建支付賬單了。根據上述分析，本單的交易處理相對比較複雜，因爲要先處理平臺會員的購買交易，然後處理外賣訂單交易，這個過程如圖 4-12 所示。
圖 4-12 交易處理過程
因爲有 2 個子單，所以我們生成 2 個交易賬單，但是在支付的時候進行合併支付，這樣做的好處是可以解耦 2 個交易處理流程，賬單信息如表 4-6 所示。
有了賬單信息以後，基於賬單生成支付請求，這裏的支付渠道是廣義的，其中優惠券、滿減等都視爲一個支付渠道，也就是在支付信息層都算做一種支付方式，如表 4-7 所示。
4.2.6 支付處理
賬單生成以後，請求支付系統生成支付單，用戶在客戶端上通過收銀臺發起支付請求，其中微信支付請求支付系統；優惠類支付我們等待微信支付成功以後請求營銷系統，完成優惠券的核銷，這樣就完成了整個賬單的支付了，此時賬單變爲已支付，訂單支付狀態變爲已支付，訂單的履約狀態變爲待配送，支付信息如表 4-8 所示。
4.3 履約過程
用戶支付成功以後進入履約過程，整個過程包括了商家的接單出餐、騎手的派單和配送、用戶的確認收餐以及整個過程的管控。
4.3.1 商家接單
商家在其後臺可以看到該筆訂單，然後選擇接單，進行菜品的製作和打包，等待騎手來取餐。以下信息不是我們案例中訂單的信息，大家可以自行把本單信息填充到以下的商家賬單信息中即可。從圖中可以看出賬單中展示了商品信息和數量、打包費、優惠信息以及優惠的承擔方，如圖 4-13 所示。
4.3.2 騎手配送
一個訂單可以平臺分配給騎手，也可以騎手自己搶單，有很多種方式；這裏關於運力的調度和策略不過多贅述。
騎手在騎手端可以看到附近用戶下的全部訂單，並可以做出決策要不要槍這一單，對於騎手來說距離越短、掙得越多、肯定就越喜歡，搶單頁如圖 4-14 所示。
如果覺得這一單的配送費很高，還有獎勵活動，那麼可以點進去看一看，從地圖裏可以看出這一單的店鋪在哪要配送到哪裏，肯定是越近越好，目的地的單量越多越好，配送地圖如圖 4-15 所示。
圖 4-15 騎手接單配送路程信息
在搶單詳情頁，騎手也可以看到這一單涉及到的菜品信息、詳細的配送費信息等內容，便於騎手做要不要搶單的決策，如圖 4-16 所示。
圖 4-16 訂單搶單詳情頁
騎手搶了訂單後就可以去店裏取餐了，同時用戶在客戶端也可以看到騎手的實時位置和配送狀態，這樣可以極大的緩解用戶等待的焦慮。
訂單變爲待配送時，會生成服務訂單，也就是配送訂單，例如由騎手小王 01 搶單了，此時服務單信息如表 4-9 所示：
之後的過程包含了取餐、送餐、確認已送達、服務單完成等，服務單完成以後將訂單推送至清算中心進行清分計算，以結清各方利益。
4.3.3 管控業務
整個交易過程中會存在各種的突發事件，比如用戶把訂單取消了、商家拒單了、騎手拒單改派了、騎手把用戶的餐弄丟了等等，這時都需要進行一個判責的處理，是誰的責任，要不要罰錢，需不需要封禁等。
4.4 清算
用戶下了單，商家制作了餐，騎手完成了配送，用戶完成了評價，訂單就正式完結了，過程中，如果發生了突發事件會被管控。每個環節都可能需要進行記賬，而記賬業務之前需要先完成計費和清分，比如完單以後商家傭金的計算、過程中騎手獎懲的計算、商家的結算收入、騎手的結算收入等計費業務，這就是接下來要介紹的清算業務。
4.4.1 費用
費用是業務層信息到賬務層信息轉換的非常關鍵的要素。交易過程中不同的節點、不同的對象、不同的菜品或者活動都會產生不同的費用，比如商家賣了一些菜品，屬於商家的菜品費；平臺爲商家提供了交易平臺和配送服務，所以平臺也會收取商家的佣金，這樣就需要一個佣金的費用。
同樣，財務需要基於業務做會計記賬，那麼不能直接用業務數據直接入賬，而是以費用視角入賬，比如抽商家的佣金費轉換爲 “平臺收入” 計入會計收入類科目。
這樣我們就需要建立一個費用體系，業務的新增和變化，都需要針對性的建立相應的費用，每個費用也就有了其依賴的業務場景。而對於這一單外賣來說我們需要到如下的費用，如表 4-4 所示。
4.4.2 清分
清算系統接收到的清算請求數據包含訂單信息、賬單信息、支付信息、履約信息等。在計費環節有幾個關鍵的模塊以及之間的關係如圖 4-17。
圖 4-17 計費模型
計費模型就是基於訂單業務應該計算出什麼樣的費用出來，例如本單其實有 2 個業務，一個是外賣業務，一個是平臺會員業務。計費模型是平臺外賣業務需要計算商家應結算金額、抽佣金額、優惠分攤金額；平臺會員計費模型需要計算出平臺會員費。再基於業務類型，去查找對應的計費規則，即計費參數、計費基數、計費模式等；本單的計費規則和結果如表 4-11 所示。
4.5 賬務
整個交易過程都需要進行賬務的記錄，無論是用戶支付了多少錢、菜品是多少錢還是優惠了多少錢，以及計費得到的應結商家收入和騎手配送收入，甚至是給商家、騎手代扣代繳的稅費。
4.5.1 記賬場景定義
我們知道記賬是在整個交易過程中分多次記錄的，用戶支付成功以後要記賬，商家接單以後要記賬，騎手搶單以後要記賬，完單以後要記賬；這樣我們就需要跟業務層約定業務場景的識別，而業務場景就對應了記賬的場景。
根據業務的發生流程，這裏應該包含正向及逆向、訂單類、支付類、管控類、獎懲類、結算類等場景。我們將業務劃分成這樣的場景並給於定義，並且我們要約定好用什麼信息去判定該場景已經發生，比如可以用訂單狀態，工單流轉等標記業務事件，如表 4-12 所示。
4.5.2 記賬設定
定義好了業務場景以及費用，就需要設定什麼場景發生了需要記什麼費用，這些費用要記哪些賬，因爲一個費用的發生不一定只記一筆賬，可能要計入多個賬戶，我們需要設定每個類場景要記什麼賬。
當然每個場景發生以後記那些賬不僅僅由訂單狀態這個場景決定，還需要其他要素參與，比如 01 支付成功，我們還需要知道這個是什麼類型的訂單，另外需要不需關注渠道，因爲不同渠道的訂單可能需要記跟渠道的分成，如表 4-13 所示。
4.5.3 記賬交互
業務場景發生以後，後端清分系統需要知道業務發生了，這裏需要一個交互信息的方式，可以通過 MQ 的手段，比如訂單支付成功了，訂單層就發一個 MQ，清分系統監聽到該 MQ 以後通過訂單狀態字段判斷訂單狀態，如果是 “01” 就知道這是 “01 用戶支付” 成功發生了。
如果該 MQ 裏包含了記賬需要的全部信息，則可以以 MQ 爲依據生成業務單據，如果 MQ 內沒有過多信息，就需要訂單業務給一個查詢數據的服務，比如查詢接口或者 SQL，通過該服務獲取記賬需要的全部數據，如圖 4-18 所示。
圖 4-18 記賬交互流程
4.5.4 記賬規則
每個業務場景發生以後，需要記哪些賬在上面已經完成設定。那麼這些賬怎麼記呢？計給哪些對象，計入哪些賬戶呢？這就是記賬規則的職能了，比如我們介紹 “01 支付成功” 以後的記賬規則，如表 4-14 所示。
有了規則以後，業務發生時就可以通過規則判定該場景需要記哪些賬，然後獲得相應的數據；獲得數據以後先生成原始的業務憑證存下來，然後進行清分處理；這裏記賬單據我們按生成的先後順序和依賴關係分成三類：業務憑證，清分明細，賬戶明細，會計憑證。
4.5.5 業務憑證
是業務發生後完成計費以後的最原始的數據，比如訂單支付成功以後獲得的記賬數據存儲在清分系統，這筆數據裏包含了 “01 用戶支付成功” 需要記賬的全部信息，如表 4-15 所示。
上面我們介紹了 “01 用戶支付成功” 場景發生以後，我們需要記錄 3 個費用“1001，,3005，,30010”，這樣我們根據業務憑證的數據進行清分，並根據記賬規則知道每個清分出的費用、金額、對象就有了，清分結果如表 4-16 所示。
4.5.6 賬戶流水
有了清分明細以後，我們就可以根據記賬規則計入對應賬戶，更新賬戶餘額，記錄賬戶流水了，如圖 4-19 所示。
圖 4-19 記賬流程
爲了簡單起見，這裏只對商家的結算和騎手的結算進行記賬，生成的賬戶流水，如表 4-17 所示。
入賬成功後，更新賬戶餘額，賬戶餘額信息如表 3-13 所示。
4.6 結算
結算就是將應付商家和騎手的收入支付出去的過程，可以將商家和騎手的收入直接付款至他們的銀行卡中，整個結算過程包括了計稅、開票、結算處理、付款處理等過程。
4.6.1 稅票
計稅模式可以按照每個賬務明細進行計稅、也可以按照每個結算週期進行一次性計稅；計稅過程需要知道稅種是什麼、稅基是什麼、稅率是多少等計稅規則。
假如我們按照賬務明細進行計稅，也就是每入一筆賬就需要計稅；入賬成功以後賬務系統將入賬明細推送給稅務子系統，稅務子系統根據稅種、稅基、稅率等配置計算該筆入賬的稅額，並推送賬務系統進行稅務的扣除，這裏要考慮平臺是否需要代扣代繳，如果不需要代扣代繳就不需要進行稅務的扣除，可以僅進行計算，提供給商家和騎手進行稅務什麼用，如圖 4-20 所示。
圖 4-20 稅務流程
4.6.2 結算付款
按照約定我們需要完成給商家和騎手的結算，將商家的應收和騎手的收入打款給他們。不同的城市、不同的商家簽訂了不同的結算週期，例如日結、周結、月結；結算的依據可以是賬戶的當期餘額，也可以是當期的賬戶流水；結算的方向可以是指定的平臺虛擬賬戶或者生成結算單付款至指定銀行卡。商家和騎手可以在錢包裏看到賬戶餘額，然後發起提現；生成提現訂單，請求打款中心完成出款，整個清結算的流程框架如圖 4-21 所示。
圖 4-21 清結算業務流程
4.7 清結算架構
通過上面對一張外賣小票的詳細分析，使得大家對全鏈路有了清晰的認識，包括交易流、支付流、賬務流、結算流等環節。最後，我們將抽象出一套可複用的支付清結算架構出來。
4.7.1 外賣清結算架構
外賣業務框架應該包含不同端的操作流程，內部平臺的交易流程以及內部系統之間的交互，另外還應該包含接入的外部服務渠道，比如支付渠道、開票渠道等。對外賣業務流程架構抽象如圖 4-22 所示。
圖 4-22 外賣全業務流程架構
再將各角色、各類單據、各系統之間的關係細化以後，可以得到外賣業務的支付清結算產品架構，如圖 4-23 所示。
圖 4-23 外賣支付清結算架構
4.7.2 支付清結算架構
依據上面的案例，剔除外賣業務場景以後，可以抽象出一個典型的支付清結算架構，可以應用於更多的業務場景，例如打車、電商、家政等，如圖 4-23 所示。
圖 4-23 通用支付清結算架構
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/OG_NoiMBEWBgGHSlqTuE4Q