電子錢包/支付系統設計與分析

1、背景

因爲印度尼西亞的某衆籌機構須要開發一個站內電子錢包系統，因此基於此需求特地作了一番調研。

現在，一些平臺如：P2P理財、旅遊、遊戲等平臺都有自身的虛擬錢包系統，像這種站內的電子錢包系統應該如何設計呢？

首先讓咱們搞清楚什麼是站內電子錢包？和商業的支付系統有什麼區別？

站內電子錢包，就是用於站內支付的、非商業的、僅限於爲公司內部的業務提供支付支持的支付系統。

商業的支付系統，如：支付寶、微信支付、京東支付等，設計一套完整的商業支付系統是很是複雜的。

和商業的支付系統相比這類系統沒有開放平臺、開放接口、商戶註冊等。

因此站內電子錢包，本質上就是一套小型的支付系統。麻雀雖小五臟俱全！下面讓咱們看看主流的支付系統是如何設計的。

2、支付系統

2.1 什麼是支付系統

支付系統是鏈接消費者、商家（或平臺）和金融機構的橋樑，管理支付數據，調用第三方支付平臺接口，記錄支付信息（對應訂單號，支付金額等），金額對帳等功能，根據不一樣公司對於支付業務的定位不一樣大概有幾個階段：

第一階段：支付做爲一個（封閉）的、獨立的應用系統，爲各系統提供支付功能支持。通常來講，這個系統僅限於爲公司內部的業務提供支付支持。

第二階段：支付做爲一個開發的系統，爲公司內外部系統、各類業務提供支付服務，支付服務自己應該是和具體的業務解耦。

下面讓咱們瞭解下支付系統的總體架構體系，以及主要功能模塊。

2.2 主流支付系統總體架構

每一個公司根據其業務和公司發展的不一樣階段，所設計的支付系統也會有所不一樣。咱們先看看互聯網公司的一些典型的支付系統架構。

支付寶
先看看業內最強的支付寶系統，支付寶的支付系統總體架構設計

京東金融

來自京東支付平臺整體架構設計 。

去哪兒

來自去哪兒公司分享的支付產品架構

美團

來自美團的支付平臺規劃架構 。這是2015年的文檔。 2016年美團纔拿到支付牌照。

這些架構文檔所有來自互聯網公開資料。 對於架構是否真實反映實際系統狀況，須要你們自行判斷。

參考架構

通常來講，支付系統典型架構會包含以下模塊：

支付系統從架構上來講，分爲三層：

支撐層： 用來支持核心系統的基礎軟件包和基礎設施， 包括運維監控系統、日誌分析系統等。
核心層： 支付系統的核心模塊，內部又分爲兩個部分： 支付核心模塊以及支付服務模塊。
產品層： 經過核心層提供的服務組合起來，對最終用戶、商戶、運營管理人員提供的系統。

支付基礎設施

支撐系統是一個公司提供給支付系統運行的基礎設施。 主要包括以下子系統：

運維監控： 支付系統在下運行過程當中不可避免的會受到各類內部和外部的干擾，光纖被挖斷、黑客攻擊、數據庫被誤刪、上線系統中有bug等等，運維人員必須在第一時間內對這些意外事件做出響應，又不可以一天24小時盯着。這就須要一個運維監控系統來協助完成。
日誌分析： 日誌是支付系通通計分析、運維監控的重要依據。公司須要提供基礎設施來支持日誌統一收集和分析。
短信平臺： 短信在支付系統中有重要做用： 身份驗證、安全登陸、找回密碼、以及報警監控，都須要短信的支持。
安全機制： 安全是支付的生命線。 SSL、證書系統、防刷接口等，都是支付的必要設施。
統計報表： 支付數據的可視化展現，是公司進行決策的基礎。

遠程鏈接管理、分佈式計算、消息機制、全文檢索、文件傳輸、數據存儲、機器學習等，都是構建大型系統所必須的基礎軟件，這裏再也不一一詳細介紹。

2.3 支付系統的主要功能模塊

上面這些大廠的支付系統因爲已經商業化了，因此比較複雜。讓咱們簡化下一個支付系統的主要功能模塊有哪些。

應用管理: 同時支持公司多個業務系統對接。
商戶管理: 支持商戶入駐，商戶須要向平臺方提供相關的資料備案。
渠道管理: 支持微信、支付寶、銀聯、京東支付等多種渠道。
帳戶管理: 渠道帳戶管理，支持共享帳戶（我的商戶）及自有帳戶。
支付交易: 生成預支付訂單、提供退款服務。
對帳管理: 實現支付系統的交易數據與第三方支付渠道交易明細的自動覈對（一般T+1），確保交易數據的準確性和一致性。
清算管理: 計算收款交易中商戶的應收與支付系統收益。
結算管理: 根據清算結果，將資金劃撥至商戶對應的資金賬戶中。

Ok，到此咱們已經瞭解了一個支付系統的基本架構和主要模塊。那麼接下來如何從零開始設計一個支付系統呢？這個我以爲應該從帳戶體系開始。

一個好的支付系統，離不開一個好的支付帳戶體系，而一個支付帳戶的設計又依賴於帳戶體系，因此在開始設計支付系統以前應該先了解並梳理清楚帳戶體系。

3、帳戶體系

帳戶是用來記錄會計科目所反映的業務內容的工具，它根據會計科目來開設的。帳戶有多種維度的分類。 按照經濟內容來講，帳戶分爲資產類帳戶、負債類帳戶、全部者權益類帳戶、損益類帳戶、成本類帳戶和共同類帳戶。 按照會計週期內期末是否有餘額，也分爲實帳戶和虛帳戶。

既然支付帳戶的創建和和會計科目有關，那咱們首先來了解下這些會計科目。

3.1 資產類帳戶

用來反映資產增長、減小以及增減變更結果的帳戶。和支付系統相關的主要資產類帳戶有： 銀行存款、應收帳款、預付帳款、庫存商品、發出商品等。 資產增長登記在借方，減小登記在貸方，期末有餘額的話，通常出如今借方。 在一個會計期間，全部借方金額的累加爲「借方本期發生額」，全部貸方金額的累加爲「貸方本期發生額」。

資產帳戶的餘額=借方期初餘額+借方本期發生額-貸方本期發生額。

爲了跟蹤在每一個銀行的存款變動狀況， 須要對公司在各個銀行開通的收款帳戶設置對應的銀行存款帳戶、應收帳款帳戶。在小明購買會員卡的案例中，資產類帳戶包括：

1. 銀行存款，這是一個總帳帳戶，記錄電商公司在各個銀行的總存款。
2. 應收帳款，這是一個總帳帳戶，記錄在銀行的應收帳款，這是虛帳戶，期末無餘額。
3. 銀行存款-工行，這是一個明細帳戶，對應在工行的對公帳戶的存款變化；
4. 應收帳款-工行，這是一個明細帳戶，記錄在工行的收款狀況，這是虛帳戶，期末無餘額。

3.2 負債類帳戶

負債類帳戶也是實帳戶，記帳規則跟資產類相反，負債增長記爲貸，負債減小記爲借，期末若有餘額，通常在貸方，代表期末有債務實有額，負債類帳戶的餘額計算：

貸方期末餘額=貸方期初餘額+貸方本期發生額-借方本期發生額。

從支付系統的角度， 電商公司的自有帳戶，包括針對我的的帳戶和針對商戶的帳戶，通常放在負債類帳戶下，此外，應付帳款、預收帳款、應交稅費等，也是負債類帳戶。

3.3 全部者權益類帳戶

全部者權益類帳戶用來反映全部者權益增長、減小和變更結果的帳戶， 記帳規則跟負債類帳戶一致：全部者權益增長記爲貸，減小記爲借。和支付系統有關的所權帳戶包括 本年利潤、利潤分配等帳戶。 企業取得的收入最終會使得全部者權益增長，所以收入類帳戶的記帳方法跟全部者權益一致：增長記爲貸，減小或者轉銷記爲借，一般該帳戶期末無餘額（由於期末收入都會轉爲全部者權益，如未分配利潤等），屬於虛帳戶。

3.4 損益類帳戶

損益類帳戶分爲收入類和費用類帳戶。

收入類帳戶指各類收入、補貼、投資收益，如主營業務收入、其餘業務收入和營業外收入等，增長記爲貸，減小記爲借。

企業在平常經營活動中會發生各類各樣的耗費，這些耗費在會計學上稱爲成本費用，它們是收入的抵減項目，在抵銷收入以前，能夠視爲一種資產，所以成本費用類帳戶的記帳規則跟資產類同樣：增長記爲借，減小或者轉銷記爲貸。費用類帳戶包括：主營業務成本、其餘業務成本、營銷費用等。

按照企業會計制度的規定，損益類帳戶的科目餘額，應該結轉入利潤分配科目，期末餘額爲零，爲虛帳戶。

在本案例中，損益類帳戶包括：

1. 主營業務收入，這是總分類帳戶。
2. 主營業務收入-會員卡，針對會員卡業務的收入。
3. 營銷費用，這是總分類帳戶。
4. 營銷費用-優惠券，用來跟蹤優惠券相關的支出。
5. 渠道費用，這是總分類帳戶。
6. 渠道費用-工行： 用來跟蹤在工行的渠道費用支出。

3.5 成本類帳戶

有成本覈算的企業須要設立的帳戶，包括生產成本、勞務成本等，本文暫不涉及。

3.6 共同類帳戶

這是反映特殊經濟業務的帳戶， 本文暫不涉及。

3.7 帳戶體系

Ok, 科普了帳戶體系，那麼接下來須要考慮如何設計支付帳戶了。

4、E-Wallet 系統設計

4.1 準備工做

開通備付金帳戶

對於支付平臺來講，首先應在銀行設立一個或多個帳戶，用於歸集客戶或商戶的備付金（粗俗地能夠理解爲，客戶/商戶充值、支付、交易等待結算的資金）

其次，對於首次申請開戶的用戶，支付平臺爲每一個用戶（基於用戶身份證）開通一個惟一的主帳戶，和一個餘額帳戶（子帳戶），主帳戶下能夠添加多個子帳戶。

以支付寶爲例，一個身份證能夠認證6個支付寶帳戶，除其中1個主帳戶外，其餘5個都是子帳戶。

爲何須要有備付金帳戶？

若是用戶錢包裏的錢都存放到企業對公帳戶，那麼這部分錢是企業的收益呢？仍是用戶的存款呢？根本分不清楚。企業會將用戶的存款挪爲他用，這樣用戶的資金沒發監管，風險極大。

備付金管理辦法的核心是什麼？

核心就是三種帳戶，分別爲存管帳戶、收付帳戶、匯繳帳戶。

存管帳戶就是大老婆，每家支付公司只能有在一家銀行開立存管帳戶。你選擇了工商銀行，就不能選擇華夏銀行。存管帳戶裏的錢能夠跨行劃款、同行劃款、用起來和普通的對公帳戶徹底如出一轍，不受限制。但通常存管帳戶只能開一個，也有的支付公司，會選擇在同一個銀行不一樣地區的分行之間開帳戶。

收付帳戶就是姨太太，每家支付公司能夠在每一家銀行都開立一個收付帳戶，但收付帳戶不能跨行劃款，除非收款帳戶是存管帳戶。收付帳戶只能同行劃款，A支付公司能夠在工行開一個收付帳戶、在農行也開一個收付帳戶，但一旦在農行上海分行開一個帳戶，就不能在農行深圳分行再開收付帳戶了。

匯繳帳戶就是一晚上情的情人，隨便在哪家銀行隨便開幾個，可是這個帳戶日終清零，只能把這個帳戶裏的錢天天歸集到本行收付帳戶或是跨行歸集到存管帳戶，好可憐。有的人問，那匯繳帳戶有啥用？好比某個支付公司和某家分行合做了一個網上收單業務，那麼這個匯繳帳戶就是這家銀行天天把收單的錢結給這個支付公司的帳戶。

備付金帳戶之間頭寸是如何調撥的？

存管帳戶、收付帳戶、匯繳帳戶之間的錢是如何調撥的？

首先明確的一點，這個錢不會走銀聯的系統的，這事情和銀聯沒有啥關係。那麼匯繳帳戶到收付帳戶，就是經過每家銀行的行內轉帳進行調撥。匯繳帳戶、收付帳戶到存管帳戶，就是經過人行的大小額系統、跨行清算系統（俗稱超級網銀）或是同城系統進行調撥。

固然咱們說的系統，都是背後的系統，實際上前端的產品就是各家銀行的企業網銀、銀企直聯，甚至極端點，你去櫃檯把這個錢完成調撥都沒問題。

每家銀行如今陸續的都上了備付金管理系統，這個系統對接了每家支付公司，讓銀行可以掌握支付公司在本身銀行開設的全部備付金帳戶的每日餘額和資金調撥明細，而且作到匯繳帳戶能每日清零，控制收付帳戶、匯繳帳戶的跨行轉帳權限，而且每日能生成報表報送給人行。

這些措施都上了的話，基本能夠杜絕支付公司捲款跑人的問題了。

4.2 支付帳戶

先來解釋下什麼是支付帳戶？

支付帳戶是指支付機構根據客戶的真實意願爲其開立的，用於記錄預付交易資金餘額、客戶憑以發起支付指令、反映交易明細信息的電子薄記。（摘自《非銀行支付機構網絡支付業務管理辦法》） 例如咱們熟悉的支付寶餘額帳戶、微信錢包帳戶。

還有另外一個容易混淆的概念--用戶帳號。用戶帳號是用戶在支付機構的惟一識別編碼，通常是用戶登錄時使用的帳號，例如你的支付寶帳號。

同一個用戶帳號下，能夠有多個不一樣用途的支付帳戶，即1 ：N的關係。例如餘額帳戶、儲值卡帳戶。

4.3 三戶模型

實際上不一樣公司對底層帳戶體系的搭建依託於自己的場景及帳號基礎服務等，但大致上都是圍繞三戶模型作的設計。

三戶體系架構

客戶：爲天然人或法人，分爲我的、企業、商戶等，不依託於第三方企業屬性；須要一些具備法律效應的證件去佐證客戶是真實存在的，所以須要有身份證、護照、營業執照等做爲證實。互聯網2C和2B的業務會有針對客戶的實名認證、資質審覈等以便作客戶管理。一個天然人可能會有多個帳號，如一我的同時有微信、支付寶或京東帳號；也可能會有多個帳戶，如一我的有多張銀行卡、白條或小金庫帳戶。

用戶：爲帳號層面的屬性，依託於第三方企業屬性。如小明是用戶，須要知足註冊/登陸體系條件，註冊爲用戶，登陸密碼、暱稱、帳號等級、聯繫方式等都是基於帳號層面的管理。一個帳號下能夠有多個帳戶；同時用戶層面會有基本信息，如實名信息等。

帳戶：通常是對資金信息的管理，如資金餘額、資金帳。對於金融科技而言，通常都是虛擬帳戶管理而非真實的資金（真實資金通常都經過銀行帳戶管理）。帳戶系統跟帳務系統掛鉤，有單式記帳法和複式記帳法，通常會結合交易訂單管理及相關場景（信貸仍是儲蓄等）。

支付平臺爲了方便管理不一樣場景的資金或不一樣客戶的資金，會有主帳戶、子帳戶之分，這樣也有利於不一樣子業務的靈活開展。支付平臺一邊連着用戶，一邊連着銀行，爲了方便歸集管理資金，支付平臺不會爲用戶一一對應的設計銀行帳戶，而是在銀行設立一個總帳戶管理不一樣場景的用戶資金。

因須要嚴格的記帳及對帳邏輯，因此要有虛擬資金賬管理及結算系統管理。不一樣支付平臺採用的方式不同，有的採用資金池模式（基於總虛擬帳戶管理），有的採用虛擬帳戶模式。

4.4 支付帳戶體系設計

能夠說支付帳戶體系的設計是整個支付系統中最重要的一塊，由於它是整個系統的基石。

4.4.1 支付系統數據結構

Ok，瞭解了三戶模型，如今咱們須要根據三戶模型構建帳戶結構了。

支付帳戶結構圖

根據此結構關係，下面先給出總體的、關鍵的數據結構設計。

帳戶相關表結構

交易相關表結構

以上基本是最核心的數據結構了，固然，不是所有的。

接下來須要梳理下我的、企業開戶、充值、支付的流程，以及結合上面的數據結構作一些講解。

4.4.2 開戶

每一個用戶必須開通支付帳戶，開通支付帳戶必須進行實名認證。帳戶按照全部權能夠區分爲我的帳戶、商戶/企業帳戶、內部支付帳戶。

我的帳戶：是面向我的用戶開設的電子帳戶。
企業帳戶：是面向企業、機構等開設的帳戶。
內部帳戶：是平臺爲自身業務開展的需求而爲本身設立的帳戶。

除此以外，支付系統還能夠根據業務須要設置各類不一樣的帳戶類型。

因爲咱們是開發一個內部使用的電子錢包，將來有可能會對外提供支付服務。因此在設計上我儘可能兼容之後的業務。

開戶會設計到如下4張表

客戶實體：是徹底獨立的我的、企業身份信息，是須要認證的。

客戶帳號：支付系統相對於整個平臺來講，是做爲獨立的基礎服務系統存在的，因此會有自身的獨立帳號體系，而業務平臺業務須要，平臺業務的passport系統帳號，能夠和支付系統帳號綁定。另外，客戶帳號ID，能夠看做是主帳號。

客戶實體-客戶帳號關係：是1:N的關係。

客戶賬戶：是客戶帳號下的資金帳戶，能夠是有多個帳戶。特別注意的是，要事先約定好帳戶ID的規則。好比頭三位用來表示帳戶類型，後幾位用來表示帳戶編號等。務必保證根據帳號號可以快速肯定帳戶類型，而且保證帳戶號是不重複的。

客戶帳號-客戶帳戶關係：是1:N的關係。

在支付帳戶體系中，以客戶爲惟一要素，關聯不一樣的帳戶。 客戶有惟一的用戶 ID，餘額帳戶、理財帳戶，每一個帳戶有各自的帳戶 ID。一個用戶 ID 關聯多個帳戶 ID。

支付帳戶體系內的全部涉及客戶的資金，本質上是屬於客戶，而不屬於開發帳戶體系的互聯網公司。第三方支付機構的帳戶系統設計和帳戶真實資金的管理，要求每一種帳戶體系，支付機構都會在銀行開設一個備付金帳戶，由銀行來管理備付金帳戶的資金。備付金帳戶的資金是這個帳戶體系的所有資金，帳戶體系內每一個實體（如：收款商戶、充值用戶）所對應的資金金額，由第三方支付機構內部系統進行記錄和管理。

4.4.3 設置

用戶對帳戶的設置

• 資金密碼（用於提現和支付）
• 申請註銷帳戶

平臺對帳戶的設置

• 是否容許充值；
• 是否容許提現；
• 是否容許透支；
• 是否激活；
• 是否註銷；

4.4.4 綁卡簽約

爲何要求用戶綁卡？這和快捷支付有關。

快捷支付指用戶在電商網站上執行支付時，不須要輸入卡信息，僅根據短信或者其餘的驗證方式確認身份後，就能夠執行扣款的支付方式。 這是目前電商網站採用的主要支付方式。 在快捷支付中，用戶首次支付，須要提供卡的信息，以後就能夠憑短信驗證碼，甚至不須要密碼，也能夠執行扣款。

接口概述

通常來講，快捷支付須要提供以下接口：

1. 簽約， 也叫「綁卡簽約」、「開通交易」等，指用戶在商戶網站上開通快捷支付的功能，他須要將銀行卡相關信息提供給電商。
2. 解約， 也叫「解綁卡」， 指用戶取消在該網站上的快捷支付功能。通常也會刪除該用戶在該網站上的相關的銀行卡信息。
3. 扣款， 也叫「支付」， 指用戶使用簽約的卡來執行一筆扣款。
4. 退款， 針對已經扣款成功的交易執行退款操做，通常同時也會把用戶權益或者對應的訂單撤銷。並非全部訂單均可以執行退款。
5. 查單, 查詢某次交易的處理狀態。
6. 簽約查詢， 即檢查某個用戶是否已經開通了簽約功能。

咱們以支付寶綁卡爲例，通常支付機構對用戶進行實名後，用戶只能綁定本身的銀行卡，這主要從安全角度考慮。

1 .輸入卡號

用戶輸入卡號，系統對卡號進行初步驗證。驗證是基於卡bin和LUHN算法。固然，有些系統提供了OCR功能，便可經過掃描方式獲取卡號信息。通常來講，你能夠經過卡bin知道哪一個銀行，由於每一個銀行都有本身的卡號規則，你能夠經過這些規則知道是哪一個銀行

2 得到銀行卡信息

第一次綁定須要卡的信息。借記卡須要卡號，用戶的真實姓名和身份證，全部的都是同樣的。信用卡是複雜的。一些渠道驗證信用卡還須要提供CV碼和信用卡有效期。

3 .驗證預留手機號

這裏有一個四要素驗證的概念。因爲實名制，全部銀行卡都是實名，銀行能夠覈實姓名、身份證號碼、銀行卡號碼和電話號碼。若是驗證經過，就會發一條短信到你的手機。
注意：

1. 關於預留手機號。咱們都知道，銀行預留的手機號碼一般都是辦卡時候留的。幾年後，許多人換了手機號，忘記了去銀行更改手機號。所以，許多銀行就不驗證電話號碼。
2. 關於短信驗證碼，電話號碼有時候都是沒必要要的，短信可能就不會發送。那麼銀行不發，支付機構就能夠本身發；
3. 重複綁卡問題。若是系統支持多個賬戶，那麼一我的必然會被綁定到多個賬戶。有些渠道支持重複綁卡，有些渠道不支持；

4 進行綁定
用戶輸入短信驗證碼並確認綁卡。支付機構就會將用戶的銀行卡信息和短信驗證碼組合發送給銀行進行簽約操做。在銀行成功簽約後，它將把簽約號碼返還給商戶。這種處理邏輯是在支付渠道方面引入的。銀行將返回如下結果:

1. 簽約成功：這意味着能夠創建簽約關係。下次就可經過簽約號來進行扣款操做。
2. 重複簽約：按照業務考慮是否支持重複簽約。 通常針對一個銀行卡僅保留一個簽約關係。
3. 簽約失敗：會提示具體失敗緣由。

4.5 充值

以用戶在第三方支付平臺（支付寶）用銀行卡給本身虛擬帳戶在線充值爲例，爲簡化流程，均以最理想狀況進行說明：

1. 用戶在第三方支付平臺執行充值操做。
2. 平臺根據用戶充值指令，跳轉到銀行網關進行支付。
3. 用戶支付成功後，銀行會實時從用戶的銀行帳戶上執行扣款操做（資金轉移到第三方支付平臺在銀行的存管帳戶）。
4. 銀行網關通知支付平臺用戶支付成功（成功扣款）。
5. 支付平臺在本身帳戶體系中給對應用戶虛擬帳戶增長對應資金。
6. 平臺通知用戶充值成功。

銀行和支付平臺而後按照約定的結算週期（例如T+1）進行對帳、清結算等操做，將用戶充值的資金結算給支付平臺在銀行設立的帳戶（備付金帳戶，平臺在銀行開設一個實體對公帳戶）。

以上只是簡化的充值流程，其中在第三步通常銀行只扣劃用戶款項，待到日終纔會將款項劃轉到支付寶備付金帳戶，第五步通常也不會增長支付寶備付金帳戶，而是先經過中間帳戶，如充值待清算帳戶，等到日終銀行頭寸和對帳文件下發時，經過對帳邏輯進行處理，若涉及到異常流程，會更復雜些。

從簡化的流程圖裏仍是能夠看出支付平臺只處理虛擬資金，實資金仍在銀行體系內。

從帳戶關係也能夠看出，實資金變更從我的銀行卡劃轉到了支付平臺的銀行帳戶，虛資金是支付平臺爲每一個註冊用戶創建的虛擬帳戶，與用戶的銀行卡能夠說沒有直接關係；說的再直白些，用戶充值的款項都劃轉到支付平臺在銀行開立的大帳戶，業務主體爲「某支付平臺」，而後支付平臺在系統內爲每一個用戶創建臺帳。

上面的充值，若是綁定了銀行卡，充值會很方便。爲何要求用戶綁卡？這和快捷支付有關。綁卡是將用戶卡信息提供給電商，之後電商就用這個信息去銀行完成支付。綁卡其實是一個受權，讓用戶容許商家自動從他的帳戶上扣除資金。因此綁卡也叫簽約，用戶和銀行，商家的三方簽定的支付合約。

4.6 使用E-Wallet支付

當開戶及充值完成後，接下來就是使用E-Wallet做爲支付渠道了支付了。

Ok, 下面是一個常見的電子錢包支付流程。

做爲支付系統，這個過程一共分兩步：收單和支付。

4.6.1 收單

用戶在業務平臺上提交支付訂單後，支付系統收到用戶的訂單支付請求並驗證請求後，並記錄下來。

一般狀況下，根據用戶使用的終端是h5仍是app應用，支付系統會返回二維碼或者deeplink鏈接。

不過若是是內部錢包支付，收單和支付能夠同時進行，可是爲了之後的擴展性，流程和結構仍是要分兩步。

具體參見上面的「統一收單」表。

4.6.2 支付

這裏須要同步和異步處理收單表裏的訂單，處理完以後須要事務寫入支付記錄和帳戶帳單流水。

這裏以支付寶的支付流程爲例說一下：

整個支付流程就是這五大塊之間的交互，具體的實現上圖也給的很清晰了，下面對圖中重要的步驟簡單的介紹：

• 添加購物車，生成待支付訂單，產生惟一訂單號
• 請求商戶服務端（本身的後臺），在後臺對訂單信息進行簽名操做，這裏應用爲了安全考慮，會把似鑰放在服務端，客戶端只要報訂單號傳給服務端，具體簽名在後臺進行。
• 服務端把簽名好的訂單信息返回給客戶端
• 調用支付接口，把簽名好的訂單信息，經過調用支付寶API，發送給支付寶客戶端SDK
• 支付寶客戶端發起向支付寶服務端發起支付請求
• 支付寶客戶端輸入支付密碼。完成支付
• 返回同步結果給支付寶客戶端
• 支付寶客戶端將接口返回支付結果給咱們的商戶端口，9000支付成功
• 同時也將支付結果發送給了商戶服務端。驗籤，解析支付結果。將客戶端與服務端的支付信息進行比對，確保訂單支付正確無誤
• 確認訂單無誤以後，返回最終支付結果給商戶端
• 客戶端將訂單支付完成信息在界面顯示，告知用戶支付完成

4.7 API 列表

既然支付帳戶已經開通，那麼做爲一種支付渠道，天然能夠用於各類場景的消費。做爲支付渠道，就須要提供相應的SDK，用於消費場景的支付流程開發。

此列表包含支付平臺電子錢包系統所涉及的幾乎全部接口，參考支付寶：

接口英文名	接口中文名
alipay.trade.page.pay	統一收單下單並支付頁面接口
alipay.trade.refund	統一收單交易退款接口
alipay.trade.fastpay.refund.query	統一收單交易退款查詢接口
alipay.trade.query	統一收單線下交易查詢接口
alipay.trade.close	統一收單交易關閉接口
alipay.data.dataservice.bill.downloadurl.query	查詢對帳單下載地址

參考

https://zhuanlan.zhihu.com/p/58624171

http://doc.cocolian.cn/essay/account/2017/02/03/clearing-account/

https://zhuanlan.zhihu.com/p/31198490

https://zhuanlan.zhihu.com/p/55592943

https://juejin.im/post/5c2345c0518825235a0554bb

https://zhuanlan.zhihu.com/p/33897440

https://kuaibao.qq.com/s/20181026G0D0WV00?refer=spider

https://www.banana.ch/doc/zh-hans/node/3826