賬戶體系是支付系統的基礎，它的設計直接影響整個系統的特性。這裡探討如何針對電子商務系統的支付賬戶體系設計。我們從一些基本概念開始入手，瞭解怎麼建模。

支付賬戶和登入賬號

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

賬戶的設計需求

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

1. 交易的需求，比如檢查賬戶是否被鎖定、餘額是否足夠、是否有效等。
2. 記賬的需求，按照公司會計需求記錄賬戶上的所有行為，包括支出、充值、轉賬等。
3. 對賬的需求，包括和支付渠道、商戶、個人的對賬需求，核對交易和賬戶餘額是否正確。
4. 風控的需求，如反洗錢、反欺詐等，都需要依賴於賬戶體系來提供核心資料。本文暫不分析這個內容，將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析
5. 信用的需求，對使用者、資產、商戶等主體進行信用評估時，也需要依賴賬戶體系來提供的核心資料。本文也暫不分析這內容，將在《信用與支付》一文中分析。

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

交易與賬戶

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

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

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

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

記賬與賬戶

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

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

內部賬戶和外部賬戶

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

那問題來了，什麼時候需要建立賬戶，比如優惠券，需要賬戶嗎？ 一次消費的儲值卡和可以充值的儲值卡，需要建立賬戶嗎？這裡先埋個雷，後續介紹支付和記賬時，給出答案。

收款賬戶和收單賬戶

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

賬戶建模

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

實體模型

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

• 使用者ID，一般直接對映到登入賬戶的ID；
• 是否允許執行支付；
• 支付密碼；
• 用於設定或者重置支付密碼的手機號；
• 使用者設定或者重置支付密碼的郵箱；
• 使用者的安全等級，根據業務需要來設定。

賬戶模型

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

• 虛擬幣賬號：使用者和使用奇點奇豆的商戶都需要建立虛擬幣賬戶。
• 代扣賬號： 用來支援訂閱型別的定期代扣；
• 零錢賬號：即電商的內部賬號，使用者、商戶、清算單位需要建立零錢賬戶
• 第三方支付賬號：使用者在第三方支付機構建立的賬戶。
• 銀行卡賬號：使用者的銀行卡資訊，每個卡對應一個賬戶。
• 結算賬號：用來支援和第三方支付公司、銀行進行結算用。 第三方支付需要為每個商戶號建立結算賬號；銀行需要為借記卡、貸記卡分別建立結算賬號（有必要嗎？銀行卡直連時使用）。
• 代扣代繳賬戶：用來支援代扣稅款業務。

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

• 賬戶號，或稱為賬戶ID，一般是系統自動生成。特別注意的是，要事先約定好賬戶ID的規則。比如頭三位用來表示賬戶型別，後幾位用來表示賬戶編號等。務必保證根據賬號號能夠快速確定賬戶型別，並且保證賬戶號是不重複的。
• 賬戶名稱，一般是由使用者自己設定的，顯示用。
• 賬戶使用的貨幣型別，注意雖然一張銀行卡可以支援多個幣種，實際在內部，還是針對每個幣種建立獨立的子賬戶。 涉及到多幣種的賬戶，也可以採用類似的建模方案。
• 會計科目程式碼，一般是一級會計科目的程式碼。

賬戶控制相關：

• 是否允許充值；
• 是否允許提現；
• 是否允許透支；
• 是否允許支付；
• 是否允許轉賬進入；
• 是否允許轉賬轉出；
• 是否有安全保障；
• 是否啟用；
• 是否凍結。

資金相關：

• 當前賬戶餘額：等於可用餘額+凍結餘額；
• 當前賬戶可用餘額；
• 當前賬戶凍結的餘額。凍結餘額指在賬戶上暫不能使用的額度。在支付的時候，往往是先凍結，商品出庫後， 再實際執行扣款。

銀行卡、第三方支付資訊：

• 第三方實體的ID；
• 第三方賬號，如銀行卡號或者在第三方支付的open_id等；
• 第三方的app_id；
• 賬號的失效日期，該賬號什麼時候失效。

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

交易模型

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

• 流水號：每一筆交易的流水號都不一樣。需要根據業務情況詳細設計流水號。這個號往往也是對交易表做分表分庫的依據。
• 交易記錄建立時間；
• 交易記錄最後修改時間；
• 會計科目程式碼
• 關聯的訂單號，由商戶提供；
• 訂單名稱、描述、關聯的地址等資訊；
• 費用資訊，包括： 結算貨幣型別、原始費用、實際費用等；
• 交易主體資訊，記錄主體ID、型別、名字、賬號、賬號型別、使用的IP地址、手機號、平臺、通知郵箱、當前位置等。 這些資訊雖然可以從主體表中獲取，但考慮主體表資訊隨時會被修改，所以這裡需要記錄詳細的各原始資訊。
• 交易對手資訊，記錄對手主體的ID，型別，名字，賬號，賬號型別，手機號，平臺，通知郵箱等。
• 交易渠道資訊，記錄所使用的交易渠道的實體id，渠道賬戶，渠道執行支付的時間、渠道側返回的訂單號等。如果有錯誤發生，還需要記錄從渠道接收到的錯誤資訊和錯誤碼。

總結

如上內容，不管是賬戶還是交易，模型都很複雜。是否有必要記錄這麼多資訊，如何在交易中使用這些模型，請關注後續文章。