支付系統設計：支付系統的帳戶模型

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

支付帳戶和登錄帳號

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

帳戶的設計需求

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

交易的需求，比如檢查帳戶是否被鎖定、餘額是否足夠、是否有效等。記帳的需求，按照公司會計需求記錄帳戶上的所有行為，包括支出、充值、轉帳等。對帳的需求，包括和支付管道、商戶、個人的對帳需求，核對交易和帳戶餘額是否正確。風控的需求，如反洗錢、反欺詐等，都需要依賴於帳戶體系來提供核心數據。本文暫不分析這個內容，將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析信用的需求，對用戶、資產、商戶等主體進行信用評估時，也需要依賴帳戶體系來提供的核心數據。本文也暫不分析這內容，將在《信用與支付》一文中分析。這五個需求，按照其設計的優先級，也是從支付、記帳、對帳、風控來進行。 支付系統根據其發展所處的階段，逐步將新增需求納入設計中。

交易與帳戶

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

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

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

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

記帳與帳戶

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

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

內部帳戶和外部帳戶

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

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

收款帳戶和收單帳戶

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

帳戶建模

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

實體模型

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

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

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

虛擬幣帳號：用戶和使用奇點奇豆的商戶都需要建立虛擬幣帳戶。代扣帳號： 用來支持訂閱類型的定期代扣；零錢帳號：即電商的內部帳號，用戶、商戶、清算單位需要建立零錢帳戶第三方支付帳號：用戶在第三方支付機構建立的帳戶。金融卡帳號：用戶的金融卡信息，每個卡對應一個帳戶。結算帳號：用來支持和第三方支付公司、銀行進行結算用。 第三方支付需要為每個商戶號建立結算帳號；銀行需要為借記卡、貸記卡分別建立結算帳號（有必要嗎？金融卡直連時使用）。代扣代繳帳戶：用來支持代扣稅款業務。對這些帳戶，需要設置如下屬性： 基本屬性，包括：

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

是否允許充值；是否允許提現；是否允許透支；是否允許支付；是否允許轉帳進入；是否允許轉帳轉出；是否有安全保障；是否激活；是否凍結。資金相關：

當前帳戶餘額：等於可用餘額+凍結餘額；當前帳戶可用餘額；當前帳戶凍結的餘額。凍結餘額指在帳戶上暫不能使用的額度。在支付的時候，往往是先凍結，商品出庫後， 再實際執行扣款。金融卡、第三方支付信息：

第三方實體的ID；第三方帳號，如金融卡號或者在第三方支付的open_id等；第三方的app_id；帳號的失效日期，該帳號什麼時候失效。注意，有些第三方信息是不能保存的，如用戶的帳號密碼、信用卡的CV號等。 為了避免帳戶信息被爬庫或者數據庫信息意外泄露，一般還需要對敏感字段，如密碼等，進行加密保存，甚至保存到另外的表中。 更進一步，為了避免帳戶信息被意外修改，還可以增加一個校驗字段，在寫入數據時設置該字段，在讀取數據時做校驗，一旦發現數據有問題，則關閉該帳號。

交易模型

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

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

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

原文出處：http://www.woshipm.com/pd/459443.html

END