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
 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM