一張小票看透支付清結(jié)算架構(gòu)

11 評(píng)論 11606 瀏覽 85 收藏 15 分鐘

編輯導(dǎo)語(yǔ):支付清結(jié)算系統(tǒng)在現(xiàn)實(shí)生活中十分常見,并在多個(gè)場(chǎng)景中被應(yīng)用。本篇文章里,作者結(jié)合生活中的現(xiàn)象對(duì)支付清結(jié)算系統(tǒng)的整體架構(gòu)進(jìn)行了梳理,抽象出“311架構(gòu)模型”。假如你想系統(tǒng)地了解支付清結(jié)算系統(tǒng)的話,不妨一起看一下吧。

支付清結(jié)算相關(guān)的系統(tǒng)寫了很多了,單模塊介紹的也不少;雖然有幾個(gè)架構(gòu)性質(zhì)的文章,但是有不少朋友反饋說無法串起來;今天我們就從一次美團(tuán)外賣的小票來看,將支付清結(jié)算串起來會(huì)是什么體驗(yàn)!準(zhǔn)備好了么,抓好扶手,走起!

一、一張小票

我們看下面外賣盒上的小票,牛肉拌飯1份一共39元,餐盒費(fèi)1元,沒有配送費(fèi),合計(jì)40元,優(yōu)惠了19元,實(shí)付21,實(shí)收17元。

我們?cè)倏疵缊F(tuán)訂單的信息,烤肉飯1分39元,打包費(fèi)1元,配送費(fèi)原價(jià)7元現(xiàn)價(jià)2元,美團(tuán)會(huì)員15元;美團(tuán)紅包減7元,滿減優(yōu)惠14元;總優(yōu)惠26元,合計(jì)36元。

一張小票看透支付清結(jié)算架構(gòu)

我們發(fā)現(xiàn)商家的小票和美團(tuán)的訂單信息之間有不少的差異,特別是優(yōu)惠的明細(xì)展示以及優(yōu)惠總額和應(yīng)付總額之間存在差異;下面我們就來順藤摸瓜,分析背后的玄機(jī)。

一張小票看透支付清結(jié)算架構(gòu)

我們先認(rèn)清一個(gè)關(guān)系,訂外賣的陳老師跟商家沒有直接的關(guān)系,美團(tuán)跟商家直接是結(jié)算關(guān)系,也就是美團(tuán)幫助商家代收餐費(fèi),并進(jìn)行結(jié)算;簡(jiǎn)而言之就是陳老師付給美團(tuán)綜合的外賣錢,美團(tuán)抽一部分然后給商家結(jié)算餐費(fèi)。

我們先粗略的假想一下,這個(gè)過程是怎么完成的。

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

一張小票看透支付清結(jié)算架構(gòu)

按照這個(gè)思路,我們來看,上面的小票在每個(gè)環(huán)節(jié)都是怎么處理的呢?

二、商品

商品廣泛用于電商系,在O2O領(lǐng)域我們可能叫“服務(wù)”多一點(diǎn),這里其實(shí)站在吃貨的角度來看,訂外賣,買了一份商品也沒什么問題。商品模型這里我們不過多介紹,簡(jiǎn)而言之就是下面這樣一個(gè)高度抽象的結(jié)構(gòu):

一張小票看透支付清結(jié)算架構(gòu)

那么這一單外賣的商品有哪些呢,有4個(gè)(這里我們將配送服務(wù)看做商品):

一張小票看透支付清結(jié)算架構(gòu)

這里我們要說一下美團(tuán)會(huì)員,這是美團(tuán)推出的一個(gè)會(huì)員服務(wù),相當(dāng)于花錢買了多張優(yōu)惠券,所以購(gòu)買美團(tuán)會(huì)員獲得優(yōu)惠券也是一次交易。而且本交易要先與外賣單,因?yàn)橥赓u單的支付用到了這批券,交易層處理很有意思,大家可以思考一下。

一張小票看透支付清結(jié)算架構(gòu)

三、訂單

選購(gòu)好了商品,那么就需要下單了,這時(shí)候訂單會(huì)去營(yíng)銷系統(tǒng)獲取可以使用的活動(dòng)優(yōu)惠或者卡券,本小票我們可以看出來,有這些優(yōu)惠我們可以使用:

一張小票看透支付清結(jié)算架構(gòu)

因?yàn)槟壳拔覀冞€不清楚美團(tuán)和商家之間的清結(jié)算協(xié)議,所以暫且認(rèn)為所有優(yōu)惠由美團(tuán)提供給用戶,后續(xù)美團(tuán)再基于協(xié)議跟商家之間做優(yōu)惠的分?jǐn)偅@部分不是本文的重點(diǎn),大家可以私下思考交流。

這樣我們就得到了訂單信息了:

一張小票看透支付清結(jié)算架構(gòu)

其實(shí)我們發(fā)現(xiàn),其中的美團(tuán)紅包是基于15元購(gòu)買了優(yōu)惠券以后才能使用的優(yōu)惠,相當(dāng)于這一單,你要先買會(huì)員獲得優(yōu)惠券,然后在本單同時(shí)使用優(yōu)惠券進(jìn)行優(yōu)惠。

雖然是同一個(gè)訂單,但我們可以想象出來,在交易處理層,至少需要做2次處理,一個(gè)是對(duì)美團(tuán)會(huì)員的處理,另一個(gè)是對(duì)本單整單的優(yōu)惠處理。所以訂單需要拆成2個(gè)子單,一個(gè)是外賣單,一個(gè)是美團(tuán)會(huì)員單。

一張小票看透支付清結(jié)算架構(gòu)

我們看到商家的小票,商品總價(jià)是40,總優(yōu)惠是19;跟訂單11101之間的7元差額是什么呢,其實(shí)就是配送費(fèi)。那么將配送費(fèi)拋出后跟商家小票一致,我們可以推斷出商家承擔(dān)了5元的配送優(yōu)惠成本,加上滿減優(yōu)惠14,商家總優(yōu)惠成本是19。

但最后我們發(fā)現(xiàn)商家實(shí)收17元,那么這4元是什么呢?其實(shí)我們有2個(gè)推斷,一是美團(tuán)抽傭4元,另一個(gè)可能是商家承擔(dān)美團(tuán)紅包7元優(yōu)惠中的4元;如果是取中間可能的話那么實(shí)際可能是:

  • 4元=x+y;
  • x=美團(tuán)抽傭;x屬于[0-4]元;
  • y=分?jǐn)偯缊F(tuán)紅包優(yōu)惠;y屬于[0-4]元。

四、交易

完成了訂單以后就需要?jiǎng)?chuàng)建支付賬單了,基于以上分析交易處理是非常復(fù)雜的,因?yàn)橐忍幚砻缊F(tuán)會(huì)員的購(gòu)買,然后處理外賣訂單。

一張小票看透支付清結(jié)算架構(gòu)

這里因?yàn)橛?個(gè)子單,所以我們生成2個(gè)交易賬單,但是在支付的時(shí)候我們進(jìn)行合并支付。

一張小票看透支付清結(jié)算架構(gòu)

基于賬單生成支付請(qǐng)求。

一張小票看透支付清結(jié)算架構(gòu)

五、支付

賬單生成以后,我們進(jìn)行支付處理。微信支付請(qǐng)求支付系統(tǒng),優(yōu)惠類支付我們等待微信支付成功以后請(qǐng)求營(yíng)銷系統(tǒng),完成優(yōu)惠券的核銷,這樣我們就完成了賬單的支付了。這時(shí)候賬單變?yōu)橐阎Ц?,訂單支付狀態(tài)變?yōu)橐阎Ц叮唵螤顟B(tài)變?yōu)榇渌汀?/p>

一張小票看透支付清結(jié)算架構(gòu)

六、履約

訂單變?yōu)榇渌蜁r(shí),會(huì)生成服務(wù)訂單,也就是配送訂單,由騎手小王01搶單了。

一張小票看透支付清結(jié)算架構(gòu)

然后的過程大家都熟悉,取了餐、送餐、確認(rèn)已送達(dá)、服務(wù)單完成,將訂單推送至清算中心進(jìn)行清分計(jì)算。

七、清算

清算系統(tǒng)接收到的清算訂單信息包含,訂單信息、賬單信息、支付信息、履約信息。

一張小票看透支付清結(jié)算架構(gòu)

一張小票看透支付清結(jié)算架構(gòu)

一張小票看透支付清結(jié)算架構(gòu)

一張小票看透支付清結(jié)算架構(gòu)

在清分計(jì)費(fèi)環(huán)節(jié)有幾個(gè)關(guān)鍵的模塊,我們可以設(shè)定為一下模型:

一張小票看透支付清結(jié)算架構(gòu)

計(jì)費(fèi)模型就是,基于訂單業(yè)務(wù)我們就知道應(yīng)該計(jì)算出什么樣的費(fèi)用出來,比如本單其實(shí)有2個(gè)業(yè)務(wù),一個(gè)是外賣業(yè)務(wù),一個(gè)是美團(tuán)會(huì)員業(yè)務(wù)。

我們假設(shè)有計(jì)費(fèi)模型是這樣的,美團(tuán)外賣業(yè)務(wù)需要計(jì)算商家應(yīng)結(jié)算金額、抽傭金額、優(yōu)惠分?jǐn)偨痤~;美團(tuán)會(huì)員計(jì)費(fèi)模型需要計(jì)算出美團(tuán)會(huì)員費(fèi)給平臺(tái)業(yè)務(wù)的分成,那么簡(jiǎn)單起見我們的模型如下:

一張小票看透支付清結(jié)算架構(gòu)

我們?cè)倩跇I(yè)務(wù)類型,去查找計(jì)費(fèi)規(guī)則。什么是計(jì)費(fèi)規(guī)則呢?就是計(jì)費(fèi)參數(shù)、計(jì)費(fèi)基數(shù)、計(jì)費(fèi)模式、計(jì)費(fèi)規(guī)則;我們?cè)O(shè)定規(guī)則如下:

一張小票看透支付清結(jié)算架構(gòu)

那么計(jì)費(fèi)規(guī)則,我們可以計(jì)算出以下清分結(jié)果:

一張小票看透支付清結(jié)算架構(gòu)

所以我們得到以下清分結(jié)果:

一張小票看透支付清結(jié)算架構(gòu)

剩下的就是優(yōu)惠成本的分?jǐn)偭恕?/p>

一張小票看透支付清結(jié)算架構(gòu)

八、賬務(wù)

完成清分計(jì)費(fèi)以后就需要請(qǐng)求賬務(wù)系統(tǒng)完成記賬了,為了簡(jiǎn)單我們只對(duì)商家的結(jié)算和騎手的結(jié)算進(jìn)行記賬;這時(shí)先生成賬務(wù)記錄:

一張小票看透支付清結(jié)算架構(gòu)

賬務(wù)流水去操作賬戶更新余額,這部分內(nèi)容大家可以看《賬戶系統(tǒng)設(shè)計(jì)從入門到精通》。

一張小票看透支付清結(jié)算架構(gòu)

入賬成功后賬戶余額變?yōu)椋?/p>

一張小票看透支付清結(jié)算架構(gòu)

九、結(jié)算

商家和騎手都可以在錢包里看到賬戶里入賬了,然后可以對(duì)余額發(fā)起提現(xiàn);生成提現(xiàn)訂單,請(qǐng)求打款中心完成出款,這個(gè)我們就不詳細(xì)介紹了。

十、這里涉及到的各個(gè)系統(tǒng)

這里面涉及到了11個(gè)系統(tǒng),我們之前都有文章詳細(xì)介紹過:

詳解 | 支付收銀臺(tái)前端設(shè)計(jì)》、《詳解:支付路由設(shè)計(jì)》、《聊聊支付通道那些事兒——介紹和接入》、《訂單系統(tǒng)設(shè)計(jì)解析》、《詳解 | 關(guān)于交易的核心設(shè)計(jì)指南》、《賬戶系統(tǒng)設(shè)計(jì)從入門到精通》、《詳解 | 結(jié)算系統(tǒng)設(shè)計(jì)》、《對(duì)賬系統(tǒng)從入門到精通》。

十一、綜合架構(gòu)

從上面的案例,并結(jié)合之前的一些文章,我們抽象出一個(gè)清結(jié)算的通用架構(gòu),我們稱之為“311架構(gòu)模型”,即分3層、11個(gè)系統(tǒng),所以叫311架構(gòu)模型。大家記住這個(gè)架構(gòu),基本可以解決絕大部分平臺(tái)的訂單支付交易清結(jié)算業(yè)務(wù)模型。

一張小票看透支付清結(jié)算架構(gòu)

十二、思考題

這張打車小票,司機(jī)手機(jī)的結(jié)算信息與用戶訂單的結(jié)算信息,你能想象出來系統(tǒng)層的實(shí)現(xiàn)方式以及業(yè)務(wù)流轉(zhuǎn)么?用戶、滴滴、司機(jī)三者之間的清結(jié)算結(jié)果是怎么樣的呢?滴滴這一單是掙錢了還是賠錢了呢?

一張小票看透支付清結(jié)算架構(gòu)

聲明:以上內(nèi)容均為案例講解設(shè)定、推測(cè),并非美團(tuán)真實(shí)系統(tǒng)設(shè)計(jì),請(qǐng)悉知。

#專欄作家#

陳天宇宙,微信公眾號(hào):陳天宇宙,人人都是產(chǎn)品經(jīng)理專欄作家。10年產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn),曾任職于某頭部金融,某頭部支付機(jī)構(gòu),云對(duì)賬創(chuàng)始人獲千萬(wàn)融資。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 訂單 和 交易賬單 看上去是1-1對(duì)應(yīng)的(或者與子單),記錄的內(nèi)容也很類似,分開設(shè)計(jì)的目的是什么?二者關(guān)注點(diǎn)有什么差異?與其它模塊的交互有什么不同?

    來自上海 回復(fù)
    1. 簡(jiǎn)單理解為,訂單:用戶購(gòu)買商品的需求單,用來講訴用戶想要什么東西。交易賬單:記錄資金流水變動(dòng)的工具,發(fā)生一筆資金交易,就會(huì)生成一條交易賬單記錄。交易賬單的統(tǒng)計(jì)便于之后的財(cái)務(wù)對(duì)賬。
      從關(guān)注點(diǎn)以及上下游模塊交互來看:
      訂單:關(guān)注商品或服務(wù)的詳細(xì)信息(如名稱、數(shù)量、價(jià)格、發(fā)貨地址等)。與以下模塊交互,比如支付模塊-確認(rèn)支付狀態(tài),觸發(fā)支付流程。庫(kù)存模塊:更新商品庫(kù)存數(shù)量。物流模塊:傳遞發(fā)貨信息,跟蹤物流狀態(tài)。
      交易賬單:關(guān)注資金變動(dòng)的詳細(xì)信息(如變動(dòng)金額、變動(dòng)時(shí)間、變動(dòng)類型:支付/退款等)。與以下模塊交互,比如支付模塊:確認(rèn)資金變動(dòng)情況,出款/入款。財(cái)務(wù)模塊:提供賬單數(shù)據(jù),支持財(cái)務(wù)報(bào)表的生成和分析。

      來自浙江 回復(fù)
  2. 訂單總金額組成中,若有平臺(tái)補(bǔ)貼,或者會(huì)員優(yōu)惠金額,平臺(tái)為了和各方進(jìn)行結(jié)算,需要營(yíng)銷系統(tǒng)在銀行有資金存儲(chǔ)嗎?若需要有真實(shí)的資金存儲(chǔ),豈不是要占據(jù)平臺(tái)大量的現(xiàn)金?請(qǐng)陳老師不吝指教~

    來自北京 回復(fù)
    1. 合規(guī)情況下需要,營(yíng)銷補(bǔ)貼本身就是成本,談不上占用;按需充值即可,不需要提前充值大量資金,否則就真是占用了

      來自北京 回復(fù)
    2. 按需應(yīng)該有個(gè)前提,就是平臺(tái)和其他玩家有固定的結(jié)算周期,結(jié)算前,按照清算結(jié)果進(jìn)行充值即可?

      來自北京 回復(fù)
    3. 是的,比如這個(gè)前提就是確保正常分賬結(jié)算;在這個(gè)前提之下,可以自己靈活控制這部分資金

      來自北京 回復(fù)
  3. 第八部分,入賬成功后賬戶余額變更,為何“17.00”、“7.00”是在凍結(jié)中?我理解,既然入賬成功,不應(yīng)該在可用余額里面嗎?

    來自北京 回復(fù)
    1. 賬戶本身有凍結(jié)能力,是否需要凍結(jié),怎么凍結(jié),凍結(jié)多久,按實(shí)際需要設(shè)置即可;案例中沒有說明,只是默認(rèn)凍結(jié)而已;比如有些場(chǎng)景資金雖然入賬,但會(huì)凍結(jié)一定周期,這個(gè)也是按照實(shí)際業(yè)務(wù)需要設(shè)置;但賬戶本身有這樣的能力;比如微信的分賬場(chǎng)景下,款項(xiàng)是先凍結(jié),發(fā)起分賬后才會(huì)解凍

      來自北京 回復(fù)
  4. 會(huì)計(jì)核心那里要怎么記賬呢?

    來自廣東 回復(fù)
    1. 會(huì)計(jì)核心按照會(huì)計(jì)復(fù)試記賬即可;每個(gè)業(yè)務(wù)場(chǎng)景,會(huì)計(jì)分錄按照會(huì)計(jì)要求設(shè)定

      來自北京 回復(fù)
  5. 這篇文章寫得非常好,咋沒人關(guān)注呢。
    正好在開發(fā)電商的訂單和結(jié)算這塊,受教了。
    不知可否加個(gè)好友?

    來自廣東 回復(fù)