詳解B2C電商支付中心的產品架構

15 評論 18744 瀏覽 138 收藏 13 分鐘

電商系統中,支付中心作為交易的重要支撐體系,是整個系統的重中之重。那它的架構有哪些關鍵部分?底層設計又要注意什么呢?本文將為大家解答這一系列問題。

一、開篇

上一篇文章《B2C電商系統產品架構:全局分析系統定義與職責》中,我們主要描述下B2C電商系統整體產品架構圖,里面各個模塊系統每一個展開其實就是一個龐大的產品體系,而這個也正是后續該系列文章的大綱。

本篇文章,我們主要來拆解下一般電商公司【支付中心】的產品架構圖。

在我們開始正式講解之前,大家先描述下自己對支付中心的認知。我想可能對于大部分普通用戶,對支付中心的理解可能更多就是付款頁面了,即收銀臺,用戶選擇不同支付方式進行付款。甚至連訂單申請的退款到賬,用戶也基本不會聯想到支付中心身上。

支付中心作為交易三流向中的資金流支持體系,是最為重要核心的部分,搞不好對公司就會產生不可估量的損失。接下來,我們就來系統性地了解下經典B2C電商的【支付中心】究竟有哪些模塊,每個模塊又有什么職能?各模塊之間又是如何聯動的。

二、正文

說到底,支付中心的原子能力就是收、退、打,其他所有的一切,幾乎都是圍繞這幾個基礎能力搭建出來的應用產品。

支付中心對內的上游主要是業務訂單系統(本文主要描述經典場景),訂單會傳入支付結算所需要的核心信息,支付中心接收后轉化為系統內的收退打相關指令,并進行信息的回執;

支付中心對外是跟三方支付公司/銀行系統進行互動,支付中心將平臺的收退打指令轉為三方真實資金的收退打指令,三方產生信息回執;

而支付中心內部,主要包含收單系統與清結算系統。前者主要負責收款,后者主要負責退款與打款。

一圖一文,以下這張圖片就是本篇文章描述的核心:

簡單描述此圖的結構:

  1. ?最上邊的訂單系統,就是觸發指令給支付中心的上游,一般就是公司的各個業務訂單系統;
  2. ?橙色背景區域內,就是支付中心的內部系統模塊組成;
  3. ?左側的模塊,是三方支付機構內部的大概邏輯(不再引入銀行,主要為了描述支付中心對外的資金信息交互);
  4. ?粗的線條,表示比較大的系統模塊或實體之間的交互邏輯;
  5. ?細的線條,表示系統模塊內的指令與模塊之間的交互邏輯;
  6. ?箭頭指向只是表明大邏輯上有關聯或順序,但僅限于宏觀層面,不開展到非常細節的產品設計層次;

接下來,我們從【收單】【清結算】【賬戶】【對賬】【交易安全】5個部分來展開:

1. 收單系統

收單系統的主要職責就是收款,對業務要保證下單支付轉化率,對系統要保證安全穩定、精準無誤;

我們用大概的時間順序來串聯描述各個環節:

1)訂單調用支付中心:

上游創建訂單后,會發起付款請求,比較常見的就是:

  1. 普通支付(原子層:父訂單:支付單=1:1,子訂單邏輯訂單體系內處理)
  2. 合單支付(原子層,訂單:支付單=N:N,支付中心還有一個父支付單與N支付單進行同步)
  3. 補差支付(原子層,訂單:支付單=N:N,支付中心根據N個原始支付單合并一個總支付單與訂單進行同步)

我們就拿比較經典的普通支付來說明,訂單創建后,獲取到業務、用戶和商品相關信息,然后創建支付單實體,支付單包含了支付收單所必須的上游信息。

2)支付單與收銀臺

支付單創建之后,上游訂單維持“待支付”狀態,用戶可以在限定時間內發起支付行為,即吊起收銀臺。

這里注意,收銀臺本質上就是收款通道的整體邏輯控制,不同終端、不同業務可選擇支付通道的不同,例如:微信內是不可能用競品支付方式的、有的業務壞賬率高無法使用分期產品、信用卡手續費誰承擔、哪個收款通道默認選中/展示排序等等。這些本質上就是結合業務不同情況,為支付轉化率和交易安全作保障。

收銀臺支付通道也分以下幾種常見類型:

  1. 當前主流電商基本都是三方支付,如微信、支付寶、京東支付,也有部分銀行支付,還有花唄、白條等消費分期通道
  2. 另外,部分平臺也提供平臺賬戶余額支付,即錢包業務
  3. 還有一些會把不同支付通道進行組合,如分期與非分期支付組合,方便額度不夠或想減少消費分期額的用戶。

3)收銀臺調用三方支付系統

當用戶選擇某種特定支付通道之后,收銀臺就會用sdk或內嵌M頁吊起支付通道,用戶放棄某個通道之后,大部分場景可以更換其他支付通道繼續支付。

在三方支付的體系內,在使用余額或綁卡支付成功后,真實資金會從用戶在三方的用戶賬戶余額轉往平臺在三方的商戶賬戶余額(有賬期的暫不展開);同時,三方告訴平臺的支付中心用戶已完成付款,平臺的支付單可以變更已付款狀態,并回執給訂單變更訂單狀態。

2. 清結算系統

清結算系統分為清分系統、結算系統組成。

1)清分系統

清分系統職責:處理上游業務單的分賬請求,并轉換成為標準的清分記錄,進而在業務結算時機調用結算系統產生結算記錄;

一條清分記錄,會被拆分為N條結算記錄。清分記錄可以理解為業務一筆訂單的完整分賬信息,可能包含很多目標賬戶,結算的時機也可能不同,經過清分系統之后,會轉化為一條條格式化的結算原始記錄,主要是出資賬戶和單個目標賬戶、結算金額、結算時間等核心信息;

2)結算系統

結算系統職責:將清分系統產生的結算記錄,按照賬期產生結算單,進而按照商戶系統合同打款信息進行轉賬打款操作(包含欠款扣款邏輯);

結算系統,將待結算的結算記錄按照結算周期和結算對象,分別進行合并運算,生成結算單(如果是負值結算單可能涉及到滾動生成結算單)。結算記錄:結算單=N:1。

結算單如果是正值,則生成打款單/提現單,然后將錢款進行打出,也有可能是多批次打出。結算單:打款單=1:N;

商戶會按照結算單與自己在平臺經營的訂單信息進行對賬,看是否有誤差,以及關注結算單的打款進度。

3. 賬戶系統

賬戶基礎原子能力有:充、提、凍、轉(支付、轉賬、扣罰)。支付單、結算單/提現單、凍結/解凍、轉賬等都會產生賬戶流水。

賬戶分類一般分為3大類:平臺類賬戶、用戶類賬戶、映射賬戶。

  1. ?平臺類賬戶根據不同財務用途會劃分很多種,例如代收代付、預收、應收、成本、資金等等。
  2. ?用戶類賬戶,體現在用戶端就是余額錢包的場景,可以充值、提現、凍結等操作。
  3. ?映射類賬戶,主要用來映射平臺在三方的資金情況,便于平臺實時了解平臺的各渠道資金情況,便于調撥等用途;

4. 對賬系統

標準的對賬系統,大概分為以下4種對賬:

  1. ?賬證:業務層-賬務層,即業務訂單與支付中心賬務進行對賬;
  2. ?賬賬:賬務層-會計層,總賬與總賬、明細賬、日記賬、明細賬之間相互核對的過程;
  3. ?賬實:內部-外部,即支付中心與三方及銀行進行對賬;
  4. ?賬表:會計報表-會計科目,跟本系統層面關聯較弱。

5. 支付安全

支付中心的天職就是為平臺交易安全提供保證。不僅要關注交易的雙方角色,還要核心關注錢款的流向,尤其是收、打這2個節點。

  • 第一方面,支付中心包保證合規、合法。首先支付中心設計要滿足監管部門的要求,同時還要結合業務上游和支付中心聯動,積極反詐騙、洗錢、信用卡套現等違規違法行為。
  • 第二方面,要做到系統健壯。從系統設計、系統實施、系統運營,都需要非常嚴謹,兜底也要建立完備的預警機制、熔斷機制,為公司業務上游提供安全可信賴的支付服務。

三、結尾

本文聚焦在支付中心的框架內,比較宏觀介紹了部分系統的定義和職責,另外有些模塊也都還在探索摸索階段,并非標準答案。

支付中心系統底層設計比較固定,最關鍵是能夠結合企業自己的業務做好對應的架構設計和運行支撐。跟著業務變化而迭代系統,這樣才能做出一個有靈魂的支付中心。

一圖一文系列,第2篇,收~

 

作者:減形簡遠,轉轉交易中臺產品負責人。公眾號:產品雜談

本文由 @減形簡遠 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 幫上大忙了。

    來自廣東 回復
  2. 親,感謝你的文章,有所啟發!方便私聊一下嗎?

    來自浙江 回復
  3. 這個圖上面怎么沒有售后系統啊

    來自湖南 回復
  4. 我要催更啦~~對于我這種入門小白來說太有用了?。?/p>

    來自山東 回復
    1. 一起崔

      回復
  5. 非常期待下一篇 老哥抓緊更新呢 雖然是做技術的 但對產品也很感興趣

    來自江蘇 回復
    1. 感謝支持,最近有點忙。剛新發了一篇,說產品的用戶思維,希望能對你有用。

      回復
  6. 這圖牛逼

    來自江蘇 回復
  7. 圖畫的挺好的,淺顯易懂。加油

    來自江蘇 回復
    1. 感謝支持!

      回復
  8. 嗯嗯 篇幅有限 著重先寫的框架。后邊會對某些模塊展開單獨寫。

    回復
    1. 啥時候出呀

      回復
    2. 大佬啥時候出后續

      來自廣東 回復
  9. 某些地方寫的太簡略了,做技術的也挺難看懂這個流程

    來自天津 回復
    1. 同意
      在細化就更好了 估計只有財務人員明白

      回復