賬戶是根據會計科目設置的，具有一定格式和結構，用于反映會計要素的增減變動情況及其結果的載體。本文作者將用五個案例，圍繞支付清算賬戶展開分析，希望對你有幫助。

賬戶體系是支付交易的基礎，就像電池對于手機，油罐對于加油站，心臟對于人體？那么這么核心的系統是不是很難設計呢？其實恰恰不難。這也印證了那樣一句話“大道至簡”。

賬戶是根據會計科目設置的，具有一定格式和結構，用于反映會計要素的增減變動情況及其結果的載體。賬戶的基本結構應同時具備以下內容：

• 賬戶的名稱，即會計科目；
• 日期和摘要，即記載經濟業務的日期和概括說明經濟業務的內容；
• 增加方和減少方的金額及余額；
• 憑證號數，即說明記載賬戶記錄的依據。

如果財務知識不是很充足，可能對以上的賬戶定義很難理解；如果從業務視角來看賬戶，可以理解為賬戶是用于記錄某個主體、某類型資金的余額、以及余額變動明細的數據載體，進而賬戶有3個關鍵的內容：

• 賬戶余額：這個賬戶有多少錢
• 賬戶流水：這個賬戶資金進進出出的明細記錄
• 賬戶交易：怎么把錢放進去，怎么把錢取出來

抓住了上面3個點，基本就抓住了賬戶設計的核心了。

基于這3個點去構建賬戶的輔助設施，比如賬戶主體，賬戶種類，賬戶余額結構，賬戶流水的記錄字段，賬戶的功能權限，賬戶的出入賬，賬戶服務（賬戶開通注銷，凍結解凍，余額流水查詢等）等。

賬戶的種類：

跟科目分類相同，賬戶可以分資產類賬戶，負債類賬戶，損益類賬戶，共同類賬戶等。

如果從業務的視角來看，可以基于業務場景來對賬戶進行分類和命名，比如商戶的結算款會結算到商戶結算賬戶，支付公司在銀行開的賬戶叫備付金賬戶，備付金賬戶又分存管戶，收付戶，匯繳戶；按主體類型可以分個人賬戶/企業賬戶；按賬戶功能定位又可以分為會員子賬戶、商戶子賬戶、中間擔保戶。

從賬戶命名上基本就知道了這個賬戶是干嘛用的；就像你有10張卡，一張是放工資的你叫他工資卡，一張是公積金的你叫公積金卡等等，基于業務命名，目的是為了區分賬戶用途。

但是，無論賬戶叫什么名字，都是有賬戶余額，賬戶流水，賬戶交易；無論卡叫什么名字都是銀行卡；所以賬戶的本質屬性沒有改變，設計辦法也基本相通。唯一不同的是附屬內容存在區別，例如支出戶只能打款不能收款，中間擔保戶不能為負等等，賬戶權限可能不同，主體不同，交易特點不同…..

賬戶的結構：

賬戶系統的基本功能腦圖如圖所示：

賬戶主體：這個賬戶是誰的，個人的？企業的？還是內部業務線的？

賬戶結構樹：就像會計科目，就像商品類目，由于賬戶可能種類繁多所以有時也需要一個結構樹。

• 賬戶類型：賬戶的分類，比如個人賬戶/對公賬戶，結算賬戶/付款賬戶，收款賬戶/打款賬戶
• 賬戶名稱：便于核算
• 賬戶余額：賬戶余額一般為了業務需要，會設計多個金額屬性，比如凍結金額，可用金額，可提金額
• 賬戶流水：賬戶的資金變動記錄，記錄對手賬戶，收支方向，金額，費用類型等基本信息
• 賬戶服務：開通/關閉、權限設置、入賬、扣賬、調賬、凍結/解凍、余額查詢、流水查詢等
• 賬戶底線原則：支付成功才入賬，扣賬成功才出款

如何設計賬戶類型：

就像有的公司叫產品經理，有的公司就產品策劃，有的公司叫需求分析師；但本質做的都是產品設計工作。如可以按照如下分類為賬戶命名：

• 基于主體類型命名賬戶：個人賬戶，企業賬戶
• 基于業務類型命名賬戶：電商商家結算戶，快遞商家結算戶
• 基于資金屬性命名賬戶：工資賬戶，公積金賬戶，手續費賬戶
• 基于賬戶職能命名賬戶：待清算賬戶，中間擔保賬戶

01 在線租車-賬戶系統解析

會開車但還沒買車的小伙伴們，周末出游、節假日出行，或者出差辦事，大家是不是首選租個車？好處當然就是不用加入擁擠的人潮，可以做那個最自由、隨性，條條街最靚的仔！

伴隨用戶租車需求的日益增長，提供租賃服務的中小企業也越來越多，而租車SaaS平臺就應運而生，主要是撮合汽車租賃企業（商戶/出租人）和租車人（用戶/承租人），提供在線租車交易閉環服務

比如通過與第三方認證機構與持牌金融機構合作，為租車業務提供風險管理和交易見證及資金擔保服務，解決交易信任問題，保障交易雙方的權益。

下圖就是租車SaaS平臺的業務模式概覽：

在租車服務過程中，存在商戶與用戶之間的支付退款業務（主要是下單支付租金、續租支付續租租金、線下提車支付押金等場景），商戶與平臺之間的分潤結算業務（看業務模式，主要是平臺服務費或交易傭金），以及平臺與第三方支付機構之間的手續費結算業務，圍繞不同角色的不同結算業務就需要建設賬戶體系。

下圖是某個租車SaaS平臺與第三方支付機構合作設計的賬戶體系建設需求雛形，滿足特定業務場景的交易需求，目的是實現資金監管與清分。

下圖是賬戶間基于主要交易場景的資金流拆解：

賬戶系統，核心是管賬。首先要向上游客戶中心提供入網開戶和賬戶信息查詢服務，包括銀行卡綁卡鑒權、賬戶余額和流水查詢等；當接收來自上游訂單系統/清結算系統的記賬請求時，要根據規則做好入賬處理；當商戶發起賬戶提現請求后，還要通知下游結算系統完成審核出款。

平臺基于第三方支付賬戶的底層能力，包裝出一個面向商戶的錢包應用，本質還是賬戶。底層是基礎能力，中間層是基于基礎能力封裝出來的服務單元，比如針對平臺商戶和用戶的企業工商認證、個人實名認證服務，最上層是錢包應用，商戶開通錢包后，可查看余額、賬單流水、進行提現等操作。

將業務的記賬請求通過配置好的入賬規則、凍結規則進行處理，進入到賬戶系統并且生成賬戶流水，然后更新錢包賬戶余額。

一個錢包賬戶多個余額：

凍結余額：應收應付入賬（信息流）；租金&續租租金支付款項進入擔保戶時，入賬記為商戶收入，進行凍結處理；

可用余額：實收實付入賬（資金流），映射第三方支付機構的支付賬戶可用總余額；租金&續租租金分賬給商戶后，入賬記為內部劃轉款項，進行解凍處理，由凍結金額轉為可用金額；平臺臺服務費、支付手續費扣款后，入賬記為支出。

錢包總余額：錢包總余額=凍結余額+可用余額，用于前臺包裝展示錢包賬戶余額。

通過任務流更新錢包余額：

設定賬務處理任務流，每筆入賬都需要從頭執行到尾，不能遺漏，任何一個環節處理失敗了這筆入賬就進入入賬的失敗處理（將該筆流水的原扣賬金額返還錢包），直到入賬成功結束。

通過費用類型設計資金流：

入賬和凍結處理規則主要依賴預先設定好的“費用類型”，費用類型是基于特定業務場景下的業務類型定義的，規則中設置好參數、入賬方向、流入流出賬戶等內容。

可查看平臺錢包用戶的全部賬戶，包括賬戶的基本信息，所屬主體，賬戶類型，賬戶余額等內容，還可聯查賬戶流水明細。

以錢包用戶（商戶）視角，記錄租車業務下各錢包賬戶的資金變動明細記錄，記錄對手賬戶、收支方向、金額、費用類型等基本信息。

02 線下游樂-賬戶系統

先簡單介紹下「線下游樂行業」的角色結構，一般來說有設備廠商、內容制作商、品牌方、加盟商等眾多角色，通過下圖可以大致的了解下它們的關系。當然很多企業也會同時擁有多種身份，比如品牌方自己就是設備廠商和內容制作商。

在上圖的角色結構下，品牌方有兩種基本的業務模型。

一是自己將設備和內容包裝好進行招商加盟。

二是自己充當一個獨立的平臺方，鏈接設備廠商、內容制作商以及加盟商。從商業的角度來說后者比前者有更大的成長空間但是投入的研發成本和獲取行業資源的難度后者遠高于前者。

所以一般的品牌方是先采用第一種業務模型將自身做大，然后想辦法成長為第二種業務模式。

這里我們主要討論的是第一種業務模型下，品牌方為了滿足運營需求而搭建的自研管理系統。該系統需要為加盟商提供收銀的能力，為品牌方提供分成結算的能力以及為雙方提供數據報表的能力（這里只列舉幾個關鍵的能力）。

假設品牌方的分成方式為按時計費或按次計費，那么品牌方的分成和訂單支付金額將沒有關系。在這樣的前提條件下，品牌方設計這套系統時同樣有兩種模式

一是收銀臺只是提供給加盟商的收銀工具，幫助加盟商完成正常的營業工作，品牌方分成通過人工結算收款或從加盟商預付款賬戶扣除，我稱這種模式為預付款模式

二是品牌方統一收款，再通過銀聯等第三方機構分賬，我稱這種模式為分賬模式（需要注意這種模式下品牌方的分成和訂單金額無關）。

上述兩種系統模式，預付款模式簡單而成長空間小，分賬模式困難但成長空間大。預付款模式只需要為加盟商創建一個預付款賬戶即可，分賬模式則需要創建品牌方賬戶和加盟商的分賬賬戶。為了政策合規，分賬模式一般是在第三方機構建立品牌方賬戶和加盟商分賬賬戶，自己的系統內的雙方賬戶只記錄數據，并不會產生實際的交易行為。

于是同樣的情況再次上演，品牌方一開始先采用預付款模式先將業務跑起來，當業務規模做起來后再引入分賬模式。這就不可避免的在引入分賬模式后的一段時間內存在雙模式并行階段，本文就將針對這種情況下的加盟商賬戶業務進行分析。

賬戶產品架構圖

如下圖所示，加盟商賬戶中心主要承擔的職責是接收上游系統的記賬請求，并根據入賬規則確定應該計入預付款賬戶還是分賬賬戶。此外賬戶信息的查詢服務，賬戶余額及流水的查詢等基礎服務是不可或缺的。賬戶業務流程圖：

整個賬戶產品的架構如下圖所示：針對預付款賬戶具有余額管理的功能；針對兩個賬戶都有賬戶管理、交易流水、交易管理的功能，但針對預付款賬戶提供的是充值和余額支付的能力，針對分賬賬戶提供的是結算入賬的能力。賬戶系統產品架構圖：

針對單獨的分賬模式，因為主要的交易過程發生在第三方機構，本系統內只記錄分賬賬戶的交易信息，所以無特殊的入賬規則，按上游系統傳達的信息正常錄入即可。

針對單獨的預付款模式，雖然交易的過程發生在系統內部，但是因為預付款的業務比較簡單，沒有凍結等操作需求，所以只需要區分好本次記賬是充值還是支付即可（不考慮一個加盟商接入多種分成模式的情況）。

針對同時擁有預付款賬戶和分賬賬戶的，記賬是基于配置好的入賬規則進行。這里需要先具體說明一下加盟商是如何產生兩個賬戶的：品牌方之前采用預付款模式給加盟商開設預付款賬戶，現準備對部分加盟商采用分帳模式，于是給加盟商開設了分賬賬戶，所以加盟商暫時擁有了兩個賬戶。

在這種情況之下，入賬規則的配置就極具個性化了，分成費用可以是優先入賬預付款賬戶、也可以優先入賬分賬賬戶，甚至是按比例都可以。

規則配置頁

需要注意的是只有多個賬戶的加盟商才需要進行入賬規則的配置

賬戶管理頁

賬戶管理頁內會顯示所有加盟商的賬戶，如果一個加盟商擁有兩個賬戶則會都顯示出來，對賬戶的管理只有簡單的開啟和關閉操作，就不做演示了。這里需要注意的是分賬賬戶因為并沒有實際的資金入帳，所以沒有余額。

賬戶流水頁

賬戶流水管理可以查看賬戶的全部變動明細

預付款賬戶因為有實際的金額入賬所以會有余額這一項。而分帳賬戶只用于記錄賬戶流水，資金流轉并不在自己的系統內產生，所以不記錄余額只記錄金額。同時因為這種特性，分賬賬戶的流水中只會顯示每次分賬的最終收入。于是在每一條的流水下會顯示子流水明細，顯示營收和實際收入之間的關系。

03 旅游門店-賬戶系統

旅游門店系統是供加盟門店的經營者使用的系統，滿足門店日常經營需要的功能及總部對門店的管理功能。如門店資金充值、產品預訂、訂后服務（包括合同、發票、扣稅、保險等）、門店懲罰等。

客人在門店支付訂單時，門店需要在系統上下單并給總部支付賣價，客人返程后，總部又需要與門店進行分潤。門店有了利潤之后，又可能會產生相應的利潤支出，如支付門店員工工資、支付手續費等。

所以，在門店系統場景下的賬戶系統主要用于門店各交易場景下的結算業務，客人對門店的結算、門店對總部的結算、門店對員工的結算等。

賬戶業務流程和產品架構

線下整個的資金流程是，客人在門店將賣價（門店與客人溝通的價格）付款給了門店（實際資金流入了管理門店的總部）->系統自動將資金上賬至該門店的賬戶->門店在系統操作下單->客人游玩返程后，將所得利潤（賣價-底價）上賬至門店利潤賬戶->門店提取利潤賬戶至個人銀行。若門店不提取所得利潤，這些獲得的利潤也可以用于門店員工工資的發放、發票、稅費、保險費的支出等。

同時，總部又可以在后臺系統控制門店的信用分賬戶，若該賬戶金額低于閾值，會對門店進行懲罰，如無法下單等。

賬戶系統架構在最底層是系統的基礎能力，即展現給用戶的功能。包括賬戶管理、交易流水管理等，中間層是需要滿足基礎能力封裝出來的服務層架構，最上層是基于服務架構集成的資金管理。

入賬規則和邏輯

會根據對應配置好的具體交易場景來入賬

賬戶主要產品頁面

賬戶列表包括交易場景、交易單號、賬戶期初余額、收支、期末余額、及本次交易具體場景的備注等。

04 家政-賬戶系統

家政平臺是撮合勞動者和終端消費用戶的平臺，建立服務者與消費者之間的服務關系。其中，勞動者包括月嫂、保姆、保潔等，提供的服務包括月嫂服務、育兒嫂服務、保姆服務、保潔服務等。

服務結束后就需要給勞動者進行服務收入的結算，而在業務發展中，又存在勞動者以及用戶的介紹人，從而存在轉介紹的場景；同樣，也會在一些城市簽約代理商，就有了渠道商的場景。在這些場景中就有了與介紹人和渠道商的分成分潤結算業務。

所以，家政場景下的賬戶系統主要用于各類角色的結算業務，對勞動者的服務收入結算，對介紹人和渠道商的分成分潤結；而賬戶種類的建設就是圍繞不同角色的不同結算業務建立。

勞動者的收入結算賬戶、合伙人的分成賬戶、渠道商的分潤賬戶等，再結合一些其他場景比如保證金繳納場景，又增加了保證金賬戶。

做為記賬系統，這里的賬戶系統主要是接收來自上游系統的記賬請求，除此之外還需要向上游提供開戶服務，賬戶信息的查詢服務，賬戶余額及流水的查詢等服務。

下圖也包含了渠道商與賬戶有往來的業務。

賬戶系統架構上最底層是賬戶的基礎能力，包括主體管理、賬戶管理、交易管理等，中間層是基于基礎能力封裝出來的服務單元，最上層是基于服務單元集成的解決方案。

賬戶記賬是一個非常重要的環節，該賬戶系統的記賬是基于配置好的入賬規則進行，而規則中主要依賴預先設定好的“費用項”，再介紹幾個入賬參數匹配到入賬規則，規則中設置好入什么賬戶、入賬的方向等內容。

賬戶列表按照賬戶的維度可以查看全部的賬戶，包括賬戶的基本信息，所屬主體，賬戶類型，賬戶余額等內容。

賬戶信息是某一個具體賬戶的詳細內容，該頁面可以對賬戶進行凍結、余額進行凍結。

賬戶流水管理可以查看賬戶的全部變動明細。

05 ETC-賬戶系統

ETC錢包是用于高速ETC通行消費的專用賬戶。由于現在大部分ETC為記賬卡，也就是先通行后付款的模式，因此車主需將通行費充值到ETC錢包才能在高速通行后進行正?？劭?，一方面滿足部分不想使用代扣模式的用戶的需求，另一方面也算是為了降低經營單位的墊資風險。

若車主未提前或及時在通行后存入通行費導致扣款失敗，且沒有按時補繳的則會被列入高速ETC限制通行名單，直至繳清欠款后才會解除。（ps.ETC被列入限制通行名單，則只是走不了ETC通道，可以走人工通道。當然ETC逃費是違法的哈，也是會被稽查的~）。

欠費之后，ETC錢包就會被扣減至負數，直接體現出當前欠款金額。此外根據ETC產品的不同，欠費超過一定次數或者時長也可能產生違約押金，延伸出了違約押金錢包。

而為了搶占市場，經營單位如果給用戶補貼通行費用，則又延伸出了紅包錢包。

錢包賬戶模塊，最主要是接收來自賬單模塊發起的通行賬單扣款記賬和支付模塊發起的充值記賬，其次伴隨著車輛用戶欠款違約，會產生違約扣款記賬；車輛用戶注銷，則需要把余額提現返還給用戶；更有用戶偶爾的多充、錯充，導致需要給用戶充值退款。

常規的賬戶業務流程如下圖。

初由于ETC扣款的場景沒有特別多，入賬規則和邏輯并沒有走配置化，費用場景也是代碼枚舉寫死的。

當業務有對應的交易場景的時候，比如分傭、獎勵、違約金、消費等，可以根據我們預先配置好的入賬規則，來決定給某個主體的哪個角色的哪個錢包加錢還是減錢，是否凍結金額，怎么凍等等。

當業務場景多的時候，用戶名下賬戶也多起來的時候，如果要快速支持響應業務場景的變更，那就需要更靈活的配置來實現，而不是每次去改代碼，并且有管理后臺記錄我們每一個賬戶場景，也便于業務運營。

下圖以ETC舉例子，當建設了統一賬戶系統之后，可以根據不同的業務線配置和修改不同的入賬規則，如每一筆推廣費用如哪個賬戶、是否凍結，凍結多久等。

在ETC違約欠款這個場景下，還有一個比較特殊的點跟大家分享一下，用戶欠款之后錢包余額往往為負數，違約之后會被扣取一筆違約金，但是此時往往是扣不到錢的（因為錢包余額已經不足），而實際扣取到的違約金是記錄在上述【違約押金賬戶】，等到用戶注銷之后是要退還給用戶的。

在用戶端需要給用戶展示兩個信息，一是用戶目前所有欠款金額（路費欠款+違約金欠款），二是用戶違約金，如果沒有新增一個【待交押金賬戶】，用于區別用戶實際扣取到的違約金，和仍需繳納的違約金，則無法區分用戶的錢包欠款有多少是屬于違約金欠款，也無法定義用戶如果部分還款的時候是先還違約金欠款還是通行欠款。

賬戶列表：

賬戶主體信息：

入賬規則配置：

如果企業業務涉及到多客服咨詢的業務，給客服同事聚合一個查詢頁面，能快捷地查到某個用戶（主體）名下各類賬戶信息及其他業務信息。

06 電商-積分賬戶系統

積分電商平臺是一個撮合商家和消費者的平臺，銷售商家入網到平臺，上傳相應的產品，用戶通過平臺公域商城或商家私域商城購買商品，用戶支付方式有全積分、積分加第三方支付、全額第三方支付。平臺通過支付方式及積分抵扣金額計算并生成支付單。

商家入網成功后，平臺將生成積分賬戶和現金賬戶，積分賬戶主要用于計算用戶積分抵扣部分，結算時平臺將通過第三方代付或營銷補貼進行金額結算；現金賬戶主要記錄用戶通過第三方支付的金額，結算時平臺將通過分賬進行訂單金額結算。

因此，平臺賬戶系統-商家角度，主要用于記錄商家的資金流水及總額，分為已結算金額、凍結金額、在途金額；平臺角度，生成平臺使用費賬戶，主要通過商家設置商品的積分比例計算出的平臺抽傭金額，可分為已結算金額、凍結金額、在途金額。

另外用戶在平臺每消費一筆，都會按照積分比例產生相應的積分贈送，所以還會有用戶積分賬戶。

賬戶系統的記賬，主要通過訂單履約系統訂單支付成功后發出的記賬請求完成賬戶之間的收入流水、退款流水、提現流水等。當訂單完成時訂單履約系統又會請求賬戶系統，并且將各角色的賬戶推送至結算系統，由結算系統完成相應的現金、積分結算，現金將T+1進入商家對公賬戶，積分將實時到達用戶賬戶。

賬戶系統涉及平臺主體的管理、賬戶類型管理、賬戶管理、各賬戶流水的變動明細、賬戶操作和通過賬戶信息生成的報表展示；商家入網成功后，系統將生成類型所涉及的賬戶號，并在銷售完成或消費成功后產生賬戶明細記錄及賬戶余額變動，并由各個子系統之間共同完成。

用戶在平臺消費產生訂單，商家執行訂單履約，履約完成后用戶確認收貨，此時系統將執行清算，訂單內第三方支付金額將記入商家收入現金賬戶，如果有積分抵扣部分將記入收入積分賬戶，具體入賬金額計算方式為通過訂單內商品設置的積分折扣，計算出每個商品需要收取的平臺使用費，在按照積分抵扣比例，分別計算到每個商品上，最終計算出平臺現金傭金X元，平臺積分傭金Y元，訂單實付金額扣除平臺傭金后為商家實際入賬金額；在清算完成后入賬資金狀態為可提現金額，系統定時執行請求第三方結算資金。

另外在訂單確認后，系統還會計算贈送用戶積分數，同樣按照商品積分比例，求和統計出每個商品應贈送積分數，并將積分入賬到用戶積分賬戶，用戶積分不可提現，只可以在下次消費時抵扣使用。

賬戶列表頁主要展示賬戶所屬主體，賬戶當前余額、賬戶在途金額（產生訂單未入賬）、凍結金額（異常情況操作凍結）、賬戶創建時間、類型等；因對接第三方機構，結算按照訂單來執行，賬戶金額總數為明細內訂單不同類型的總和，平臺可針對明細進行凍結/解凍操作（僅限待結算）。

平臺收入=訂單總金額-商家收入，會產生增加，但因為積分部分平臺會涉及營銷補貼至商家，會從平臺收入內扣除，平臺總收入-總支出=總利潤。

07 校園一卡通-賬戶系統

一卡通平臺用于管理學生各類活動的充值及學生校內消費。一卡通平臺提供一卡通充值服務及一卡通消費服務，包含餐費充值及消費、水費充值及消費、電費充值及消費、公話充值及消費等等。

學生通過充值點進行一卡通充值，學生消費后，平臺從中獲得一定比例的平臺服務費。

賬戶中心是整個平臺的核心，主要的業務流程如下，包含學生賬戶的開立，一卡通充值、一卡通消費及其分賬的過程。

賬戶中心主要包含賬戶主體信息管理、賬戶管理、賬戶流水管理。賬戶根據賬戶科目的設置可建立層級關系，主要目標是把賬記清楚。

一卡通充值入賬規則：選擇充值人、一卡通充值費用類型、充值金額，充值成功后，在費用類型賬戶中記入充值金額。

一卡通消費入賬規則：學校一卡通消費時，不同的刷卡終端設置不同的費用類型，根據費用類型進行一卡通賬戶的記賬。

分賬入賬規則：不同商戶設置不同費用類型的分賬規則，分賬規則中含有分賬收入方信息，根據一卡通消費記錄中的費用類型匹配分賬規則，算出分賬明細，在分賬收入方賬戶中記錄待結算明細。

結算入賬規則：通過結算定時任務進行賬戶中待結算數據的結算，并將待結算明細更新為已結算。

08 銀行收單-賬戶體系

銀行建設的收單系統一般會涉及結算戶、內部戶、虛擬戶等。

結算戶是指商戶的收款賬戶，因為商戶賬戶的資金都是收單未結算資金，銀行一般要求商戶開立本銀行的賬戶作為結算戶。

內部戶是指機構為了方便其結算資金使用的過渡記賬賬戶，這類賬戶都是機構預設的，只有機構才能操作這些賬戶，商戶對其是無感知的。

虛擬戶是指收單系統內部的建立的一套登記簿，不屬于銀行賬戶，僅僅用于記錄多種交易場下的記賬。下文講到的客戶待清算、待結算、已結算等賬戶都屬于虛擬戶。

支付平臺（收單系統）對接銀行核心系統，業務平臺于銀行內部核心系統開立總賬戶，支付平臺內開立平臺商戶、平臺用戶二級虛擬戶。收款資金沉淀在銀行，通過支付平臺指令由銀行將資金清算至平臺商戶、平臺用戶的實體資金賬戶中，實現資金流轉合規化，規避二清風險。

賬戶系統主要實現建立多級賬戶體系、憑證管理及賬戶記賬等功能，可滿足賬戶擴展功能及新業務接入時自動記賬規則配置。

銀行僅需為平臺在核心系統中開立內部戶，無需對現有系統進行任何改造；電商等平臺子商戶通過調用支付平臺商戶入網提交資料請求接口，完成在銀行支付平臺中子商戶信息錄入和開戶、個人信息錄入和開戶、銀行卡綁定，符合小核心、大外圍的核心思想。

平臺商戶和交易商戶入網成功后，支付平臺會生成如下賬戶，主要包含待清算賬戶、待結算賬戶、已結算賬戶以及基本戶等。

根據不同的交易節點講解入賬邏輯，本文主要講解支付、分賬、結算以及提現對應的記賬邏輯。退款、對賬等場景由于篇幅原因暫時不講解。

用戶在優選平臺上下單，選擇某種支付方式完成交易。支付成功后支付平臺（收單系統）會做一次記賬。以優選為平臺商戶，海鹽為交易商戶為例，用戶張三在優選平臺海鹽店鋪購買一件商品1000元，使用了微信支付，用戶支付完成后支付平臺（收單系統）會進行清分記賬，記賬結果如下：

備注：記賬順序從下往上看

用戶確認收貨后進行分賬，支付平臺（收單系統）根據優選平臺分賬指令進行分賬，分賬到平臺商戶及交易商戶賬戶中。假設分給海鹽900元，分給優選平臺100元，記賬結果如下：

備注：記賬順序從下往上看

T+1日支付平臺根據結算規則生成對應的結算單，然后再給平臺商戶和交易商戶打款，平臺未接觸到資金，由收單系統進行清分結算，業務操作合規、資金安全。

備注：記賬順序從下往上看

系統根據提現規則，支持自動提現和手動提現。下圖中監管賬戶是由支行開立的內部戶，平臺無法操作賬戶，只能提現屬于其的資金。

備注：記賬順序從下往上看

重點說明：客戶未提現前的資金都存放在銀行的監管賬戶中，平臺無權限挪用資金，當客戶提現或者系統自動提現時，資金由監管賬戶到客戶賬戶，整個環節保證了資金的安全。

整個交易的過程資金流走向如下圖：