作者：鳳凰牌老熊? ?來源公眾號：鳳凰牌老熊

支付賬戶和登錄賬號

賬戶體系設計首先要區(qū)分兩個概念，支付賬戶和登錄賬號。這是兩個不同業(yè)務領域的概念：支付賬戶指用戶在支付系統中用于交易的資金所有者權益的憑證；登錄賬號?指用戶在系統中的登錄的憑證和個人信息。一個用戶可以有多個登錄賬戶，一個登錄賬戶可以有多個支付賬戶，比如零錢賬戶，儲值卡賬戶等。一般來說，支付賬戶不會在多個登錄賬戶之間共用。如果沒有特殊說明，下文中的賬戶，都默認指支付賬戶。

賬戶的設計需求

在支付系統中，賬戶的設置，主要是從如下幾個方面來考慮：

交易的需求，比如檢查賬戶是否被鎖定、余額是否足夠、是否有效等。

記賬的需求，按照公司會計需求記錄賬戶上的所有行為，包括支出、充值、轉賬等。

對賬的需求，包括和支付渠道、商戶、個人的對賬需求，核對交易和賬戶余額是否正確。

風控的需求，如反洗錢、反欺詐等，都需要依賴于賬戶體系來提供核心數據。本文暫不分析這個內容，將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析

信用的需求，對用戶、資產、商戶等主體進行信用評估時，也需要依賴賬戶體系來提供的核心數據。本文也暫不分析這內容，將在《信用與支付》一文中分析。

這五個需求，按照其設計的優(yōu)先級，也是從支付、記賬、對賬、風控來進行。支付系統根據其發(fā)展所處的階段，逐步將新增需求納入設計中。

交易與賬戶

賬戶設置，一般是從交易開始的。交易的實現必須有賬戶的支持，賬戶是交易的基本構成元素。從支付系統的角度，交易中涉及到的資金流是資金從一個賬戶流向另一個賬戶。發(fā)起交易的一方，被稱之為交易主體，他可以是個人，也可以是一個機構。

資金從該主體所擁有的賬戶中流出。而接收交易的一方，被稱為交易對手，他也可以是個人，或者機構。和第三方支付或者金融機構的交易不同，電商系統中，交易還會涉及到渠道。

由于電商系統本身并無清結算的資質，所有資金從交易主體到交易對手的賬戶的流動，在大部分情況下，并沒有經過電商系統，而是由電商系統調用支付渠道提供的接口，由它來完成真正的支付過程。當然，渠道也不是活雷鋒，在這過程中，渠道要收取費用。

所以，在電商系統中，一次交易會涉及到三個賬戶：交易主體賬戶、交易對手賬戶以及支付渠道賬戶。如何在這三個賬戶中完成一次交易，我們將在后續(xù)的《交易和記賬》一文中詳細分析。

記賬與賬戶

公司的會計需要對每一筆交易都要做詳細的記錄，即記賬。公司每天都產生大量的交易行為，為了便于管理和統計，一個簡單的方法是對交易進行分類，比如食品、帶寬、辦公用品等等。這個分類，按照公司的規(guī)模和業(yè)務復雜度，可以有一級，二級，三級或者更多級的結構，這被稱之為會計科目。記賬時，除了交易明細，還需要在每個級別上對交易額進行匯總。

一般來說，一級科目上匯總稱為總帳科目，而詳細記錄稱為明細科目。在電商系統中，由于涉及到的參與方較多，記賬也相對復雜，但基本方法也是類似的。電商的參與者可以分為商戶、買家和渠道，對這三類參與者，都需要分別建立總帳賬戶和明細賬戶。

內部賬戶和外部賬戶

當用戶使用銀行卡來支付時，電商支付系統需要和銀行對接，從用戶銀行卡所代表的賬戶上扣除資金。對接了銀行，第三方支付等機構的電商支付系統，它需要連接到用戶在這些機構的賬戶來執(zhí)行扣款或者充值操作，這些賬戶或稱為外部賬戶。對外部賬戶，支付系統只能記錄賬戶在本系統的明細以及累計消費額，無法得知賬戶真正余額。不少電商在玩零錢的概念，也就是讓用戶充值到零錢，使用的時候就直接從零錢中扣除。這就需要零錢賬號。這是電商系統中自己設立的賬號，所以也叫內部賬號，可以知道賬號的全部消費明細和余額。當然，除了零錢賬號，也可以有儲值卡賬號，信用賬號等。

那問題來了，什么時候需要建立賬戶，比如優(yōu)惠券，需要賬戶嗎？一次消費的儲值卡和可以充值的儲值卡，需要建立賬戶嗎？這里先埋個雷，后續(xù)介紹支付和記賬時，給出答案。

收款賬戶和收單賬戶

當電商要對接銀行時，往往都會被要求開設一個收款賬戶。用戶通過這個銀行來支付時，錢就被轉到這個賬戶上。對第三方支付也是一樣。收款賬戶是開設在銀行或者第三方支付這邊的， 即渠道側。一般來說，渠道每天都可以提供這個賬戶的交易流水供電商對賬用。這樣在電商這邊，渠道就成為一個收單機構。所以在電商這邊，建立這個收款賬戶對應的對賬用的收單賬號，用來記錄通過這個渠道進行的各項交易流水。

賬戶建模

說了這么多，目的是為了對賬戶建模。賬戶模型是和公司業(yè)務密切相關的，公司不同規(guī)模，發(fā)展的不同階段需要不同的模型。賬戶建模本身包括三大核心模型：實體模型、賬戶模型和交易模型。從交易模型中可以衍生出針對各個角色的賬戶流水，即明細模型，用于支持對賬。

實體模型

實體模型和用戶、商戶模型有重疊的地方，這里專門針對支付而設置的各個實體屬性。一般來說，支付相關的實體模型需要包括如下的屬性：

• 用戶ID，一般直接映射到登錄賬戶的ID；

• 是否允許執(zhí)行支付；

• 支付密碼；

• 用于設置或者重置支付密碼的手機號；

• 用戶設置或者重置支付密碼的郵箱；

• 用戶的安全等級，根據業(yè)務需要來設置。

賬戶模型

根據業(yè)務需要，可以設置多種賬戶，如支付賬戶、預付卡賬戶、代扣賬戶、零錢賬戶、結算賬戶等。從類別上來說，這里的賬戶，一般指總賬賬戶。一般來說電商系統中涉及的賬戶類型有：

• 虛擬幣賬號：用戶和使用奇點奇豆的商戶都需要建立虛擬幣賬戶。

• 代扣賬號：用來支持訂閱類型的定期代扣；

• 零錢賬號：即電商的內部賬號，用戶、商戶、清算單位需要建立零錢賬戶

• 第三方支付賬號：用戶在第三方支付機構建立的賬戶。

• 銀行卡賬號：用戶的銀行卡信息，每個卡對應一個賬戶。

• 結算賬號：用來支持和第三方支付公司、銀行進行結算用。第三方支付需要為每個商戶號建立結算賬號；銀行需要為借記卡、貸記卡分別建立結算賬號（有必要嗎？銀行卡直連時使用）。

• 代扣代繳賬戶：用來支持代扣稅款業(yè)務。

對這些賬戶，需要設置如下屬性：基本屬性，包括：

• 賬戶號，或稱為賬戶ID，一般是系統自動生成。特別注意的是，要事先約定好賬戶ID的規(guī)則。比如頭三位用來表示賬戶類型，后幾位用來表示賬戶編號等。務必保證根據賬號號能夠快速確定賬戶類型，并且保證賬戶號是不重復的。

• 賬戶名稱，一般是由用戶自己設置的，顯示用。

• 賬戶使用的貨幣類型，注意雖然一張銀行卡可以支持多個幣種，實際在內部，還是針對每個幣種建立獨立的子賬戶。涉及到多幣種的賬戶，也可以采用類似的建模方案。

• 會計科目代碼，一般是一級會計科目的代碼。

賬戶控制相關：

• 是否允許充值；

• 是否允許提現；

• 是否允許透支；

• 是否允許支付；

• 是否允許轉賬進入；

• 是否允許轉賬轉出；

• 是否有安全保障；

• 是否激活；

• 是否凍結。

資金相關：

• 當前賬戶余額：等于可用余額+凍結余額；

• 當前賬戶可用余額；

• 當前賬戶凍結的余額。凍結余額指在賬戶上暫不能使用的額度。在支付的時候，往往是先凍結，商品出庫后， 再實際執(zhí)行扣款。

銀行卡、第三方支付信息：

• 第三方實體的ID；

• 第三方賬號，如銀行卡號或者在第三方支付的open_id等；

• 第三方的app_id；

• 賬號的失效日期，該賬號什么時候失效。

注意，有些第三方信息是不能保存的，如用戶的賬號密碼、信用卡的CV號等。為了避免賬戶信息被爬庫或者數據庫信息意外泄露，一般還需要對敏感字段，如密碼等，進行加密保存，甚至保存到另外的表中。更進一步，為了避免賬戶信息被意外修改，還可以增加一個校驗字段，在寫入數據時設置該字段，在讀取數據時做校驗，一旦發(fā)現數據有問題，則關閉該賬號。

交易模型

交易記錄，交易流水，賬戶流水，交易臺賬，這三個容易混淆的概念，從數據上來說，卻并不復雜，它們的核心是交易流水，賬戶流水是從賬戶視角的交易流水。那對一筆交易，涉及到的方方面面內容很多，有哪些需要記錄的呢？考慮到交易記錄將被用于風控和信用分析，能收集到的信息是越全面越好。

• 流水號：每一筆交易的流水號都不一樣。需要根據業(yè)務情況詳細設計流水號。這個號往往也是對交易表做分表分庫的依據。

• 交易記錄創(chuàng)建時間；

• 交易記錄最后修改時間；

• 會計科目代碼

• 關聯的訂單號，由商戶提供；

• 訂單名稱、描述、關聯的地址等信息；

• 費用信息，包括：結算貨幣類型、原始費用、實際費用等；

• 交易主體信息，記錄主體ID、類型、名字、賬號、賬號類型、使用的IP地址、手機號、平臺、通知郵箱、當前位置等。這些信息雖然可以從主體表中獲取，但考慮主體表信息隨時會被修改，所以這里需要記錄詳細的各原始信息。

• 交易對手信息，記錄對手主體的ID，類型，名字，賬號，賬號類型，手機號，平臺，通知郵箱等。

• 交易渠道信息，記錄所使用的交易渠道的實體id，渠道賬戶，渠道執(zhí)行支付的時間、渠道側返回的訂單號等。如果有錯誤發(fā)生，還需要記錄從渠道接收到的錯誤信息和錯誤碼。

總結

如上內容，不管是賬戶還是交易，模型都很復雜。是否有必要記錄這么多信息，如何在交易中使用這些模型，請關注后續(xù)文章。

最后，也歡迎有問題的小伙伴加微信：yw5201a1溝通交流。

此外我們的官方網站也上線了，每日分享高質量的文章、原型素材和行業(yè)報告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點擊底部的閱讀原文直接查看，或者復制網址：www.dadaghp.com?打開。

更多干貨可關注微信公眾號：產品劉

想學習更多關于產品、職場、心理、認知等干貨，可長按右邊二維碼，關注我們。

··················END··················

RECOMMEND

推薦閱讀

B端可視化：圖表設計（2）

B端產品經理訓練營

產品經理學SQL

形成自己的知識體系

點擊“閱讀原文”

查看更多干貨

總結

以上是生活随笔為你收集整理的支付系统设计：支付系统的账户模型（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。