88 張圖,把支付清結算串起來
支付是一個龐大且繁雜的體系,有非常多的概念、模型和邏輯。通過本文的 88 張圖,66 個知識點,把支付清結算體系串起來,建立一個支付知識速查手冊
1. 支付的本質
支付的本質是付款人向收款人的資金轉移
-
收付款人:可以是個人、企業、銀行
-
資金:即貨幣,可以是現金、銀行存款、支付機構零錢餘額
-
轉移:即債權歸屬發生了變化
-
轉移需要工具:銀行卡、支票、移動支付、網絡支付等
2. 支付和交易
有聯繫,但範疇不同,交易是價值的交換,支付是資金的轉移
-
純交易:價值交換,不涉及貨幣
-
純支付:資金轉賬,不涉及商品和服務
-
基於交易的支付:用貨幣兌換商品和服務的價值交換
3. 支付的過程
支付可以劃分爲 “交易、清算、支付”,三個過程
-
交易:用戶身份的確認,訂單生成以及支付的發起
-
清算:支付指令的接收、清分、軋差
-
結算:基於清分結果,執行的資金劃撥
4. 直聯和間聯
機構間的接入,有直聯和間聯模式
-
直聯:直接對接接口,傳遞支付指令
-
間聯:通過第三方機構轉接支付指令
5. 支付模式
支付經過多年的發展,形成了多樣化的支付模式
第一方支付:即現金支付,面對面,一手交錢,一手交貨
第二方支付: 即通過銀行進行資金的劃轉,避免大量現金攜帶的安全性和便捷性問題
第三方支付: 即通過持有支付牌照的三方支付機構將資金支付給商家的支付模式
第四方支付: 即用戶通過聚合支付平臺將款項支付給收款人的支付模式
6. 清算模式
- 根據收付雙方所開戶的機構是否相同,支付可以分爲機構內清算和跨機構清算
機構內清算: 付款賬戶和收款賬戶在用一個機構內
跨機構清算: 付款賬戶和收款賬戶在不同的機構內
- 根據清算的處理時效和軋差方式可以分爲,實時全額清算和延遲淨額清算,延遲淨額又分雙邊和多邊
實時全額清算:以實際的支付金額進行實時逐筆清算的模式
延遲淨額清算:根據清算對手之間的支付往來進行正方向衝抵以後,將淨額部分進行一次性清算,雙邊淨額是兩兩之間進行,多邊清算是全部參與者之間
7. 三方產業生態
根據提供支付服務環節的不同,可以將支付機構分爲收單側和賬戶側
-
收單側:爲商戶提供快捷、網關、聚合、POS 等收單服務的支付機構
-
賬戶側:爲用戶提供付款需要的 “資金賬戶”,以微信和支付寶爲主
8.PVP/DVP / 往來戶 / 代理
瞭解四種機構間的結算模式,有助理理解跨境支付、央行大小額系統集中清算的原理
1.PVP 結算(Payment Versus Payment)
同時付款;指在外匯交易達成後,在雙方指定結算日,外匯的交割和資金的結算同步進行,並互爲條件的一種結算方式,一手交錢一手交錢
2.DVP 結算(Delivery Versus Payment)
券款對付;指在債券交易達成後,在雙方指定結算日,債券的交割和資金的結算同步進行,並互爲條件的一種結算方式,一手交券一手交錢
3. 往來戶結算
銀行間相互在對方開通賬戶並且存款用於跨行結算,稱爲往來賬戶結算模式
-
銀行間支付過程:B 銀行借記 A 銀行存款賬戶(-1000)
-
銀行內支付過程:A 銀行借記張三賬戶 1000(-1000),B 銀行貸記李四存款賬戶(+1000)
4. 代理結算
在同一家第三方銀行都開立賬戶,用於銀行間結算的模式;例如目前的央行就是各商業銀行、三方支付機構之間資金清算的代理行
-
銀行 1 和銀行 2 之間的結算通過在代理行 A 的存款進行
-
銀行 2 和銀行 3 之間的結算先通過代理行 A 和 B 在代理行 C 完成清算,然後再由銀行 A 與銀行 2 結算、銀行 B 與銀行 3 結算
9. 合作銀行存管模式
沒斷直連之前,支付機構的備付金開在商業銀行,分爲 “存管戶、收付戶、匯繳戶”
-
匯繳戶:功能最弱,只能用戶本行收款和原路退回,不能向客戶付款,且日終不留餘額
-
收付戶:一個合作銀行最多隻能開一個,可以同行收款和付款,日終允許有餘額
-
存管戶:功能最強,在存管行的每個省、直轄市分行都可以開一個存管戶;只有存管戶可以跨行收款和付款
10. 集中存管模式
斷直連以後,備付金集中存管在央行,每個支付機構只有一個備付金集中存管賬戶,該賬戶可以同行 / 跨行收款、付款;通過網聯銀聯實現
-
映射 / 解映射:支付機構將央行備付金圈存給網聯或者銀聯用於日間清算
-
支付請求:支付機構向網聯銀聯發起收款、退款、打款等業務,並實時清算
-
信息轉接:網銀聯將支付請求轉接給對應的商業銀行
-
提交結算:結算場次,網銀聯將支付機構的軋差淨額提交央行進行結算
11. 支付生態全景
國內支付體系依靠龐大的生態網絡共同實現,沒有任何一家企業可以獨立完成支付業務
這麼龐大的支付網絡,離不開衆多支付組織的支撐,每個支付組織都承擔着相應的 “支付職能”
-
交易平臺:爲商家和用戶提供交易場所,提供商品或者服務,撮合買賣雙方
-
支付機構:通過提供各類收付支付解決方案爲交易平臺提供支付服務,例如微信支付、支付寶支付、聚合支付等
-
清算機構:跨機構進行交易轉接和資金清算時,需要依賴清算組織實現
-
銀行:支付需要錢,最原始的錢在銀行的結算賬戶當中;銀行爲社會提供最基礎的金融服務,是支付服務的最主要提供方
-
央行:幾乎所有跨機構的支付業務在人行完成最終清算。人民銀行爲支付業務提供最基礎的支付清算服務、支付基礎設施、清算賬戶
12. 計價 / 計費
計價和計費都是計算,但二者存在差別
-
所處環節不同:計價在交易之前進行,計費在交易之後進行
-
服務對象不同:計價是用戶服務;計費是爲商家服務
-
計算結果不同:計價計算出來用戶應該付多少錢;計費計算出來應該結算給商家多少錢
-
系統不同:計價有計價系統實現;計費由清算系統實現
13. 訂單 / 賬單 / 支付單
不同的單據職責不同,記錄的信息不同,但相互之間有非常密切的關係
-
訂單:登記一次交易所包含的全量信息,誰買了那個商家的什麼商品
-
賬單:以訂單爲依據,其中包含卡券、積分等內部支付方式,以及外部渠道的支付方式
-
支付單:僅處理外部支付渠道的支付,以賬單爲依據
14. 券的處理機制
券在交易中要被處理兩次:提交渠道之前先凍結;渠道成功之後再進行覈銷
15. 交易補貼 / 支付立減
有時候用戶在下單支付有優惠,可能是在下單時優惠,也可能是渠道支付立減優惠
-
交易補貼:下單時使用優惠券,用戶的應付金額 = 訂單金額 - 優惠金額,屬於平臺的補貼
-
支付立減:用戶支付時優惠,用戶的實際支付金額 = 應付金額 - 渠道立減;屬於支付渠道的補貼,但平臺還是會收到用戶的應付金額,渠道會把補貼部分給到平臺,只不過用戶少支付了一些
16. 即時交易 / 擔保交易
-
即時交易:支付成功以後,資金會實時進入收款方賬戶,例如資金轉賬、面對面付款等
-
擔保交易:電商場景居多,用戶支付成功後,資金會先進入中間擔保戶,用戶確認收貨或者超過一定時間後轉入商家收款賬戶
17. 逆向交易策略
正向交易用了卡券、積分等組合支付,在用戶發起部分退款時需要明確這些支付方式的處理順序或者比例
例如支付了 100 元,用了 20 元券;當部分退款 40 時,是直接退 40 元,還是先處理 20 的券,再通過渠道退給用戶 20 元;或者按比例處理
18. 四大履約模式
-
物流配送:像買的實物商品,商家通過配送發貨進行履約,當然,也存在自提的模式
-
上門服務:像家政、打車等的履約,需要服務人員找到用戶進行面對面履約
-
到店享受:像 KTV、寵物美容等,需要用戶到店裏兌換服務
-
權益發放:像視頻會員、超前點映、話費充值等,虛擬權益類的履約,直接在線發放
不同的履約模式,在履約處理上存在差別,如下圖所示
19. 交易核心架構圖
雖然有衆多交易模式,但從交易處理的宏觀視角看,具有一個穩定的處理流程框架和大體順序,掌握這個模型,基本就可以推演各類交易模式,以及各種交易處理
20. 支付業務類型
根據場景和資金轉移的特點,支付可以劃分出非常多樣化的服務,消費、退款、結算打款、代付、代發、打款退回、充值、提現、轉賬、預授權、調撥、分賬等
-
支付:代商戶向用戶收款
-
退款:將收用戶的錢,退回用戶的資金賬戶
-
結算打款:代商戶收的錢,結算給商戶綁定的銀行卡
-
代付:將商戶的款項付款至商戶指定的銀行賬戶中
-
代發:具備明確的付款場景下的代付,例如發工資、發補貼等
-
退票:付款成功的款項,又退回至付款賬戶
-
充值:將銀行卡中的錢轉入支付賬戶中
-
提現:將支付賬戶中的錢轉入銀行賬戶中
-
轉賬:非消費場景的同類賬戶之間的資金直接劃轉,例如支付賬戶之間,結算賬戶之間;不同類型賬戶之間劃轉資金是充值或者提現
-
預授權:根據消費金額預先凍結賬戶資金
-
調撥:統一企業的不同資金賬戶之間資金的劃轉
-
分賬:將收款按比例分成多份劃轉至各方資金賬戶
21. 支付底線
爲了確保資金安全,要遵守底線原則:渠道支付成功才入賬,商戶扣賬成功纔出款
22. 支付(消費)
支付即向用戶收款;用戶用不同的支付方式,平臺需要將支付指令提交給不同類型的渠道
-
零錢支付:即錢包支付,用戶的支付賬戶和平臺的收單賬戶在同一家機構(當然也有可能不再同一家,例如用戶使用微信零錢)
-
銀行卡支付:即快捷支付、網銀支付、認證支付;需要用戶先綁卡,支付時從銀行卡里扣錢到平臺的收單賬戶;因爲涉及到跨行,所以需要清算機構轉接信息,並最終提交央行進行跨行清算
-
餘額支付:用戶在平臺開設一個虛擬賬戶,預先充值餘額,支付時直接扣款給平臺商家;此支付方式無需調用外部支付渠道
23. 退款
退款的原則是原路退回,用戶支付時用什麼樣的支付方式,退款時就走原支付方式的逆向
-
零錢支付退款:資金退回到用戶零錢賬戶
-
銀行卡支付退款:資金原路退回到用戶的付款銀行卡
-
餘額支付退款:資金退回到用戶在平臺的虛擬賬戶中
退款時要校驗原支付單是可退款餘額即退款次數是否超限;另外還需要啊校驗退款的有效期,一般渠道時效爲 1 年,超過一年的支付無法原路退回;可以轉爲付款將資金退給用戶
注意:網聯的退款通道分爲 “協議支付退款、商業委託支付退款、網關支付退款等”,是不同的通道
24. 組合支付
組合支付是指一筆訂單通過 2 種及以上的支付方式進行支付;線上支付通常內外組合:內部支付方式(券、餘額)+ 外部支付渠道
25. 合單支付
多個子單一次性進行支付的模式,常見的是以下兩種場景
-
場景 1:在航旅、酒店等支付場景中,一次支付行爲可以同時進行票證、保險的付款,且多筆付款分別對應多個不同的商戶
-
場景 2:電商平臺上,用戶挑選不同商家的商品,加入購物車,可進行合單支付,只需要用戶做一次支付
在合單支付的解決方案選擇上,有兩種模式
模式 1:直接接入 “合單支付” 產品,實現合單支付,例如微信的“合單支付”
模式 2:接入一款延遲分賬的產品,用戶資金先進入過渡戶,平臺根據子訂單金額髮起分賬,將資金結算給商戶
26. 分次支付
支付金額比較大,超過了所有可用渠道的支付單筆限額,分多次進行支付;只有在整個訂單總金額全部被支付以後,纔算訂單支付成功
要區分分次支付和分期支付之間的不同
27. 充值 / 提現 / 轉賬
這幾種支付行爲都會產生資金的流動,但是本質上存在差別
-
充值:是資金從高信用賬戶流向低信用賬戶,例如從銀行卡賬戶流向支付賬戶;亦或是從貨幣賬戶流向專項用途的非貨幣賬戶,例如從支付賬戶給手機充值;
-
提現:是資金從低信用資金賬戶流向高信用資金賬戶;主要是從支付賬戶提現到銀行賬戶
-
轉賬:是同等級別信用賬戶之間的資金劃轉,例如銀行卡賬戶轉到銀行卡賬戶,支付賬戶轉到支付賬戶
注意:資金範疇的充值 / 提現需要同名,例如銀行賬戶和支付賬戶之間的充值和提現需要絕對同名,也就是你的零錢賬戶只能綁定自己的銀行卡往裏面充錢;而向手機話費賬戶充值,不受同名限制
28. 充值
充值本質上走的是 “收單通道”,收款成功後增加用戶在平臺的賬戶餘額
除了向支付賬戶充值以外,還有其他的充值類型,常見的有以下 4 種
-
電子錢包充值:從銀行卡充錢到微信零錢,或者到平臺虛擬餘額
-
遊戲充值:通過銀行卡賬戶或者支付賬戶向遊戲平臺的會員賬戶充值,本質是虛擬商品的購買,一般無法提現
-
電話卡充值:給手機卡充話費,可以用銀行賬戶充,也可以用支付賬戶充,資金進入運營商的話費賬戶,一般無法提現
-
預付卡充值:向公交卡、美髮卡等充值,一般無法提現
29. 提現
提現本質上走的是 “付款通道”;扣除用戶賬戶餘額後,向綁定的銀行賬戶所屬行發起付款請求,付款成功後,收款行增加用戶賬戶餘額;一般需要提現到同名賬戶
-
用戶提現:用戶將零錢賬戶餘額提現到綁定的個人銀行卡中
-
商戶提現:商戶將收款賬戶中的餘額提現到綁定的企業結算銀行卡中
30. 轉賬
轉賬是銀行賬戶之間,支付賬戶之間的資金劃轉,可以是同名賬戶,也可以是非同名賬戶
31. 代付 / 代發 / 代收 / 代扣
這四個詞很相似,但有所區別,代付和代發是一組,因爲都是資金流出,屬於付款業務;代收跟代扣是一組都是資金流入,屬於收款業務
從業務渠道種類看:分爲櫃面代收代付、瀏覽器(網絡支付)代收代付、專線直聯代收代付、互聯網直聯代收代付等
-
代收:即代理收款,當然,收款的方式有很多種,例如快捷、網關、代扣等,都可以幫助客戶收款;代收都是收款方發起,即便有的場景看起來是客戶發起,但實際上是客戶在收款方渠道的操作,觸發了收款方的代收行爲
-
代扣:是由收款方發起的主動向付款方收款的業務,需要跟付款方預先簽約代扣協議,常用場景是分期還款、會員自動續費等;本質是收款方發起借記支付,付款方將借記支付轉爲貸記支付進行主動付款的支付業務
-
代付:代客戶付款至指定銀行賬戶,這裏的付款可以是單純的付出一筆資金;主要用於商戶提現、用戶提現、結算付款等;還有另一個含義就是在買東西時找朋友代付款,即找人代付,是用戶之間進行的
-
代發:具有明確場景的代付,就是你付的是什麼錢,更合理、透明、合規,例如工資、補貼等等;一般需要用企業對公基本結算戶實現;另外,代發是一種老叫法,現在除了代發工資,已都叫代付了。也就是說,“代發工資”是一個業務場景,使用的 “代付” 業務產品
32. 退票
通過銀行支付款項時,銀行實時扣減付款賬戶餘額,但最終沒有成功入賬到收款人的賬戶,而將付款金額全額退回至付款賬戶的業務,即退票
把付款業務看成由 2 個過程組成:一個過程是 “錢付出去了”,另一個過程是 “對方收到錢了”
只有這 2 個過程都成功了,纔是真正的付款成功;但是,第二個過程可能會失敗,那就會發生退票
33. 歸集 / 調撥 / 資金池
-
資金歸集:是指將分散在不同賬戶、部門或地區的資金集中到一箇中心賬戶或資金池中的過程
-
資金調撥:更側重於資金的轉移和重新分配過程;資金歸集通過調撥實現
-
資金池:則是這些集中起來的資金所形成的一個統一的資金儲存和管理空間。因此,資金歸集是形成資金池的一種方式或手段
34:主掃 / 被掃 / 刷卡 / 碰一碰
這類支付方式的核心是 “新型支付工具的研發”
這是四種線下面對面支付的方式,本質上是對支付工具的識別,進而進行支付工具所綁定的支付賬戶的賬務處理,以完成最終的支付
35. 刷掌 / 刷臉 / 聲波 / 虹膜
這類支付方式的核心技術是 “用戶身份識別能力”
這是四種線下面對面支付的方式,本質上是對用戶身份的識別,基於該用戶身份下所開通的該支付方式所綁定的賬戶進而進行賬戶的賬務處理,以完成最終的支付;
36. 信息流和資金流
信息流是支付指令的傳輸路徑,資金流是資金在賬戶之間的流動的路徑
資金的流動依賴信息的流動去推動,以信息流爲依據;同樣資金流動也是信息流動的必然結果,發生信息流動的目的就是推動資金的轉移以完成最終的支付
可以通過以下步驟結合上圖,進行信息流和資金流的分析
-
對象分析:分析出都有哪些參與對象
-
賬戶分析:涉及到哪些資金賬戶,這些資金賬戶都屬於誰
-
信息流分析:交易流程是什麼樣的,參與者之間是如何進行信息交互的,就得到了我們要的信息流了
-
資金流分析:將支付過程,結算過程中涉及到的賬戶標記出來,資金是從哪些賬戶流出,流入哪些賬戶的,就得到了我們的資金流了
37. 退款的全局實現
不同平臺接入的通道不同,退款政策也不同,就需要去分析接入的各類通道的退款能力,已實現自己的退款業務
-
商戶做退款:通過微信支付、支付寶支付、快捷支付的退款能力實現
-
三方做退款:通過網聯或者銀聯執行的支付在退款時可以通過請求網聯銀聯提供的退款通道執行退款
-
清算機構做退款:內部先做淨額軋差,淨額通過人行最終實現退款資金的清算
38. 前置路由
用戶在提交訂單以後,需要後端提供收銀臺封裝結果,哪些支付方式可用,如何排序,是否有推薦的支付方式等
首先是交易層要傳入支付特徵給到收銀臺服務端或者支付系統;後端根據交易特徵和歷史支付畫像,封裝出收銀臺給到前端
39. 支付處理流程
對於支付處理的流程的把握,主要關注 3 層模型
-
支付全局流程:站在全局的視角看支付流程,瞭解清楚從用戶挑選商品開始,到最後支付完成,不同系統層之間是如何協調完成的
-
支付核心主流程:支付核心系統不變流程,例如請求校驗、冪等性、交易信息補全、路由處理、渠道信息補全、支付應答等
-
支付方式的差異化流程:是在主流程的框架上,每一個支付方式的差異,例如交易信息補全環節,每個支付方式補全的參數不同
40. 渠道路由
渠道路由及根據交易特徵,選擇出最有的支付通道出來;通過分組規則以及多條篩選規則得到最終要走的支付通道
41. 支付渠道
可以將渠道分幾大類:收款渠道、付款渠道、退款渠道、鑑權渠道、實名渠道
1. 快捷通道
根據方案提供機構的不同,快捷支付可以分爲三種模式:三方模式、銀聯模式、銀行模式
三方快捷: 即由三方支付機構提供給商戶的快捷支付產品,該模式也是市面上的主流模式,以易寶支付快捷支付爲例
圖片來易寶支付開放平臺
銀聯快捷: 銀聯在線支付是銀聯推出的網上支付平臺,包括認證支付、無跳轉支付、網銀支付等多種支付方式,其中無跳轉支付即快捷支付
圖片來銀聯開放平臺
銀行快捷: 有的銀行也直接向商戶提供快捷支付產品,以例如工商銀行的 “H5 移動在線支付”
圖片來工商銀行開放平臺
2. 網銀通道
網上銀行支付,是指消費者在網上銀行頁面輸入其賬戶信息,通過銀行提供的驗證方式(如 U 盾,支付密碼等)完成付款的支付方式,主要適用於 PC 端及移動端,以匯付天下的網銀支付流程爲例
圖片來自匯付天下開放平臺
3. 代扣通道
是由收款方發起的主動向付款方收款的業務,需要跟付款方預先簽約代扣協議,常用場景是分期還款、會員自動續費等
本質是收款方發起借記支付,付款方將借記支付轉爲貸記支付進行主動付款的支付業務
4. 微信支付通道
做過零售端主流的支付方式,面向個人用戶的收款非常重要的一個支付通道,其包含多種支付產品:APP 支付、公衆號支付、合單支付等
圖片來自微信支付開放平臺
對通道的理解和接入並不難,因爲通道方都會提供接入文檔和相應的商務和產研人員輔導
42. 支付記賬
支付成功後的記賬主要涉及到支付、交易、營銷三層業務的登記;不同業務登記不同的會計分錄
從全局視角看支付的記賬,可以省略掉中間過渡戶,會計分錄如下
借 銀行存款 80
銷售費用 20 (20 元的券)
貸 商戶待結算 100
43. 支付核心全景圖
一筆支付是有衆多組織以及很多系統共同完成的,把這些組織和系統放到一起,通過支付流程串起來,可以看清楚一筆支付的全貌
-
商戶平臺交易處理:處理用戶的訂單,先請求支付平臺預下單,然後根據支付機構返回的支付標識、方法或者 URL 調用渠道的收銀臺
-
支付機構支付處理:處理商戶的支付請求,並請求清算機構進行支付處理,內部需要登記賬務流水、清算處理、結算處理、以及與商戶對賬
-
清算機構轉接處理:實時清算,定時結算,向付款行轉發支付請求
-
銀行對客戶的處理:銀行根據清算機構轉接過來的支付申請,操作用戶的賬戶
44. 渠道清結算
以最複雜的場景爲例,看一下清結算的原理;用戶在交易平臺購買了一個商家的商品,支付成功以後全鏈的清結算如下圖所示,一層套一層
用戶之間資金流
-
用戶支付:用戶付款成功,渠道登記平臺待結算;
-
渠道結算:從待結算結算到平臺的收單賬戶;
-
結算通知:支付渠道通知交易平臺錢已經結算到了收單賬戶
-
收單提現:平臺將資金提現到對公戶;
-
商家結算:平臺從擔保戶結算到商家的虛擬賬戶;
-
商家提現:商家提現到自己的對公戶
平臺間的清結算流
-
清算機構清算:主要是清算機構向付款行和支付渠道下發清算文件和結算文件;
-
支付渠道清算:支付渠道向交易平臺下發交易賬單和資金賬戶;
-
商家結算:交易平臺提供給商家對賬單
機構間的資金流
在央行銀行清算賬戶和備付金賬戶之間完成
45. 對象關係
在算賬過程中不同的交易會涉及到不同的對象關係,有沒有代理商、有沒有分賬方等
對象關係不同涉及到的算賬目標和任務不一樣,在商戶入網時構建該商戶的關係模型,在實際算賬過程中調用該模型關係,計算對應目標
-
單商戶:就是簡單的收單商戶,自己找上門簽了一個收款產品
-
商戶 - 分賬方:最典型的就是電商類交易平臺,如滴滴、美團等,平臺需要給店家、騎手分賬
-
代理商 - 商戶:商戶通過代理商接入平臺,形成了代理關係
-
代理商 - 代理商 - 商戶 - 分賬方:這是更復雜的關係,涉及二級代理商
46. 分賬 / 分潤本質
-
分賬:是商戶將交易金額按照設定比例進行多方劃分的過程
-
分潤:是渠道方將各參與方費率差部分劃分給各方的過程,例如給代理商劃分 “商戶手續費 - 自己手續費” 的那一部分手續費差
47. 算賬模型
交易成功後先登記賬務流水,然後由賬務系統推送至清算中心進行計費和清分,計費結果再返回賬務系統進行流水登記
計費過程中通過交易所屬商戶的商編獲取到其對象關係模型,以及每個對象的手續費配置和分賬分潤比例
48. 商戶手續費 / 通道成本
支付業務中會向商戶手續交易手續費,並向通道支付通道成本,其差值即是支付機構最基本的商業模式
49. 計費模式
常見的商戶計費模式有內扣、外扣、預付實扣;常見的通道成本計費模式有固定金額、固定比例、筆數階梯計費模式、利息模式、銀聯階梯模式等
50. 清分
結算前按照結算對象計算應收應付金額的過程
51. 商戶清結算
支付機構將備付金中的預收代付資金,按照與商戶簽訂的結算協議結算給商戶的過程
結算方向:可以結算到支付賬戶,或者結算到銀行卡
結算模式:即按照什麼樣的方式將資金結算給商戶
-
T1 結算:下一個工作日結算
-
D1 結算:下一個自然日結算
-
D0 結算:當天結算
-
H0 結算:整點結算
-
S0 結算:逐筆結算
-
TD 結算:跨日結算,針對於酒吧、KTV 等 0 點前後交易集中的商戶結算模式,例如按照上一日的 12:00 到下一日的 12:00 爲結算週期
52. 結算處理流程
D1 是自然日 + 1 結算,與 T1 結算產品類似,多了一個墊資的場景,需要判斷是否是工作日,週末要考慮墊資,因爲上游渠道還沒有結算
53. 結算產品架構
-
結算服務:向上遊提供各類業務的結算數據接收、查詢、對賬單下載等服務
-
結算任務管理:各類結算產品的結算任務時間和結算的觸發
-
業務數據:待結算的業務數據
-
結算信息管理:商家簽約、結算日期、結算卡等基礎信息的維護
-
結算處理引擎:各類結算產品的核心處理核心
-
商戶對賬:結算賬單的模版及生成記錄、查詢和下載
-
打款處理:請求出款
54. 商戶結算記賬
將平臺代商戶向用戶的收款,結算至商戶的支付賬戶或者銀行卡的過程,該過程主要是從商戶結算戶出金、通過過渡戶扣減平臺銀行存款(備付金)的過程
從全局視角看商戶結算的記賬,可以省略掉中間過渡戶,會計分錄如下
借 商戶結算戶 100
貸 銀行存款 100
55. 錢包
錢包是利用互聯網技術手段實現數字貨幣線上管理的虛擬錢包,像微信錢包,支付寶錢包,以及剛剛推出的數字人民幣錢包——“存錢、借錢、花錢、結錢”
-
銀行用戶錢包:由銀行基於銀行結算賬戶體系構建的錢包應用,比如各個銀行 APP 裏的錢包
-
支付機構用戶錢包:由支付機構基於支付賬戶體系提供錢包解決方案構建的錢包應用或者 API 經過商戶封裝後的錢包應用
-
數字人民幣錢包:人行推出的數字人民幣錢包
-
平臺自建錢包:各個平臺自己基於自建賬戶搭建的虛擬錢包應用
-
綜合錢包:是以上幾類賬戶共同構成賬戶基礎的綜合性錢包
56. 三戶模型
設計賬戶的經典模型,可以清晰的構建出各信息層的邊界和關係
-
三戶:客戶、用戶、賬戶,客戶是一個自然存在的個人或者企業;用戶是客戶在平臺註冊形成的一個用戶賬號,資金賬戶是用戶開通的用於支付交易或者結算使用的賬戶
-
關係:一個客戶可以註冊爲多個用戶,每個用戶可以開通多個賬戶,例如你在美團可以註冊爲美團用戶、摩拜單車用戶、美團打車用戶
-
擁有和授權:例如在微信擁有零錢賬戶、理財賬戶;同樣微信可以爲家屬開通親屬卡,將賬戶授權給親屬用戶使用
57. 賬戶分類
從不同的角度,賬戶有不用的分類方法
-
按科目屬性:資產類賬戶、負債類賬戶、損益類賬戶、共同類賬戶等
-
按科目級別:總分類賬賬戶、明細分類賬賬戶
-
按對象類型:個人賬戶、企業賬戶
-
按用途:結算戶、待結算戶、清算往來戶、已清算賬戶、存款戶
-
按賬戶種類:虛擬賬戶、支付賬戶、結算賬戶、清算賬戶、備付金賬戶
58. 複試記賬法
每一項經濟活動發生後,都會登記在至少 2 個賬戶的記賬方法;常用的是 “借貸複式記賬法”
牢記記賬規則:有借必有貸,借貸必相等
能夠分析出賬戶屬性:資產類賬戶、負債類賬戶、損益類賬戶、共同類賬戶等
記住 3 個會計恆等式
-
會計恆等式 1:資產 = 負債 + 所有者權益
-
恆等式 2:利潤 = 收入 - 費用
-
恆等式 3:資產 + 費用 = 負債 + 所有者權益 + 收入
主要是 1 和 3,2+1 推出 3,等式左邊增加在借方,減少在貸方;等式右邊增加在貸方,減少在借方
例如:用 1000 元買了一臺電腦
先分析涉及到的賬戶屬性,錢減少了 1000 元,涉及到銀行存款減少了,獲得一臺電腦即庫存商品增加了;二者都屬於資產類科目,增加在借方,減少在貸方;所以會計分錄爲
借 庫存商品 1000
貸 銀行存款 1000
59. 會計事件
支付發生後需要記賬,記賬就需要一個時機,這個時機就是會計事件,例如訂單創建成功、支付提交渠道、支付返回成功、優惠券完成核銷等等
60. 記賬模式
根據業務發生後如何進行記賬,可以將記賬方式分爲實時記賬、緩衝記賬等
61. 熱點賬戶及解決
熱點賬戶是指在短時間內產生了大量記賬請求,造成賬戶餘額的高併發更新,而出現入賬延遲、失敗、準確性等問題,這裏涉及到的賬戶稱爲熱點賬戶
可以通過以下 7 種方案解決熱點賬戶問題
-
限流,控制併發:限制入賬請求的併發數,缺點是會造成大面積記賬延遲
-
變多爲少,明細彙總記賬:將明細彙總成總金額去更新賬戶,適合對賬戶餘額時效性要求不高的賬戶
-
排隊辦理,緩衝記賬:建立緩衝區,超過併發的請求,進行排隊
-
臨時存放,緩存記賬:高併發請求先記入緩存,然後定時將緩存記賬更新到數據庫
-
增加點位,子賬戶拆分:將賬戶拆分成子賬戶,分別進行更新
-
小弟線上,前置緩衝:可參考網聯前置系統,爲解決央行備付金賬戶熱點問題
-
技術性能升級:提高系統性能,從根本上解決技術瓶頸
62. 記賬日與日切
記賬日及會計總賬日,指業務發生後登記賬務的時間,一般由日切子系統統一維護記賬日
日切簡單的說就是記賬日期的切換,變更系統的記賬時間;這個切換時間點就是 “日切點”
-
統一調度:日切任務,有日切系統統一調度,協調進行
-
日切點與日切維護:日切子系統維護日切時間,以及記賬日期
-
系統時段切割與運行狀態管控:將日切過程劃分成日切準備、日切中、日切結束、日終處理等階段
63. 三大對賬模式
對賬即 “賬證實” 的核對,確保賬務登記的準確性
根據覈對的目的和數據的不同,可以將對賬分爲 3 種模式
-
交易對賬模型:覈對平臺支付記錄與渠道清算記錄的一致性
-
資金對賬模型:覈對渠道的應收應付和實收實付時候一致
-
餘額調節覈對:將系統記賬餘額和實際資金賬戶餘額經過在途調整後進行一致性覈對的業務
64. 對賬差錯處理
對賬差錯是在覈對過程中發現的與實際不相符的錯誤點
不同對賬模式會對出不同的差錯類型
-
賬務差錯: 賬務數據和支付數據不一致,給商戶多入或者少入了;可以通過商戶補入賬消除差錯
-
交易差錯: 平臺支付數據與渠道清算數據不一致,存在平臺單邊或者渠道單邊;可以通過平臺補單或者渠道撤單消除差錯
-
資金差錯: 應收應付和實收實付不一致,出現長短款了;可以向銀行追款或者確認損失消除差錯
65. 二清本質
“二清” 即二次清結算,分信息二清和資金二清,重點要解決資金二清
指的是有清結算資質的機構將資金結算給入網的平臺後,該平臺再將資金清結算給其子商戶,若該平臺沒有清結算資質的話,就屬於二清了
如果平臺的經營出現問題,資金又沒有受到第監管,這些 “裸奔” 的資金容易被平臺捲走,對於商家和客戶而言,都不安全
66. 二清解決原理
原理:非自有資金不過自己的賬戶,通過收單機構直接清分給自己的商戶
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/8CdJFFJ4UalbZya-DjvN8g