賬戶系統設計從入門到精通

賬戶作爲支付交易的最基礎設施，可見其重要性，其核心不是設計本身，而是他的理念以和規範以和基本原則；可以幫助你從 0 到 1 全面掌握賬戶系統的設計方法，最後附帶後臺設計的幾頁關鍵頁面原型...... 深吸一口氣，讓我們開始吧！

第一部分：賬戶系統概述

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

1. 什麼是賬戶

我們先看看標準定義

賬戶是根據會計科目設置的，具有一定格式和結構，用於反映會計要素的增減變動情況及其結果的載體。

增減變動的會計分錄的書寫規範

借: 科目 A 金額 1

貸: 科目 B 金額 1

賬戶結構規範

賬戶的基本結構應同時具備以下內容:

  1. 賬戶的名稱，即會計科目;

  2. 日期和摘要，即記載經濟業務的日期和概括說明經濟業務的內容;

  3. 增加方和減少方的金額及餘額;

  4. 憑證號數，即說明記載賬戶記錄的依據。

財務知識不是很充足的同學可能對以上的賬戶定義很難理解和繞口；我們從業務的角度來看賬戶，後面的電子賬戶我們都會從業務角度去看，拋棄財務視角

從業務視角來看賬戶其實就是用於記錄某個主體的某類型資金的餘額以及餘額變動明細的數據載體

所以賬戶有 3 個關鍵的點

**賬戶餘額：這個賬戶有多少錢
**

賬戶流水：這個賬戶資金進進出出的明細記錄

賬戶交易：怎麼把錢放進去，怎麼把錢取出來

抓住了上面 3 個點我們基本就抓住了賬戶設計的核心了，是不是很簡單

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

2. 賬戶的種類

從財務科目分類來看內部賬戶，賬戶可以分資產類賬戶，負債類賬戶，損益類賬戶，共同類賬戶，然後就是不同的科目

但是站在業務的視角，我們更多是基於業務場景來對賬戶進行命名，比如商戶的結算款會結算到商戶結算賬戶，支付公司在銀行開的賬戶叫備付金賬戶，備付金賬戶又分存管戶，收付戶，匯繳戶；個人賬戶，企業賬戶；會員子賬戶，商戶子賬戶，中間擔保戶

所以從賬戶命名上我們基本就知道了這個賬戶是幹嘛用的；就像你有 10 張卡，一張是放工資的你叫他工資卡，一張是公積金的你叫公積金卡等等，所以這時候我們基於業務命名，目的是爲了區分賬戶用途

但是收回來我們發現，無論賬戶叫什麼名字，都是有賬戶餘額，賬戶流水，賬戶交易；無論卡叫什麼名字都是銀行卡；所以賬戶的本質屬性不變，設計辦法基本相通，唯一會有不同的是附屬內容，比如支出戶只能打款不能收款，中間擔保戶不能爲負等等，權限不同，主體不同，交易特點不同.....

小樣，你以爲穿個馬甲我就不認識你啦，你裝錢的，能進能出，記得明明白白；別管你叫啥我都知道怎麼設計，不管我叫你啥我都這麼設計

3. 賬戶的結構

**賬戶結構
**

chTmFf

賬戶服務

賬戶底線原則

支付成功才入賬，扣賬成功纔出款，一分不少真安全

4. 如何設計類型

賬戶名稱，結算戶，付款戶，支出戶

原則：名稱是便於區分業務，賬戶本質相同

就像有的公司叫產品經理，有的公司就產品策劃，有的公司叫需求分析師；但本質大家乾的都是產品設計工作

基於主體類型命名賬戶：個人賬戶，企業賬戶

基於業務類型命名賬戶：電商商家結算戶，快遞商家結算戶

基於資金屬性命名賬戶：工資賬戶，公積金賬戶，手續費賬戶

基於賬戶職能命名賬戶：待清算賬戶，中間擔保賬戶

等等，現在應該清楚設計賬戶時如何給賬戶命名了吧，簡單易記，容易區分

5. 賬戶的附屬設施

有了電池是不是還需要充電線，有了油罐是不是還得有加油設備，安全設備；同樣有了賬戶是不是還得有附屬模塊才能實現賬戶的資金管理職能

費用類型

每筆交易都有業務場景，比如下單付款，投訴罰款，用戶充值，餘額提現，賬戶年費等等，一個是爲了讓用戶知道這是筆什麼交易，另一個就是財務能夠知道編寫什麼科目的會計憑證

fggphI

入賬規則

上游有業務系統比如賬務系統請求一筆費用的入賬，那麼如那個賬戶呢，收支方向如何呢？所以入賬規則就是來確定這筆入賬怎麼入的問題，規則主要有 2 部分組成

JS16aK

**
凍結規則**

有些費用入賬後是需要暫時凍結的，比如用戶領的活動獎金，必須在凍結 7 個工作日之後才能解凍；某業務線的商家結算收入，統一在次月 15 號可提走；所以一條入賬規則需要關聯一個凍結規則

5TXrA2

費用 / 入賬規則 / 凍結規則關係

一個費用入賬時，可能記一筆賬，也可能記多筆；比如商戶佣金費用，則會入兩筆賬：成本賬戶入一筆扣款，商家傭金賬戶入一筆收入；而扣款不用凍結，收入需要凍結 7 天

對外服務

任何系統都不是孤島，賬戶系統同樣，要將能力賦能給上游實現自己的價值；賬戶向外提供的服務基礎的應該包含：開戶，註銷，查詢（餘額，流水，狀態），交易（支付，退款，充值，提現，凍結）等

賬戶管理後臺

賬戶系統需要提供一個業務後臺給到相關的運營人員，財務等角色；後臺可以查看所有的賬戶以及賬戶的狀態，所屬主體以及餘額情況；還可以操作賬戶進行註銷

還需要能夠查看所有的出入賬流水，配置相關費用，配置入賬規則和凍結規則

6. 賬戶系統架構圖

功能架構

業務架構

7. 賬戶入賬流程圖

8. 賬戶系統後臺

上面基本已經很清楚了，賬戶系統後臺頁面文章不再詳述，原型可以到星球進行下載

9. 賬戶的應用

賬戶除了管錢之外還可以在此之上構建一些應用產品比如下面這兩個

錢包

像微信錢包，就是用戶的一個虛擬賬戶，在錢包裏可以看到餘額，可以充值餘額，也可以將餘額裏的錢提現到銀行卡

餘額支付

賬戶可以作爲一種支付方式，包裝出一個支付通道，利用平臺自己的賬戶進行平臺商品的購買支付，當然這個要考慮合規性

10. 合規淺談

果然最後說的都是重頭戲，賬戶作爲一種資金池形態，要嚴格做好其合規性，如果平臺沒有資質牌照，那麼自建可以但是用戶賬戶的真實資金一定要放到監管賬戶當中進行監管，避免違規沉澱資金池，其他合規風險讀者朋友們自己思考一下吧

第二部分：賬戶主體

賬戶本身記錄的是資產或者負債或者費用，那麼必然就需要一個主體承載，誰的錢，誰的債，誰的費用，誰的愛！世界上沒有一片樹葉沒有歸屬，就算秋風落了葉，那它要不屬於天空或是歸屬大地，所以賬戶歸於誰，而這個誰是誰就是今天我們要聊的主體

1. 什麼是主體

主體可以是人，可以是公司，可以是一個組織，我們暫且認爲主體就是一個具有基本特徵和屬性的一個可定義的對象

2. 主體的廣義定義

基於對象出發，那麼主體可以認爲是自然界存在的實體物質和虛無的對象；比如一個人是一個主體，一個公司是一個主體，一個組織是一個主體；公司的一條業務線是一個主體，公司的一個部門也是一個主體，一個城市也是一個主體，一座房子也是一個主體等等

那麼這麼多主體有什麼意義呢，其實就是說明賬戶的主體可以非常廣義，比如一個城市的 GDP, 可以通過一個統計報表得到，同樣也可以爲每個城市設置一個 GDP 賬戶，那麼這個賬戶的主體就是一座城市；北京 GDP 賬戶 2020 年年末餘額 4 萬億！

所以主要是一個可以被定義的對象，我們就可以將它作爲賬戶的主體來管理，就可以爲之開通某種意義上的賬戶，賬戶也可以是廣義的，不只是金錢餘額，也可以是水量餘額，點量餘額，好感度餘額等等，從而賬戶的廣義我們是不是就可以認爲：賬戶可以記錄一個可被量化的數量以及變化過程的記錄工具；那麼我們就可以用賬戶的設計理念去設計更多的事物的數量以及變化過程

3. 狹義賬戶主體

我們迴歸賬戶主體本身，就是賬戶的歸屬對象；最常見的主體就是個人和企業；銀行卡的主體有個人主體和法人主體；

對於一個公司內部來說爲了經營分析或者管理的需要又會虛擬出更多的主體類型，比如營銷賬戶的這類費用賬戶的主體可以是業務線或者部門或者小組，來記錄部門和小組的預算以及預算的消耗

站在人民銀行的角度看賬戶主體我們知道就是：網聯，銀聯，各商業銀行，各城市處理中心，各特批處理機構等

站在銀行角度看銀行賬戶主體就是：個人，企業，支付機構等

站在一個普通企業看賬戶主體就是：個人用戶，企業用戶，內部業務線，子公司等

4. 主體的唯一 ID

就像個人我們的唯一 ID 可以是身份證，我們在開銀行卡的時候就是用的身份證 ID 作爲這個主體的唯一 ID，在辦理社保的時候也是用身份證 ID 作爲身份的唯一 ID；唯一 ID 的條件就是能夠唯一識別這個主體

比如個人的唯一 ID 可以是身份證，手機號，社保號，一個平臺的 userID 及時在這個平臺的唯一 ID；

企業的唯一 ID 可以是統一社會信用編號，也可以是對公戶的卡號等；如果企業入駐了一個平臺那麼這個平臺爲這個企業生成的企業編碼也可以唯一識別這個企業

唯一 ID 的用途就是唯一識別這個主體，但是有時候可能這個主體的唯一身份 ID 不夠用，比如這個人在淘寶即是個人用戶又是商家用戶，那麼他在開戶時可能就不能只用身份證了，而是用 userID 去開付款戶 和 bussid  去開結算戶 

5. 主體的身份認證

安全起見，我們需要覈查主體的身份，像銀行開戶需要本人到場 + 身份證覈驗；二類戶的開通需要多要素鑑權識別主體身份的合法性

對於企業來說企業的營業執照，法人簽字，蓋章或者對公戶小額打款來驗證企業的真實身份

6. 主體的創建

對於一個平臺而言，其賬戶系統的主體無非以下幾種

個人用戶：具有身份證或者手機號唯一識別的一個自然人個體

企業用戶：具有企業信用編號唯一識別的一個法人主體

內部主體用戶：爲了管理需要內部的子公司主體或者業務線主體或者部門

主體下業務線子用戶：一個子公司下面的一個業務線或者部門

所以我們在創建主體的同時就需要定義每一類主體的唯一識別 ID

在開戶的時候，就需要使用這個唯一識別 ID 作爲賬戶主體的唯一識別 ID

7. 主體的信息管理

一個平臺的各類主體信息一般是放在用戶中心或者 crm 系統，這些系統去調用賬戶中心進行開戶，在這些系統內對於一個主體我們需要管理他的基本信息，比如 ID 信息，屬性信息，權限信息，關係信息；有什麼信息就增加字段管理即可，也可以將信息分類，每一類記錄的不同的表中，比如身份信息，認證信息，賬戶開通信息等

8. 爲主體開戶

有了主體以後，賬戶的開通可以是人工也可以是上游系統調用開戶接口開通相關賬戶和賬戶權限

比如接口要傳入下面的信息

入參

主體 ID：123

ID 類型：userid

用戶類型：個人

用戶姓名：張三

開通賬戶類型：佣金賬戶

賬戶特殊要求：可付款

請求成功後賬戶系統就會先在賬戶主體表中插入基本主體信息，如果需要其他信息，在後面加字段即可

根據主體 ID 可以去賬戶表查詢開通的所有賬戶

然後基於開戶請求我們在賬戶中心表中創建對應的賬戶，賬戶中心表中要有主體的用於開戶唯一 ID

Z7M9j0

同時在賬戶餘額表中創建賬戶餘額

U3P5Vw

同時在賬戶的權限表中設置賬戶權限

8hLjvB

賬戶中心經過一些列的處理後賬戶就開通了，然後返回給開戶方

出參

開戶結果：開通成功

我們從上面的開戶過程可以看出來，賬戶內部和主體之間是一個複雜的對應關係

9. 主體與賬戶的關係

通過 8 我們知道，主體和賬戶以及賬戶內部有複雜的對應關係

主體 vs 賬戶是一對多的關係，一個主體可以開通多個賬戶，每一個賬戶又會關聯餘額表，權限表，流水錶

主體的開戶 ID 去關聯賬戶的賬戶 ID，賬戶 ID 去關聯賬戶的餘額表中的餘額，權限表中的權限

第三部分：賬戶結構

1. 簡單賬戶結構

賬戶結構一個是本身的結構有什麼組成，另一個就是賬戶體系內賬戶與賬戶之間的構成模型，我們主要說後者，我們看幾個最簡單的賬戶結構

只有一類賬戶，比如整個賬戶系統只有一類賬戶：張三 - 工資賬戶

有多個類型的賬戶，比如下圖，但本質上依然很簡單，很容易管理

2. 簡單餘額結構

餘額結構就是針對賬戶內部來說，賬戶的餘額如何劃分，就像火鍋，有一個鍋，鴛鴦鍋，九宮格，一樣，賬戶作爲一個容器，其內部依然可以劃分成多個存儲空間

只有一個餘額的餘額結構，你會發現微信錢包的餘額就只有一個，有多少就是多少，簡單粗暴

R4zqCb

這樣的餘額結構必然支持的交易種類就很簡單，收入，支出；無法支撐其他的針對餘額的處理

3. 複雜賬戶結構

隨着業務的複雜度增加，各類功能性以及運營需求增加，簡單的賬戶結構開始變得複雜，以支撐更復雜的業務模型，比如紅包可能每個業務線都要推出一種紅包營銷形態，比如保險業務線，遊戲業務線；而紅包又被拆分成了現金紅包，虛擬幣紅包等這樣的話紅包賬戶結構就成了多層級的賬戶結構；如下

看着是不是很像會計科目的結構，最下一層是不是很像葉子科目，當然第二層和第三層換一下位置也可以；這種情況下賬戶結構就很複雜了，而且自然存在了總賬戶和明細賬戶之分

還有一種是賬戶結構分總分機構，但二級賬戶的種類繁多，功能劃分較細，這類賬戶結構具有支撐複雜的記賬能力，以及業務處理能力，這類賬戶結構常見在二清監管戶體系，比如下面具有衆多子賬戶的賬戶體系，協同完成資金的監管和分賬職能

一朋友諮詢我人力資源代理平臺的賬戶該如何設計，業務模型就是平臺幫助很多企業代收代發工資，並且支付公積金和社保等多種資金款項，我設計了四個方案，你覺得那個方案好呢

4. 複雜餘額結構

因爲資金清算週期或者業務流轉節點多，或者其他風控要求，需要對賬戶餘額進行復雜的處理操作，比如有的能提，有的不能提，最常見的結構就是三個餘額屬性

D1pBWi

覈算恆等式：總餘額 = 凍結餘額 + 可用餘額

這樣的話，就可以對賬戶餘額進行一些處理，比如發的紅包 7 天后才能提現，那麼紅包入賬戶時就會先入凍結餘額，7 日後解凍之可用餘額

5. 賬戶結構和餘額結構的關係

從上面我們可以看到，賬戶可以分多級，餘額可以分多塊，那麼有什麼關係呢

多級之間：x 級總賬戶總餘額 = sum(x-1 級子賬戶所有賬戶總餘額之和)

某個賬戶：總賬戶餘額 = 凍結餘額 + 可用餘額

上面另個恆等式可以用於校驗賬戶系統記錄的合法性，是不是覺得跟會計系統科目之間的試算平衡很類似

6. 賬戶管理表的設計

通過前面的賬戶主體，賬戶結構，賬戶餘額結構，我們基本可以設計出賬戶表的基本字段了，只要包含這幾部分信息：賬戶主體信息，賬戶結構信息，餘額信息，賬戶狀態信息，我們設計如下，除了核心字段以外，其他想展示的字段可以去相關表中查詢，比如主體姓名，可以用主體 ID 去主體表中查詢

7. 餘額的變化

我們簡單說一下，後面在將流水和餘額更新時會細講；賬務請求賬戶入賬時，基於凍結規則我們可以知道該筆入賬是否需要凍結，如果需要凍結的話就更新凍結餘額，後面再解凍，如果不需要凍結的話就直接更新可用餘額

作業：思考一下，如果你是螞蟻財富的賬戶產品經理，你會如何設計賬戶結構和餘額結構，來滿足業務模型呢？歡迎在產品羣或者星球提交作業！（備註小心有坑哦）

第四部分：費用管理和入賬配置

有了賬戶那麼賬戶裏就需要存入和存出，充值和提現，轉賬和消費；這樣賬戶纔會流動起來，纔有了生命力；那麼在交易場景裏費用就顯得十分重要了，多少錢，什麼費...... 我們以滴滴司機的結算賬戶爲例來討論本節內容

1. 交易場景

任何一筆收支都依賴於一個場景，而且這個場景基本涵蓋所有後續清結算的信息，

比如用戶叫了一輛快車，張師傅接了單子，從立水橋南到奧森公園；這就是一個交易場景，我們可以稱爲” 快車打車場景 “，在這個場景下我們可以知道用戶是誰，在哪打的車，什麼車型，起步價多少，每公里多少，司機是誰等；

如果車到了，超過了 4 分鐘用戶不用車取消了，那麼這時候就需要支付一個取消費用，這又是一個場景，我們可以稱爲 “超時取消場景”

我們將平臺的所有交易場景進行枚舉，如果要新增場景，那麼要預先在場景中心申請場景編號，才能開展上線業務

2. 費用

在上面的場景中，就會產生交易，因此產生一些列的費用，

比如打車單訂單費用，完單後要給司機做結算就有了訂單結算費用，平臺要抽取一定服務費就有了 “平臺服務費用”，如果高峯期給司機發一定補貼的話就有了“高峯補貼費” 等等；

費用就是站在業務角度定義資金的業務屬性，基於業務側的費用我們可以關聯到後續的財務科目，這樣的話費用是從業務發生那一刻就產生並且定義了，而且最後關聯到會計科目，這樣業務和財務實現信息一體，對於業務記賬以及轉財務賬提供巨大的遍歷

3. 計算

這需要一個強大的計算系統，我們在支付系列清結算模塊會做重點介紹；這裏點到爲止

下單前的預計算，爲用戶選擇起點和重點後預先計算可能需要的訂單費用

進行中的實時計算，這個大家都打過車就不再說了

結束後的計算，計算出本單實際產生的費用

我們可以看出訂單總費用包含三部分：起步價 + 里程費 + 時長費；你可能會問，一個訂單爲什麼要拆成這麼多費用呢？我們簡單想一下，這三個費用的特點，而且這三個費用在不同的城市，不同的時段，不同的用戶，不同的車型都會發生變化，所以我們可以理解爲，費用的細化是精細化運營的必然結果，另外用戶也需要知道爲什麼收這麼多錢

訂單的清結算，訂單完結後就需要給司機做結算，那麼還需要進行一次計算，那就是這一單應該給司機多少錢，平臺抽多少錢，要不要實時扣稅，有沒有其他費用，比如保險費，我們得出如下的清算結果

4. 賬戶結構和餘額結構

簡單點，每個司機只有一個結算賬戶，在某支付平臺開通的二類支付賬戶，沒有其他類型的賬戶，接單的收入，補貼獎金全部結算到該賬戶，司機可以進行提現

因爲爲了風控客訴問題，我們爲司機設置一個 7 天的訂單結算凍結期，這樣的話我們的賬戶餘額分成了凍結餘額和可用餘額，可用餘額可以用於提現

5. 費用管理設計

上面我們講了交易場景和費用的定義，現在我們就來設計費用費用管理，設計費用有三個關鍵點

費用編碼  費用名稱  費用結構

這裏的設計辦法有 2 種

一級枚舉型，就是費用之間沒有關係，對所有費用進行枚舉，有規律設置編碼

多級結構，就是像會計科目一樣，有總科目，明細科目，明細科目可以設置多級

以上兩種方式可能第二種更好一些，特別是在覈算和統計時，可以進行總分分別進行統計分析和核算

6. 入賬規則管理

我們設置好了費用，那麼在每個節點都會產生費用，或者計算出相關的費用，比如司機收入，那麼清分之後就需要計入相關的賬戶，比如司機收入要計入司機的結算賬戶；那麼還可能一個費用要計入多個賬戶，比如複試記賬時，又比如司機獎金可能要同時計入平臺的運營賬戶和司機的結算賬戶

入賬規則設計有兩個關鍵點

一個是匹配條件：要基於入賬請求傳參的條件來匹配到相關的入賬規則條目，比如我們需要定義每類記賬請求需要什麼條件，比如司機收入入賬，一個條件就夠了

費用類型   司機收入

另一個是入賬規則：就是這個條目指定入什麼賬戶，比如司機收入匹配到的規則應該是要入司機結算賬戶，則入賬規則是

賬戶主體：司機

主體 ID：司機 ID

賬戶類型：結算賬戶

這樣我們就得到了一條入賬配置規則

基於上面的規則，上游系統在申請入賬時必須傳幾個參數：費用類型，主體類型，主體 id; 基於司機收入這個費用，我們就匹配出一條規則，應該入司機的結算賬戶，利用司機 ID 找到相關的結算賬戶 ID 然後計入賬戶

第五部分：凍結配置與賬戶流水

當業務系統請求入賬以後基於費用類型以及入賬規則我們就可以知道應該入哪個賬戶；這時候問題就來了，因爲賬戶餘額也是分結構的，有凍結和可用，那麼要是想先凍結起來怎麼辦呢？

我們先回顧一下上一篇的最後一個圖，在凍結處理裏我畫了一個虛線圈，本篇文章我們就把他做實了

1. 凍結規則

我們在賬戶系統設計詳解裏講過凍結模塊，這裏我們再細講一下；凍結就是一個費用請求入賬時要基於業務要求決定需不需要暫時凍結起來，還是直接就可以使用；那麼如何設計凍結規則呢

凍結規則是基於入賬規則設置的，也就是這筆入賬需不需要凍結，如何凍結，是全部凍結還是部分凍結；這裏我們以全部凍結爲例

所以一個入賬規則要關聯一個凍結規則，入賬的時候就需要同時獲取凍結規則；入賬規則和凍結規則是一對一的關係，費用類型和入賬規則是一對多的關係

凍結規則有 2 部分組成，一個是關聯的入賬規則；另一個是凍結規則；也就是說在配置入賬規則的同時就需要關聯性的去配置一條凍結規則

B6bevb

凍結規則的配置有幾個關鍵點

凍結模式：就是按照固定時長凍結還是凍結到固定時間點

凍結時間：如果選擇固定時長的話就填一個時間值，如果是固定時間的話就選擇一個可循環的時間點函數，比如次月 10 號，就配置成 M+1 月 10 號

2. 賬戶流水

賬戶有 2 個核心部分組成，一個是賬戶餘額我們已經講過了，另一個就是賬戶流水，賬戶流水就是記錄了賬戶的變動歷史明細，我們收窄爲 “資金的變動明細”

爲了記錄資金的變動明細，我們就需要記錄最基本的明細信息，一般必須包含以下信息

賬務流水號：作爲該筆明細的唯一標識

請求 ID：請求入賬方的 ID，便於後續的核算

賬戶 ID：這筆流水屬於哪個賬戶（會計記賬就是科目編號）

費用類型：這筆流水是什麼費用

金額：發生額

剩餘餘額：這筆流水發生後的賬戶餘額

收支：支出，收入，這筆流水是增加餘額還是減少餘額（同會計分錄的借貸）

賬務發生時間：記賬時間

會計時間：作爲業務口徑和財務口徑轉換的時間（非必須）

備註：業務備註信息

凍結狀態：凍結的管理

操作：凍結 / 解凍

這樣我們就將業務的記賬請求通過入賬規則處理，凍結規則處理，進入到賬戶系統並且生成賬戶流水了

3. 更新賬戶餘額

這裏有一個賬務處理任務流，每筆入賬都需要從頭執行到尾，不能遺漏，任何一個處理失敗了這筆入賬就宣佈失敗進行入賬的失敗處理，我們先設定一個最簡單的任務流

檢查賬戶流水合法性  通過

賬戶流水錶插入賬戶流水   完成

基於賬戶流水信息更新餘額表對應賬戶的凍結餘額或者可用餘額  完成

      賬戶 ID：

      總餘額 = 總餘額 + 本次發生額
      凍結餘額 = 凍結餘額 + 本次發生額（凍結時）

      可用餘額 = 可用餘額 + 本次發生額（不凍結時）

自洽校驗：總餘額 = 凍結餘額 + 可用餘額     通過

入賬成功

經過一些列的處理，入賬成功了，通知請求方，本次入賬結束

4. 餘額解凍

因爲入賬的時候有的流水處於凍結狀態，那麼我們就需要按照凍結的規則進行解凍，這時候就需要一個凍結解凍處理的任務進行掃描執行，至於掃描的模式要基於凍結模式去設計，我們以凍結固定時長最小單位爲天爲例，那麼任務就需要每日凌晨去掃描遍歷所有處於凍結狀態的賬戶流水，滿足解凍條件的變更凍結狀態爲未凍結，然後對餘額進行處理；這又是一個處理的任務流

任務掃描遍歷凍結狀態的賬戶流水

滿足條件的賬戶流水變更凍結狀態爲未凍結狀態

扣減賬戶的凍結餘額並同時增加賬戶的可用餘額

解凍完成

第六部分：後臺設計

1. 賬戶列表

2. 賬戶信息管理

3. 賬戶流水管理

10 年產品設計經驗，4 年社交，2 年電商，5 年支付；曾任職於某頭部金融，某頭部支付機構；獲千萬創業融資；PMCAFF 專欄作者；把所見 · 所聞 · 所想 · 所做，在夜深人靜處沉澱成文字留給這個世界！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/T4tsb-KtwgUY22d5txJGnA

猜你喜歡