支付系統設計:支付系統的賬戶模型(一)
賬戶體系是支付系統的基礎,它的設計直接影響整個系統的特性。這里探討如何針對電子商務系統的支付賬戶體系設計。我們從一些基本概念開始入手,了解怎么建模。
支付賬戶和登錄賬號
賬戶體系設計首先要區分兩個概念,支付賬戶和登錄賬號。 這是兩個不同業務領域的概念:支付賬戶指用戶在支付系統中用于交易的資金所有者權益的憑證;登錄賬號 指用戶在系統中的登錄的憑證和個人信息。 一個用戶可以有多個登錄賬戶,一個登錄賬戶可以有多個支付賬戶,比如零錢賬戶,儲值卡賬戶等。 一般來說,支付賬戶不會在多個登錄賬戶之間共用。如果沒有特殊說明,下文中的賬戶,都默認指支付賬戶。
賬戶的設計需求
在支付系統中,賬戶的設置,主要是從如下幾個方面來考慮:
- 交易的需求,比如檢查賬戶是否被鎖定、余額是否足夠、是否有效等。
- 記賬的需求,按照公司會計需求記錄賬戶上的所有行為,包括支出、充值、轉賬等。
- 對賬的需求,包括和支付渠道、商戶、個人的對賬需求,核對交易和賬戶余額是否正確。
- 風控的需求,如反洗錢、反欺詐等,都需要依賴于賬戶體系來提供核心數據。本文暫不分析這個內容,將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析
- 信用的需求,對用戶、資產、商戶等主體進行信用評估時,也需要依賴賬戶體系來提供的核心數據。本文也暫不分析這內容,將在《信用與支付》一文中分析。
這五個需求,按照其設計的優先級,也是從支付、記賬、對賬、風控來進行。 支付系統根據其發展所處的階段,逐步將新增需求納入設計中。
交易與賬戶
賬戶設置,一般是從交易開始的。 交易的實現必須有賬戶的支持,賬戶是交易的基本構成元素。 從支付系統的角度,交易中涉及到的資金流是資金從一個賬戶流向另一個賬戶。 發起交易的一方,被稱之為交易主體,他可以是個人,也可以是一個機構。
資金從該主體所擁有的賬戶中流出。 而接收交易的一方,被稱為交易對手,他也可以是個人,或者機構。 和第三方支付或者金融機構的交易不同,電商系統中,交易還會涉及到渠道。
由于電商系統本身并無清結算的資質,所有資金從交易主體到交易對手的賬戶的流動,在大部分情況下,并沒有經過電商系統,而是由電商系統調用支付渠道提供的接口,由它來完成真正的支付過程。 當然,渠道也不是活雷鋒,在這過程中,渠道要收取費用。
所以,在電商系統中,一次交易會涉及到三個賬戶: 交易主體賬戶、交易對手賬戶以及支付渠道賬戶。 如何在這三個賬戶中完成一次交易,我們將在后續的《交易和記賬》一文中詳細分析。
記賬與賬戶
公司的會計需要對每一筆交易都要做詳細的記錄,即記賬。 公司每天都產生大量的交易行為,為了便于管理和統計,一個簡單的方法是對交易進行分類,比如食品、帶寬、辦公用品等等。 這個分類,按照公司的規模和業務復雜度,可以有一級,二級,三級或者更多級的結構,這被稱之為會計科目。 記賬時,除了交易明細,還需要在每個級別上對交易額進行匯總。
一般來說,一級科目上匯總稱為總帳科目,而詳細記錄稱為明細科目。 在電商系統中,由于涉及到的參與方較多,記賬也相對復雜,但基本方法也是類似的。 電商的參與者可以分為商戶、買家和渠道,對這三類參與者,都需要分別建立總帳賬戶和明細賬戶。
內部賬戶和外部賬戶
當用戶使用銀行卡來支付時,電商支付系統需要和銀行對接,從用戶銀行卡所代表的賬戶上扣除資金。對接了銀行,第三方支付等機構的電商支付系統,它需要連接到用戶在這些機構的賬戶來執行扣款或者充值操作,這些賬戶或稱為外部賬戶。對外部賬戶,支付系統只能記錄賬戶在本系統的明細以及累計消費額,無法得知賬戶真正余額。 不少電商在玩零錢的概念,也就是讓用戶充值到零錢,使用的時候就直接從零錢中扣除。這就需要零錢賬號。這是電商系統中自己設立的賬號,所以也叫內部賬號,可以知道賬號的全部消費明細和余額。 當然,除了零錢賬號,也可以有儲值卡賬號,信用賬號等。
那問題來了,什么時候需要建立賬戶,比如優惠券,需要賬戶嗎? 一次消費的儲值卡和可以充值的儲值卡,需要建立賬戶嗎?這里先埋個雷,后續介紹支付和記賬時,給出答案。
收款賬戶和收單賬戶
當電商要對接銀行時,往往都會被要求開設一個收款賬戶。用戶通過這個銀行來支付時,錢就被轉到這個賬戶上。 對第三方支付也是一樣。收款賬戶是開設在銀行或者第三方支付這邊的, 即渠道側。 一般來說,渠道每天都可以提供這個賬戶的交易流水供電商對賬用。 這樣在電商這邊,渠道就成為一個收單機構。 所以在電商這邊,建立這個收款賬戶對應的對賬用的收單賬號,用來記錄通過這個渠道進行的各項交易流水。
賬戶建模
說了這么多,目的是為了對賬戶建模。 賬戶模型是和公司業務密切相關的,公司不同規模,發展的不同階段需要不同的模型。 賬戶建模本身包括三大核心模型:實體模型、賬戶模型和交易模型。 從交易模型中可以衍生出針對各個角色的賬戶流水,即明細模型,用于支持對賬。
實體模型
實體模型和用戶、商戶模型有重疊的地方,這里專門針對支付而設置的各個實體屬性。 一般來說,支付相關的實體模型需要包括如下的屬性:
- 用戶ID,一般直接映射到登錄賬戶的ID;
- 是否允許執行支付;
- 支付密碼;
- 用于設置或者重置支付密碼的手機號;
- 用戶設置或者重置支付密碼的郵箱;
- 用戶的安全等級,根據業務需要來設置。
賬戶模型
根據業務需要,可以設置多種賬戶,如支付賬戶、預付卡賬戶、代扣賬戶、零錢賬戶、結算賬戶等。 從類別上來說,這里的賬戶,一般指總賬賬戶。一般來說電商系統中涉及的賬戶類型有:
- 虛擬幣賬號:用戶和使用奇點奇豆的商戶都需要建立虛擬幣賬戶。
- 代扣賬號: 用來支持訂閱類型的定期代扣;
- 零錢賬號:即電商的內部賬號,用戶、商戶、清算單位需要建立零錢賬戶
- 第三方支付賬號:用戶在第三方支付機構建立的賬戶。
- 銀行卡賬號:用戶的銀行卡信息,每個卡對應一個賬戶。
- 結算賬號:用來支持和第三方支付公司、銀行進行結算用。 第三方支付需要為每個商戶號建立結算賬號;銀行需要為借記卡、貸記卡分別建立結算賬號(有必要嗎?銀行卡直連時使用)。
- 代扣代繳賬戶:用來支持代扣稅款業務。
對這些賬戶,需要設置如下屬性: 基本屬性,包括:
- 賬戶號,或稱為賬戶ID,一般是系統自動生成。特別注意的是,要事先約定好賬戶ID的規則。比如頭三位用來表示賬戶類型,后幾位用來表示賬戶編號等。務必保證根據賬號號能夠快速確定賬戶類型,并且保證賬戶號是不重復的。
- 賬戶名稱,一般是由用戶自己設置的,顯示用。
- 賬戶使用的貨幣類型,注意雖然一張銀行卡可以支持多個幣種,實際在內部,還是針對每個幣種建立獨立的子賬戶。 涉及到多幣種的賬戶,也可以采用類似的建模方案。
- 會計科目代碼,一般是一級會計科目的代碼。
賬戶控制相關:
- 是否允許充值;
- 是否允許提現;
- 是否允許透支;
- 是否允許支付;
- 是否允許轉賬進入;
- 是否允許轉賬轉出;
- 是否有安全保障;
- 是否激活;
- 是否凍結。
資金相關:
- 當前賬戶余額:等于可用余額+凍結余額;
- 當前賬戶可用余額;
- 當前賬戶凍結的余額。凍結余額指在賬戶上暫不能使用的額度。在支付的時候,往往是先凍結,商品出庫后, 再實際執行扣款。
銀行卡、第三方支付信息:
- 第三方實體的ID;
- 第三方賬號,如銀行卡號或者在第三方支付的open_id等;
- 第三方的app_id;
- 賬號的失效日期,該賬號什么時候失效。
注意,有些第三方信息是不能保存的,如用戶的賬號密碼、信用卡的CV號等。 為了避免賬戶信息被爬庫或者數據庫信息意外泄露,一般還需要對敏感字段,如密碼等,進行加密保存,甚至保存到另外的表中。 更進一步,為了避免賬戶信息被意外修改,還可以增加一個校驗字段,在寫入數據時設置該字段,在讀取數據時做校驗,一旦發現數據有問題,則關閉該賬號。
交易模型
交易記錄,交易流水,賬戶流水,交易臺賬,這三個容易混淆的概念,從數據上來說,卻并不復雜,它們的核心是交易流水,賬戶流水是從賬戶視角的交易流水。那對一筆交易,涉及到的方方面面內容很多,有哪些需要記錄的呢?考慮到交易記錄將被用于風控和信用分析,能收集到的信息是越全面越好。
- 流水號:每一筆交易的流水號都不一樣。需要根據業務情況詳細設計流水號。這個號往往也是對交易表做分表分庫的依據。
- 交易記錄創建時間;
- 交易記錄最后修改時間;
- 會計科目代碼
- 關聯的訂單號,由商戶提供;
- 訂單名稱、描述、關聯的地址等信息;
- 費用信息,包括: 結算貨幣類型、原始費用、實際費用等;
- 交易主體信息,記錄主體ID、類型、名字、賬號、賬號類型、使用的IP地址、手機號、平臺、通知郵箱、當前位置等。 這些信息雖然可以從主體表中獲取,但考慮主體表信息隨時會被修改,所以這里需要記錄詳細的各原始信息。
- 交易對手信息,記錄對手主體的ID,類型,名字,賬號,賬號類型,手機號,平臺,通知郵箱等。
- 交易渠道信息,記錄所使用的交易渠道的實體id,渠道賬戶,渠道執行支付的時間、渠道側返回的訂單號等。如果有錯誤發生,還需要記錄從渠道接收到的錯誤信息和錯誤碼。
總結
如上內容,不管是賬戶還是交易,模型都很復雜。是否有必要記錄這么多信息,如何在交易中使用這些模型,請關注后續文章。
作者:鳳凰牌老熊,程序員 & 架構師,來自中科大的本科,研究生在軟件所學習。先后在中科輔龍、三星(中國)研究院和國內一些大型的互聯網公司呆過。在中科輔龍公司負責電子政務內容管理系統建設,負責研發龍馭系列產品的研發,這款產品最終實施到2000多個電子政務網站上,期間也參與了一些支付反洗錢以及支付系統的建設。之后在三星中國研究院,負責自然語言處理(NLP)以及智能家居相關項目。智能家居項目在2014CES消費電子展上作為三星重點項目推介。2014年開始加入愛奇藝公司,負責數據倉庫和支付系統的建設。
本文由@鳳凰牌老熊(微信公眾號:shamphone) 原創發布于人人都是產品經理 。未經許可,禁止轉載。
作者您好, 看了您這篇文章收益匪淺。其中我有個地方有疑惑, 交易主體和交易對手, 是否和交易中資金流轉的方向有關系?比如資金流出方是交易主體,資金流入方是交易對手? 其實我認為是交易主體是指交易的發起方, 而交易的另一方就是交易對手了, 和資金流向沒有關系。但我另外一個同事看了你這篇文章, 他的理解卻是跟資金流轉的方向有關。
一個賬戶系統同時承擔用戶零錢交易和財務清結算功能會不會不太好? 因為零錢賬戶需要在支付時使用實效性要求較高,財務清結算可以是異步轉賬記賬(偏向于財務會計領域復式記賬)。博主建議分開還是可以合并成一套? 一套的話,使用零錢支付時,復式記賬會計分錄該怎么走?還是同一套系統針對實時交易(支付/退款)這種采用另外一套記賬方法。
一個賬戶系統的定義是什么,一個是支付賬戶,一個是結算賬戶,這樣應該不會有影響吧。
個人經驗,平臺類業務的賬戶規劃還是需要兩套,一套是結算賬戶,用來快速處理資金和零錢的相關業務操作,一套是財務賬戶,用來進行異步財務相關的賬戶處理;
用來進行異步財務相關的賬務處理。不是賬戶處理,敲錯字了。
您好,請問一下公司的電商平臺允許用戶在非登錄狀態下輸入手機號即可購買并支付,支付成功后,系統會自動以手機號創建一個用戶賬號并提供一個默認密碼完成用戶的注冊工作,這樣在系統上會存在安全隱患嗎?如果會,風險有多大?
首先不明白為什么會這樣設計,首先很多支付渠道是不需要用戶輸入手機號碼的。另外即使如果有手機號碼了,如果這個手機號碼和已有的用戶手機號碼沖突了又該如何?
“這樣在電商這邊,渠道就成為一個收單機構。 所以在電商這邊,建立這個收款賬戶對應的對賬用的收單賬號,用來記錄通過這個渠道進行的各項交易流水?!?br /> 請問這個收單賬號是指什么,不是指收款賬戶么。 賬號賬戶分不清楚
了解了,即開設一個賬號,綁定這個收款賬戶,就可以查這個賬戶在渠道側的流水
要是能補上關鍵的結構圖就更清楚了
?? 真是精彩
真是精彩
Thank you so much!!!
交易模型中是否要加個記錄交易狀態的字段? 比如說成功,失敗,凍結?
作為一個支付前端sdk的產品,后臺的東東了解甚少,學習了,謝謝少俠
同,希望可以進一步交流
謝謝樓主,分析的很好,我能說樓主也是賬戶賬號傻傻分不清楚,嘻嘻
樓主咨詢一下,像銀行,第三方支付,銀聯,在整個支付系統中資金渠道都有哪些?分別在什么情況下用起來呢?
純干貨,太實用了,謝謝樓主!
假設是用支付寶渠道的話
您好,請教您一個問題。對于做電商的平臺,想要做到自動退款,確認收貨后自動打款到商家賬戶。是不是需要支付寶為公司開設的中間賬號/公司支付寶賬號及買家支付寶賬號就可以打通了?謝謝!
是的。
講得非常好,分析很全面,值得學習。。。
膜拜樓主,寫的邏輯性超強,而且通俗易懂,期盼跟多好文。尤其是這種系列類的文章,太棒了。
樓主寫得太好了?。∮袀€問題想請教下:虛擬幣賬號是指實際發生消費時,商家直接接收該虛擬幣作為收入?還是說要兌換成相應現金再轉給商家?
商家先接受虛擬幣,如何結算需要和商家定協議。
寫的很全面 邏輯清晰 LZ好人
太實用啦,干貨滿滿!把支付這塊知識梳理得很清楚。剛剛做了一個支付系統,如果早看到這個就好了。有幾個問題,希望老師能回答一下:
1.為什么要設置多種賬戶模型?是因為每種的錢不一樣(有的是虛擬幣,有的是人民幣,有的是美金),每種的權限不一樣(有的自動扣減,有的需要用戶授權)嗎?
2.文中留下的問題優惠券需要設置賬戶嗎?一次性使用的儲值卡需要設計賬戶嗎?充值的儲值卡需要設置賬戶嗎?
3.交易記錄和交易流水有什么區別?交易臺賬是什么意思?
4.交易記錄在什么情況下會修改?提交訂單后商家修改運費或商品價格算嗎?
謝謝!
1. 賬戶模型在實現上可以統一成一個,也可以分開建模。 取決于其中差異性。在業務實體上是多個。
2. 優惠券可以不設置賬戶;一次消費的儲值卡也可以不設置賬戶,當做優惠券處理; 可以多次消費、充值的儲值卡,需要建模成賬戶;
3. 記錄、流水、臺賬,在會計上有不同含義,但對電商系統來說,無太大區別。
4. 交易記錄不是一次全寫入的,會分階段寫入。 修改運費和價格,需要更新交易記錄,但這字段和原始運費、價格,需要存儲在不同字段中。
懂了。太感謝啦!
1、我還想深入了解一步,什么時候能設置賬戶,什么時候不設置賬戶?
2、假如系統里面有積分,積分也可以用來抵扣貨款,那積分要設置賬戶嗎?
3、什么叫做支付屬性?
請樓主指點。
這里積分類似虛幣,需要賬戶。
老熊,方便留個微信不 , 有問題可以跟你討論一下。
關注下“鳳凰牌老熊”公眾號,在公眾號下留言即可。
這個支付還是需要研究一下的
流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!流程設計一直是弱項,學習啦!
流程設計一直是弱項,學習啦!
寫的好全面,適合我這種小白 ??