支付系統架構設計(上)

9 評論 32966 瀏覽 223 收藏 10 分鐘

本文描述的支付系統作為整個電商系統的一部分,也可以作為獨立的支付系統對接多個前端業務系統。各公司應根據自身業務發展和規劃進行取舍,不可照搬。

綜述

支付是任何商業模式變現的最后一公里,是業務流程閉環的關鍵一環。

本文涉及的支付系統沿襲《電商系統:對賬設計》第一節的描述,支付系統和業務系統解耦處理。業務系統關注商品、庫存、交易流程、運營服務等。而支付系統要關注支付流程的完整性、業務合規性以及技術可實現性

因為支付行業有各種監管規定,尤其是涉及跨境電商更加復雜。支付系統要兼并合規性、易用性、安全性為一體,在前期設計時一定要綜合考慮。

上圖為通用支付系統的架構參考。不同的業務模式和需求可以按照不同的維度分層和功能劃分。(關鍵在于根據實際需求取舍,不可照搬)下面將對各個層級做詳細介紹。

前臺應用層

這一層主要是面向客戶,由業務系統的類型決定。通俗說法就是客戶支付的場景是什么樣的。不同的支付渠道會有各自的支付產品來滿足各種場景。

如:微信渠道提供的支付產品【JSAPI支付】就可以滿足線下掃碼、公眾號、PC網站(web)三種場景。

移動應用(安卓、IOS)場景下,微信和支付寶分別提供有APP支付產品。(詳情點擊圖片)

前臺應用層的主要目的是幫助產品在設計支付系統時,理清業務所涉及的收款場景和系統類型。

API接入層:

這一層主要是面向各個業務系統。比如接口權限、數據權限、緊急止付、快速凍結等。

當業務系統和支付系統非一個網段內,是不是要考慮白名單,以及控制不同應用只能操作應用范圍內的商戶。尤其是中國人民銀行于今年(2019)下發《關于進一步加強支付結算管理防范電信網絡新型違法犯罪有關事項的通知》(銀發[2019]85號)后,這一塊尤其關鍵。

這一層可以參考銀聯、微信支付、支付、連連支付等公司開放平臺的技術規范。

接入服務層

這一層的核心在于梳理清楚對外(業務系統)輸出的能力范圍。

通俗理解為api功能,當然也可以通過微服務的服務注冊來實現。

商戶服務

入網:

商戶簽約流程(入網、建檔、進件):線上還是線下,需要哪些資料,是否需要簽合同蓋章等;如果商戶入網需要和支付渠道直接簽約,那此處的入網能力就沒有,直接提供頁面給商戶,錄入支付參數信息即可。(目前服務商版微信APP支付需要商戶自己去微信申請)

結算、提現:

擔保交易場景下,就會涉及針對訂單的指令清算(類似確認收貨后訂單才完成)。有些支付渠道給商戶結算的資金并非直接到商戶的銀行卡,而是結算到商戶在渠道開的錢包。很多時候大家所說的結算,本質上是提現流程中的結算,而非交易流程的結算。因為交易流程的結算在資金到錢包時已經完成。

充值:

當支付系統涉及B2B支付場景,比如租金繳納、供應鏈金融等,會涉及付款方商戶充值。有些企業2B業務比較多,通過企業錢包(一般通過銀行托管賬戶實現)使付款充值到錢包,收款方主動(自動或者手動)劃扣,達到線上核銷。(B2B場景后續會專題討論,此為業財一體化核心環節)

還有一種場景就是商戶入住平臺需要交納保證金。商戶充值后,平臺方凍結該筆資金。

賬單:

此處賬單泛指可以根據商戶需要,同步商戶的支付訂單、訂單流水、資金流水等信息。(請參考:《電商系統:記賬設計之訂單管理、流水管理》)

分賬:

分賬在此暫不介紹,后續文章專題討論。

應用服務

應用服務比較簡單,一般涉及如下幾點:

支付渠道管理:參考下文【網關服務】。

支付產品選擇:取決于業務系統類型和支付渠道,參考【前臺應用層】。

應用參數管理:支付渠道校驗業務系統的有效性,確保通道不被濫用。

  • APP支付需要配置微信開放平臺注冊申請的appid或者支付寶開放平臺的APPID;
  • 小程序、公眾號需要配置微信公眾平臺的appid;
  • 公眾號需要配置支付目錄;
  • PC網站、手機H5 需要提交備案域名;
  • 等……

商戶層級管理:有些應用會涉及多商戶,應用需要維護商戶層級關系。

個人服務

如果支付系統不涉及錢包服務,就不會有充、提、轉、支、收,借貸、白條這個服務也不好承載。常見錢包可以分為實體錢包和虛擬錢包(通俗叫法)。

實體錢包(支付渠道管理錢包及其賬務):

通過接口提交資料在支付渠道側開設錢包,前提是支付渠道必須有相關牌照。目前市場上錢包多種形式,一般有如下幾種類型:

  • 實名制預付卡包裝成線上錢包(也可以是內部兩個賬戶打通)。需要有預付卡牌照和互聯網支付牌照,很多商場、園區APP即是這種,和實體一卡通打通。
  • 虛擬賬戶(美團、支付寶余額、微信余額)
  • 銀行托管賬戶開設子賬戶(摩拜、P2P產品)
  • 銀行二類戶、三類戶包裝(華為錢包、部分券商軟件余額)

余額寶、微信零錢通,不屬于余額,屬于購買的基金理財產品。其性質和券商軟件的股票資產、P2P持有資產類似,屬于最廣義的貨幣供應量(M3)。

實體錢包在開戶時會根據實名驗證的強度對錢包的額度、用途、范圍、時效等有所限制。

虛擬錢包(本地系統管理錢包及其賬務):

這種只適用于公司內部充值、消費使用。比如有些食堂、連鎖餐廳、理發、健身房等,皆是如此,在用戶充值時,錢已到了商家的結算卡。這種錢包一般是無法提現的。

總結

做支付系統一定不能脫離實際業務場景,更不能照搬其他公司方案。核心在于理清業務場景(決定支付產品的選擇)、商戶類型(決定入網流程、分賬需求、結算類型),然后選擇合適的支付渠道??梢赃x擇微信、支付寶直連通道、可以選擇其服務商、聚合支付供應商。

對接銀行或者銀聯商務的快捷支付、認證支付也是選擇之一。如果沒有精力做一整套的支付系統,市場上有可選擇的“第四方支付”提供的SAAS服務。

接下來將分享分賬、業務服務、網關服務、清算&賬務服務,以及支付中心運營管理平臺(web后臺)的設計。

 

本文由 @俠之大者 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 求分享網關服務和支付中心運營管理平臺,謝謝!

    來自廣東 回復
  2. 你好,你寫的十分不錯,商戶如果需要和支付渠道簽約為啥入網能力就沒有呢

    來自北京 回復
  3. 你好,非常專業,有問題想請教下。
    現在很多電商平臺都有余額的概念,C端用戶在平臺下單,直接可以用余額支付,也可以針對余額直接提現到支付寶/微信/銀行卡賬戶,但是這些電商平臺并沒有支付牌照,這樣合規嗎?不合規的話,為什么電商平臺還能一直這樣搞下去?

    來自安徽 回復
    1. 看模式。
      就拿人人都是產品經理的打賞,是 C2B2C的。作者提現需要收手續費。但是公眾號打賞就是C2C。
      你說的電商,比如小鵝通,他是類PAAS服務,商家入駐后是是 C2B2B,核心是看平臺和商家的合同。如果商家委托代收是可以的。

      平臺收錢是需要待開票的。你看本文【個人服務】錢包那一塊,需要先搞清楚平臺的錢包類型 和 其與商家的合作關系,才能定型。

      來自廣東 回復
  4. 你好,寫的很棒,就是有些地方沒有看懂。另外,請教一個支付牌照的問題,就是我不設立錢包或者虛擬錢包,但是我在生態范圍內設定另外一種虛擬的貨幣,類似qq幣。用戶通過可以購買虛擬幣,然后通過虛擬幣在生態范圍內消費,這種方式可以規避支付牌照么?國家有沒有類似的規定?謝謝。

    來自湖北 回復
    1. 以下回答僅供參考,因為這個判斷準則不好把握。
      為用戶開立具有充值、消費和提現等支付功能的類支付賬戶的電子錢包,開設這種錢包肯定涉及“平臺結算”。這種屬于“無證經營網絡支付業務”。這也會涉及到開票的問題。
      一般來說你開的錢包:不能跨法人、不能跨領域、不能跨地區。(集團形式的看子公司是否并表也是一個準則)

      來自廣東 回復
    2. 來自廣東 回復
  5. 此處多了一個,應該刪掉。
    這一塊主要是方便梳理系統核心邏輯。開票、撤銷服務等都可以放在這里。
    謝謝提醒。

    回復
  6. 業務服務層里面怎么有兩個賬戶服務模塊?僅僅是畫圖為了對齊還是?

    來自四川 回復