一文搞懂第三方支付系統架構設計
支付方式的發展歷程是怎樣的?第一方、二方、三方、四方支付是什麼?三方支付系統的背後支撐體系是怎樣的?一個第三方支付系統由哪些部分組成?各個組成部分的作用原理是什麼?本文作者將細緻而全面地帶你深入到支付系統的技術設計中,助你體系化掌握支付系統的技術全貌!
本文將是一個系列內容,後續還將發佈交易、退款、結算等各個環節的技術知識,感興趣的讀者朋友記得關注騰訊雲開發者公衆號,不錯過後續內容
01 序言
1.1 背景
支付方式的發展歷程是怎樣的?第一方、二方、三方、四方支付是什麼?三方支付系統的背後支撐體系是怎樣的?一個第三方支付系統由哪些部分組成?各個組成部分的作用原理是什麼?我會盡可能以通俗易懂的方式來組織結構,從客觀現實需要來引出實現,讓讀者能夠更容易理解這一金融基礎設施的內部基本原理。
文章內容僅爲個人觀點,如有不同看法,敬請指正。
1.2 專業名詞
本節預先介紹一些下文出現的重要專業名詞(下劃線標註),可快速瀏覽便於後續返回查閱。
02 支付發展歷史
我們日常生活中使用的微信支付、支付寶都屬於第三方支付應用,那麼什麼是第三方支付?爲什麼叫做第三方支付?第一方支付和第二方支付又是什麼呢?還有第四方支付嗎?我們不妨以支付歷史發展進程來對它們進行一一闡述。
2.1 第一方支付
第一方支付如下圖所示:
第一方支付即現金支付,從最早出現貨幣的時候,我們就開始並長時間依賴於這種支付方式。“第一方” 特指買賣雙方直接以法定貨幣進行交易,即一手交錢一手交貨,資金不通過任何中間機構。隨着商業的發展,大宗交易不再適合使用現金進行支付,第一方支付不再能滿足需求。
2.2 第二方支付
第二方支付如下圖所示:
第二方支付是依託於銀行的支付方式。買賣雙方通過銀行來進行資金的劃轉,避免了大額現金交易帶來的安全、攜帶、保存、清點、驗證等問題,使得大額交易變得快捷、方便、安全和簡單。由於銀行操作存在一定的成本和使用門檻,因此第二方支付逐漸從日常生活和小額市場的支付中淡化並退出,轉而在一些鉅額的交易和政策性的金融活動中發光發熱。
2.3 第三方支付
第三方支付是指具備一定實力和信譽保障,並獲得國家頒發運營牌照的獨立機構,採用和各大銀行簽約的方式,通過與銀行相關接口對接而促成交易的網絡支付模式。我們熟悉的微信支付和支付寶都屬於第三方支付工具。第三方支付工具隨着移動設備 + 互聯網的大範圍普及而迅速佔領日常生活中的各種交易場景,逐漸取代了大部分的中小額現金交易。
2.4 第四方支付
第四方支付實際上是聚合了多個第三方支付、合作銀行的渠道接口,爲商戶提供一站式的支付解決方案:
第四方支付的優勢在將多家第三方支付聚合在一起,給商戶提供了一站式的支付解決方案,同時便利了商戶和用戶。但第四方支付目前缺乏政策資質,存在較大的資金安全風險。
03 第三方支付概述
本章將對第三方支付進行整體性的描述,包括角色拆分、賬戶體系、原作模式以及領域劃分等。
### 3.1 領域角色
回到我們第三方支付的介紹圖中:
上圖中涉及到了 4 個角色:用戶、商戶、銀行以及第三方支付工具本身。由此可見,第三方支付系統必須至少在內部抽象出 3 種角色來爲用戶、商戶和銀行服務。由於支付主要涉及到的是資金的記錄和流轉,適合以賬戶形式承載,因此延伸至第三方支付系統中的 3 種賬戶。
3.2 三種賬戶
賬戶是支付機構內部爲其服務對象(用戶、商戶、銀行等)創建的物理記錄(類似於表格),這些記錄包含了對象的關鍵信息,如機構爲對象分配的唯一 ID、對象的餘額、交易的流水、賬戶狀態等等。可以說賬戶是支付機構識別服務對象的根本,所有服務對象都必須要有賬戶。
根據第三方支付的服務對象,我們將抽象出三種賬戶:用戶賬戶(User Account)、商戶賬戶(Merchant Account)以及銀行賬戶(Bank Account)。
3.2.1 用戶賬戶(User Account)
一個用戶的賬戶需要記錄什麼信息呢?需要有一個唯一的賬戶 ID 避免記錄混亂,需要爲用戶記錄餘額,需要記錄賬戶的資金變動過程(流水)。如下圖所示:
用戶賬戶的行爲特點是什麼?
-
很少併發:同一時刻通常只會發生一筆交易,因爲支付需要用戶手動去操作。
-
交易頻率較低:一個普通用戶通常一天只會支付數筆。
-
餘額敏感:用戶對自己的賬戶餘額及其變動非常敏感。
這些特點是很直觀的感受,但對我們後文深入的介紹會有很大影響,此處先做了解和鋪墊即可。
3.2.2 商戶賬戶(Merchant Account)
商戶賬戶需要記錄的最基礎信息同用戶一樣,也是 ID、餘額和流水。
商戶賬戶的行爲特點是什麼呢?
-
高併發:同一時刻會有很多用戶向同一個商戶支付,促銷活動時更甚。
-
交易頻率高:一個商戶一天的交易可能會非常大。
-
餘額變動不敏感:由於商戶伴隨着用戶的不斷支付,餘額會快速變化,因此商戶本身對該賬戶餘額不敏感。
3.2.3 銀行賬戶(Bank Account)
Bank 賬戶映射的是各大銀行,其賬戶如下所示:
銀行賬戶的特點是什麼呢?
-
數量有限:銀行賬戶映射的是各大銀行,因此數量有限。
-
金額流水龐大:一個大型支付機構和銀行的資金交易往來通常都是以億爲單位,金額特別龐大。
-
併發量高:擁有同一銀行卡的用戶非常多,這些用戶同時使用銀行卡支付、體現的量級也非常大,其量級比單個商戶會大很多。
-
餘額不敏感:因爲是支付機構內部爲了映射銀行而開具的內部賬戶,銀行並不會關注,所以除了支付機構本身,沒人會關注該賬戶餘額。
3.2.4 對應關係
上述 3 種賬戶和第三方支付角色的對應關係是怎樣的呢?是直接一對一嗎?如下圖所示:
用戶只擁有用戶賬戶就足夠了,而商戶則往往同時擁有商戶賬戶和用戶賬戶,銀行則只對應於銀行賬戶。
爲什麼商戶還額外擁有用戶賬戶呢?這是出於資金管理的需要。商戶賬戶中的資金並非全部歸屬於商戶本身,其中有一部分是第三方支付機構將會收取商戶的佣金。只有在支付機構收完佣金後的淨額才歸屬於商戶本身,才能任其自由使用。
簡而言之,商戶賬戶中的資金商戶無法直接動用,需要在支付機構收取完佣金後結轉到商戶的用戶賬戶中才能自由提取。這其實就是結算過程,後續結算卷會有專門的文章講解,此處僅做簡單瞭解即可。
3.3 切換視角
以一個常見的菜市場買菜的場景爲例,在用戶視角,支付過程如下:
用戶挑選好蔬菜後,打開微信支付,掃描賣家二維碼,輸入金額和密碼完成支付,拿走貨物,用戶角度的支付過程到此結束。但從系統的角度來看,支付僅僅只是整個交易鏈路中的過程之一。在交易的事前事後還需要很多其他過程的協助。
讓我們跳出用戶視角,思考一些深入的問題:
-
我們購買貨物的微信餘額是怎麼來的?如果使用銀行卡支付,那麼錢是如何從銀行卡轉移到微信的?
-
當我們的銀行卡急需資金,選擇從微信提現到銀行卡時,資金是如何轉移的?
-
用戶支付的錢是怎麼給到商家的?微信支付有收取支付手續費嗎?向誰收取的?什麼時候收的?
-
當我們對購買的貨物不滿意,想要退款時,資金是如何退回的?
由此可見,想要真正瞭解支付,我們的關注點就不能只停留在用戶的角度。
3.4 運作模式
支付機構本質上還是資金相關的操作,我們知道第三方支付涉及用戶、銀行和支付機構本身。接下來讓我們嘗試用上文的賬戶體系來分析一下常見的支付過程。
3.4.1 初始狀態
我們將以一個典型例子來說明,涉及對象的初始狀態如下圖所示:
涉及的用戶有兩個,張三和李四,他們分別有自己的微信賬戶和銀行賬戶,微信也在銀行開具了自己的銀行賬戶,稱爲備付金賬戶(專業名詞章節介紹)。他們各自的餘額如上圖所示。
3.4.2 用戶充值
現在假設張三想要通過自己的銀行卡充值 20 元到微信餘額,資金變動如下圖所示:
首先是張三的銀行賬戶向微信備付金賬戶劃扣 20 元,成功後微信則給張三的微信餘額加 20 元,充值完成。
PS:用戶在微信中綁定了銀行卡,因此不需要用戶去銀行轉賬,而是通過微信與銀行間的接口來自動完成該筆資金的劃扣。
3.4.3 用戶提現
假設李四想要將微信中餘額提現 10 元到自己的銀行卡,則資金變動如下:
首先將李四的微信餘額減去 10 元,然後微信支付調用銀行接口,從微信備付金賬戶中轉賬 10 元到李四的銀行卡中,提現過程結束。
PS:這裏減去李四微信餘額時並不是直接減掉,而是先凍結,等銀行側成功轉賬後再實際減去。凍結和解凍的細節和原因將在付款卷中詳細介紹。
3.4.4 用戶轉賬
假設張三要給李四轉賬 20 元,則資金變動如下圖:
此時,張三的餘額先減 20,然後李四的餘額加 20,轉賬完成。
PS:微信轉賬有確認收款的過程,如果我們要用上述賬戶體系來完成這個功能,可以怎麼做呢?這個問題將會在支付卷中探討。
3.4.5 資金變動彙總
從上面的表格我們注意到:備付金賬戶和微信賬戶的變動淨額總是相等的。
-
在充值時,微信體系餘額增加,則備付金賬戶也會增加相同的金額;
-
提現時,微信體系餘額減少,則備付金賬戶的餘額也會減少相同金額。
-
轉賬時,只是支付工具內部賬戶之前的劃轉,不涉及資金流入和流入支付體系,因此備付金賬戶餘額不變。
因此,我們可以認爲 所有支付系統餘額是所有備付金銀行賬戶餘額的映射。 我們稱微信餘額爲系統資金,銀行餘額爲物理資金。如果物理資金小於系統資金,則說明物理資金被挪用,可能會導致用戶無法提現。國家會監管持牌支付機構的備付金使用情況,避免這樣的情況出現。
3.5 支付交互
上一節介紹了用戶賬戶、銀行賬戶之間的一些常見交易類型,本節將介紹涉及商戶賬戶的支付過程,如下圖所示:
用戶和商戶也都擁有自己的銀行賬戶和微信支付賬戶。微信支付作爲中間橋樑,將銀行、用戶、商戶連接起來,共同構成了整個交易網絡。 從交互圖中可以看出,支付系統具有很多重要的功能:
-
充值。用戶將銀行卡中的資金轉移微信支付中,成爲微信餘額的過程。
-
提現。用戶或商戶將微信餘額轉移到銀行卡的過程。
-
支付。這裏特指用戶將資金從自己的現金賬戶劃轉到商戶的交易賬戶過程。
-
退款。支付的逆向過程,將資金從商戶賬戶退回到用戶賬戶。
-
結算。用戶支付給商戶的資金,在收取手續費後,劃轉到商戶的現金賬戶的過程。
上述功能中,有的只涉及用戶,如充值和提現;有的同時涉及用戶和商戶,如支付、退款;而有的只涉及商戶,如結算。
3.6 領域拆分
讓我們對上面的各種交易類型做一個整合,在業務領域上進行拆分和歸納,如下圖說是:
下面對這些領域及其職責進行簡單說明:
-
支付(廣義):負責支付、轉賬、充值等基礎交易能力的提供。
-
退款:負責將用戶支付的資金從商戶賬戶退回用戶賬戶或用戶銀行卡。
-
付款:負責將支付體系內的資金提取到指定的用戶銀行賬戶,即提現。
-
結算:負責按照合同約定的規則,將商戶交易賬戶的資金劃轉到商戶現金賬戶,並收取交易手續費。
各個領域提供基礎能力,並服務各種各樣的業務場景。有的業務場景需要多種領域能力合作完成,如結算業務需要依賴於付款的提現能力。
04 結束語
在上文的介紹中,我們說明了幾個重要的問題:
-
什麼是第三方支付。
-
第三方支付機構的賬戶體系是怎樣的。
-
第三方支付業務背後的資金是怎麼在賬戶間流動的。
-
第三方支付系統包含哪些主要領域。
在本文中,我們從全局的角度簡單說明了一個支付系統的構成和運行過程,並對第三方支付領域做了拆分。後續文章將會對每個領域進行更詳細的探索和理解,包括其主要業務流程的實現思路以及一些有趣的問題探討。
原創作者|周成
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/Z2sNg-VjdmGD5kymZPrrYQ