錢包和紅包是什么大家都了解的叭！但是對于紅包、錢包產(chǎn)品設(shè)計的架構(gòu)和流程了解嗎？下面是筆者對于紅包和錢包的相關(guān)內(nèi)容做一個分析整理，大家一起往下看，多多了解吧！

掌握了理論知識以后，應用于實踐是對理論考察的最佳手段，本章以紅包和錢包設(shè)計為實際案例，了解支付中架構(gòu)和邏輯在設(shè)計中的應用。

一、紅包設(shè)計

發(fā)紅包，領(lǐng)紅包，普通紅包，拼手氣紅包，在用戶使用層面大家都不陌生，因為經(jīng)常會用到紅包這個功能，但紅包底層的支付流程及算法規(guī)則、涉及的支撐系統(tǒng)都有哪些，估計很多人并不知道，本小節(jié)就分析一下“紅包”背后的秘密，掌握如何設(shè)計一套紅包體系。

1. 紅包概述

紅包對于用戶來說是一種娛樂手段、生活工具，對于企業(yè)來說是一種營銷手段，大家最熟悉的是經(jīng)常使用的微信紅包，像釘釘、脈脈等很多應用內(nèi)也都有紅包模塊。

紅包實質(zhì)上是用戶賬戶之間的“轉(zhuǎn)賬”能力；一個用戶的賬戶扣一筆錢，拆分后轉(zhuǎn)給多個賬戶；至于每個賬戶轉(zhuǎn)多少金額，就是紅包金額的算法，普通紅包簡單，平均總金額就行；拼手氣紅包稍微麻煩，既要保證紅包最低金額，又要保證金額隨機，已經(jīng)領(lǐng)過的不能再領(lǐng)，過期的紅包不能再領(lǐng)且要退回發(fā)紅包的賬戶，如圖1所示。

圖1 紅包發(fā)放的賬戶處理

常見的紅包類型按照發(fā)放者類型可以分為個人對個人和企業(yè)對個人，按照領(lǐng)紅包對象可以分為指定單個對象或者不指定多個多像，也就是群發(fā)紅包，按照紅包的金額又可以分為固定金額的紅包也就是普通紅包或者不固定金額的拼手氣紅包。

紅包體系涉及到的相關(guān)系統(tǒng)包括前端的應用、訂單、賬戶、營銷、運營等，其中：

• 前端應用：用戶發(fā)放領(lǐng)取的前端展示頁，收銀臺等；
• 訂單系統(tǒng)：紅包的支付訂單，用戶領(lǐng)取后的轉(zhuǎn)賬訂單；
• 賬戶系統(tǒng)：金額查詢，紅包余額的轉(zhuǎn)出轉(zhuǎn)入；
• 營銷系統(tǒng)：紅包規(guī)則創(chuàng)建，查詢，比如發(fā)了多少個，什么類型的紅包等；
• 運營系統(tǒng)：查看管理紅包發(fā)放和領(lǐng)取記錄。

2. 架構(gòu)和流程

紅包的功能結(jié)構(gòu)如圖2所示，主要包括紅包的分類，領(lǐng)取模式，紅包的規(guī)則，紅包的支付方式等模塊組成。

圖2 紅包功能腦圖

指定用戶的一對一發(fā)放場景，是指在一對一聊天場景，發(fā)紅包給朋友，相當于指定了這個用戶領(lǐng)取紅包，整個發(fā)放和領(lǐng)取流程如圖3所示。

圖3 指定用戶發(fā)紅包流程

• 發(fā)送用戶1的狀態(tài)必須為已實名；
• 指定用戶，前端需傳輸用戶2的userid
• 余額支付：用戶1使用余額支付時，用戶2未領(lǐng)取前，發(fā)送金額凍結(jié)；
• 綁卡支付：用戶1使用銀行卡支付時，支付金額先充值到1的資金賬戶中并凍結(jié)；
• 領(lǐng)?。河脩?確認領(lǐng)取后，解凍1資金后通過轉(zhuǎn)賬，入賬至2的資金賬戶中；
• 退回：用戶2到期未領(lǐng)取，發(fā)送金額解凍后，遵循原路退回原則，退回用戶1；
• 用戶1撤銷發(fā)送：只要用戶2未領(lǐng)取，均可解凍資金并退回資金。

不指定用戶發(fā)放紅包可以發(fā)放一個，也可以發(fā)放多個，由設(shè)置的紅包數(shù)量決定，如圖4所示。

圖4 不指定用戶紅包發(fā)放流程

對其中比較重要的字段進行說明：

• 發(fā)送用戶：1；
• 接收用戶：n(n=2,3,4…)；
• 發(fā)送紅包數(shù)：K；
• 發(fā)送總金額：M；
• 整個流程圖中的幾個關(guān)鍵點說明如下：
• 發(fā)送用戶1的狀態(tài)必須為已實名；
• 接收用戶n的狀態(tài)在領(lǐng)取時不需要為已實名；
• 從設(shè)置的紅包數(shù)/可領(lǐng)取人數(shù)K確認，是對單用戶還是多用戶場景；
• 資金凍結(jié)成功后，按照隨機規(guī)則直接創(chuàng)建K個子紅包。
• 用戶1使用余額支付時，只要有用戶未領(lǐng)取，剩余發(fā)送金額都保持凍結(jié)態(tài)；
• 用戶1使用銀行卡支付時，支付金額會先充值到1的資金賬戶中，并凍結(jié)該資金。

二、錢包設(shè)計

錢包錢包，就是裝錢的包，這個解釋應該是最精準的了。但是誰說錢包只能裝錢呢，裝身份證行不行，裝名片可不可以，裝某人的照片是不是可行？一個不裝錢的包還叫錢包么？本小節(jié)將解析用戶電子錢包的設(shè)計思路和方法。

1. 錢包概述

電子錢包是利用互聯(lián)網(wǎng)技術(shù)手段實現(xiàn)數(shù)字貨幣線上管理的數(shù)字化錢包，如微信錢包，如圖5所示，支付寶錢包，以及剛剛推出的數(shù)字人民幣錢包。

圖5 微信錢包截圖

電子錢包，無非要滿足2個條件，第一個是數(shù)字化的，第二點是用于管錢的，既然管錢就必然有“多少錢的余額”“怎么變化的流水”。

錢包最核心的一個用途就是管錢，另一個非常重要的用途是用于支付交易。因為無論在銀行還是在三方支付機構(gòu)開通的錢包更多的目的是用于結(jié)算或者支付，所以暫且認為錢包的核心目的是支付，如圖6所示。

圖6 錢包用途

從另一個角度來看，錢包是一個金融工具，管理電子貨幣，并向用戶提供充值、提現(xiàn)、轉(zhuǎn)賬、支付的交易能力。

2. 錢包的底層能力

錢包的底層能力其實就是賬戶；錢包的用戶端無非就是個殼，如圖7所示，應用層就是用戶使用的錢包，底層是賬戶的基礎(chǔ)能力，包括注冊、綁卡、轉(zhuǎn)賬等交易能力。

圖7 錢包的底層能力

常見的賬戶種類有央行的清算賬戶、銀行結(jié)算賬戶、支付機構(gòu)的支付賬戶、企業(yè)自建的虛擬賬戶等，其中，銀行結(jié)算賬戶主要分個人結(jié)算賬戶和企業(yè)結(jié)算賬戶；支付機構(gòu)也可以為用戶開具賬戶，稱之為支付賬戶；還有一種賬戶就是平臺自建賬戶，當然這類賬戶就是虛擬記賬，并不存有真實的資金，圍繞自建賬戶也可以構(gòu)建一個用戶錢包體系。

錢包的本質(zhì)是賬戶，賬戶的本質(zhì)是資金，所以根據(jù)賬戶里的資金屬性來看，錢包可以分為銀行錢包、支付機構(gòu)錢包、企業(yè)錢包、數(shù)字人民幣錢包等，其中由銀行基于銀行結(jié)算賬戶體系構(gòu)建的錢包應用是銀行錢包，比如各個銀行APP里的錢包；由支付機構(gòu)基于支付賬戶體系提供錢包解決方案構(gòu)建的錢包應用或者API經(jīng)過商戶封裝后的錢包應用是支付機構(gòu)錢包。

3. 錢包的架構(gòu)和流程

錢包的產(chǎn)品架構(gòu)可以分為三層，如圖8所示，其中，應用層主要為用戶端錢包，為用戶提供錢包的基礎(chǔ)功能，例如余額管理和流水查看，銀行卡綁定，實名認證等；支持系統(tǒng)為內(nèi)部系統(tǒng)，為錢包提供各項服務(wù)能力，例如會員服務(wù)、銀行卡服務(wù)、支付系統(tǒng)、賬戶系統(tǒng)等；最底層為外部的服務(wù)通道，例如支付通道、實名認證通道等。因此，可以說錢包是通過集成眾多底層能力實現(xiàn)的。

圖8 錢包產(chǎn)品架構(gòu)

錢包得業(yè)務(wù)流程可以基于不同的服務(wù)去分析，如圖9所示，錢包的注冊開戶流程、實名認證流程、余額流水查詢流程、充值提現(xiàn)流程等，每一個流程都會涉及到內(nèi)部相關(guān)的幾個系統(tǒng)，例如注冊開戶會涉及到用戶中心，為開戶提供用戶基礎(chǔ)信息。

圖9 錢包涉及到的系統(tǒng)體系

用戶進入錢包應用以后首先需要先完成賬號注冊、賬戶開戶、實名認證、設(shè)置密碼，然后可以使用錢包相關(guān)的功能，例如支付相關(guān)功能、銀行卡管理的相關(guān)功能、信息查詢等，如圖10所示。

圖10 錢包的使用流程

4. 錢包的功能

錢包的核心功能主要包括注冊、實名認證、綁卡、充值提現(xiàn)、轉(zhuǎn)賬、支付等，下面分別做一個詳細的解讀。

注冊：用戶先注冊為平臺用戶獲得唯一身份ID，然后申請開通錢包功能，該錢包可以是平臺自建，也可以是接入的三方的錢包，如果是接入的三方錢包，那么按照三方要求傳送用戶信息申請開戶，如圖11所示。

圖 11 錢包注冊及開戶

實名認證，一般實名認證主要是2種，一個是通過三方支付的綁卡多要素鑒權(quán)實現(xiàn)認證；另一個是手機號，主要通過運營商的手機實名認證。

綁卡/解綁，綁卡鑒權(quán)有現(xiàn)成的服務(wù)接口，接入即可，四要素的，三要素的，五要素的；如果是自建錢包只是為了驗證銀行卡可不可用，那么使用三要素即可；如果是接入的三方支付公司的錢包服務(wù)，那么根據(jù)開的是幾類支付賬戶進行鑒權(quán)認證選擇即可。

充值/提現(xiàn)，有了錢包就需要充錢，錢包不用了就需要把錢提出來；如果是自建錢包沒接入任何一方的話，使用微信支付寶進行充值即可，提現(xiàn)的話接入三方的付款通道即可，將資金付給用戶；如果是接入了三方錢包的話，使用三方提供的交易能力即可。

轉(zhuǎn)賬，主要是指用戶之間的錢包賬戶之間進行資金轉(zhuǎn)移，一般不支持跨商戶平臺轉(zhuǎn)賬；有個人對個人轉(zhuǎn)賬，也有商戶對個人轉(zhuǎn)賬，如圖12所示。

圖12 錢包之間的轉(zhuǎn)賬

余額支付，就是使用錢包進行下單支付，比如我們在購買商品用微信支付時支付方式可以選擇微信錢包；平臺也可以使用自己的虛擬賬戶體系構(gòu)建余額支付能力。

前端設(shè)計首先也考慮的就是錢包的基礎(chǔ)能力，例如余額管理、充值提現(xiàn)、流水的查看等，完成基礎(chǔ)能力建設(shè)以后，可以基于實際需要構(gòu)建更多的其他能力，比如信貸、欠款償還等，如圖13所示是一款簡單的B2B采購商城的商戶錢包，主要用于商戶采購下單支付。

圖13 錢包頁面

錢包的運營后臺、賬戶系統(tǒng)、支付交易等獨立系統(tǒng)單元這里就不介紹了，在其他章節(jié)有詳細解析，錢包的開通情況記錄可以通過一個后臺列表實現(xiàn)，如圖12-14所示，可以看到用戶錢包的基礎(chǔ)信息，錢包類型、認證狀態(tài)、賬戶類別等。

圖14 用戶錢包列表

三、一提多戶

這是一個非常實用的案例，對綜合素養(yǎng)要求較高，案例涉及面比較廣。很多公司會存在多條業(yè)務(wù)，有些企業(yè)每個業(yè)務(wù)線都會有一個錢包業(yè)務(wù)，這樣就造成了商家端錢包分散，一個商家在每個業(yè)務(wù)線都有一個錢包，分別管理余額、提現(xiàn)、綁卡、支付密碼等，資金管理體驗比較差，如圖15所示。

圖15 多個業(yè)務(wù)線多個錢包

此種情況可能就有了統(tǒng)一各業(yè)務(wù)線錢包的訴求，統(tǒng)一以后商家僅需管理一個錢包，綁定一張卡，設(shè)置一個密碼，一次完成多賬戶的同時提現(xiàn)，提高資金管理效率，提升商家的結(jié)算體驗，如圖12-5所示。

圖12-15 統(tǒng)一錢包結(jié)構(gòu)

此種情況下，錢包的提現(xiàn)業(yè)務(wù)有2個核心問題要解決：

第一個核心問題是“判斷有多少可提”：需要有系統(tǒng)告訴錢包當前的可提金額是多少，以及這些余額分別來自哪些賬戶，每個賬戶各有多少。

第二個核心問題是“怎么發(fā)起提現(xiàn)”：當商家輸入提現(xiàn)金額時，需要有系統(tǒng)告知錢包，本筆提現(xiàn)要從哪些賬戶出，每個賬戶出多少，所以需要一個分配提現(xiàn)金額的策略。

1. 解決幾個關(guān)鍵問題

以上統(tǒng)一錢包的訴求，可以轉(zhuǎn)換為“錢包的余額查詢、提現(xiàn)預加工的支持”這樣兩個更明確的訴求，其中有幾個關(guān)鍵點要想明白。

可提余額并不一定等于賬戶可用余額的總和，因為有提現(xiàn)手續(xù)費，導致個別賬戶可能不滿足最低提現(xiàn)金額要求，所以說可提金額不一定等于可用余額的總和。比如一個賬戶里只有2毛錢，而提現(xiàn)手續(xù)費要5毛，就無法完成提現(xiàn)，如表1所示。

示例中主體001的可提余額計算結(jié)果=11.5元，因為賬戶3中的0.8元不滿足最低提現(xiàn)要求，因此不可提，實際可提金額=1.5+10.00=11.5元，因此，錢包可用余額12.3元，可提金額=11.5元。

表1 賬戶的最小可提金額示例：

可提余額不代表用戶要提的金額，因為用戶可能只選擇提取其中的一部分，所以要計算這部分金額應該如何分配到賬戶中，除非讓用戶選擇那個賬戶提多少，但這樣就失去了統(tǒng)一錢包的意義了，那么如圖16所示，就需要設(shè)定一個策略，在用戶屬于一個提現(xiàn)金額時，計算出這么多金額分別從每個賬戶扣多少。

圖16 提現(xiàn)金額分配至賬戶的策略

制定一個提現(xiàn)金額的分配策略，有很多種方法，可以做得簡單一些，比如設(shè)定一個固定的順序，以“ABC”的順序進行扣款，如圖17所示，先扣A賬戶，再扣B賬戶，最后扣C賬戶。

圖17 固定的提現(xiàn)扣款順序

也可以做成綜合策略，比如如果一個賬戶就夠了，那就只出一個賬戶，如果多個賬戶才能夠，那就按照順序扣款等，不過這樣的算法成本會增高，可能帶來的效果并不明顯，所以，我們就選擇第一種方法，按照固定順序扣款，這樣增加一個提現(xiàn)順序的配置，如表2所示。

表2 提現(xiàn)順序配置

如例：可提金額是11.5，此時用戶僅提現(xiàn)“8元”，根據(jù)提現(xiàn)扣款順序的設(shè)定，如表2所示，實際扣款如表最后一列：賬戶1扣1.5，賬戶2扣6.5。用戶每輸入一次提現(xiàn)金額，就執(zhí)行一次預計算，并實時反饋給用戶錢包。

2. 計算賬戶余額

因為錢包底層是多個賬戶，每個賬戶都有總余額，可用余額，可提金額等信息，那么當錢包要查詢賬戶余額信息時，對底層賬戶余額進行加工匯總的任務(wù)誰來完成？也就是通過執(zhí)行以下三個公式：

1. 錢包N總余額=賬戶A余額+賬戶B余額+賬戶C余額；
2. 錢包N可用余額=賬戶A可用余額+賬戶B可用余額+賬戶C可用余額；
3. 錢包N可提余額=賬戶A可提余額+賬戶B可提余額+賬戶C可提余額。

無外乎有3種處理方法，分別是錢包進行處理、賬戶系統(tǒng)進行處理或者一個中間層來處理，下面分別分析每一種實現(xiàn)方式的利弊。

錢包進行處理：這種方法有個問題，耦合嚴重，錢包受底層賬戶的賬戶設(shè)置、制度政策的影響較大，如圖18所示，錢包查詢到各賬戶余額然后進行匯總加和得出賬戶各類總余額。

圖18 錢包處理賬戶余額的計算

賬戶系統(tǒng)進行處理：這會讓賬戶系統(tǒng)承載更多的計算任務(wù)，不利于資金管理的純粹性，需要過渡承接業(yè)務(wù)的變化帶來的迭代壓力，如圖19所示，賬戶系統(tǒng)對各賬戶余額進行匯總加和得出總賬戶余額，然后將結(jié)果告知錢包。

圖19 賬戶處理賬戶余額的計算

清算系統(tǒng)進行處理：對于清算系統(tǒng)來說，進行大量的計算和處理是其最擅長的職能，交給它去完成，上下游都釋放了壓力，各自去做自己最純粹的事情，如圖20所示，清算系統(tǒng)獲得各賬戶的余額以后進行匯總加和得出總余額，然后提供給錢包。

圖20 清算系統(tǒng)處理賬戶余額的計算

其中，箭頭代表余額數(shù)據(jù)的查詢，123代表明細數(shù)據(jù)，N代表處理過的數(shù)據(jù)，清算系統(tǒng)查詢到123明細數(shù)據(jù)，輸出給錢包的是匯總數(shù)據(jù)N，并且包含了明細數(shù)據(jù)123。為了釋放賬戶的壓力，讓賬戶專心做自己資金管理的職能，將一些處理事務(wù)交給清結(jié)算系統(tǒng)去做，包括對賬戶余額的加工處理，以及提現(xiàn)余額的分配計算等，如圖21所示，增加一個錢包的統(tǒng)一處理服務(wù)層，完成統(tǒng)一錢包的預處理服務(wù)。

圖21 錢包統(tǒng)一處理層

四、流程與架構(gòu)

因為錢包側(cè)用戶只發(fā)起一筆提現(xiàn)請求，但是，最終要扣多個賬戶，出多筆資金，那么，這個從一提到多出的處理由誰來實現(xiàn)，也就是一筆提現(xiàn)變多筆提現(xiàn)。

因為是提現(xiàn)業(yè)務(wù)，所以我們選擇讓提現(xiàn)處理系統(tǒng)來完成對提現(xiàn)的拆分，也就是錢包發(fā)起提現(xiàn)時，會請求清算系統(tǒng)對提現(xiàn)金額進行分配計算，然后得到計算結(jié)果，并封裝成提現(xiàn)數(shù)據(jù)提交給提現(xiàn)系統(tǒng)。錢包提交的提現(xiàn)請求數(shù)據(jù)結(jié)構(gòu)為：提現(xiàn)請求 {提現(xiàn)請求ID,提現(xiàn)金額X}；提現(xiàn)明細{子提現(xiàn)請求1，子提現(xiàn)請求2}。

提現(xiàn)系統(tǒng)將提現(xiàn)請求拆分成兩筆提現(xiàn)：提現(xiàn)1，提現(xiàn)2，分別請求清算系統(tǒng)進行提現(xiàn)扣款處理，整個提現(xiàn)處理的業(yè)務(wù)流程如圖22所示，清算中心分別進行可提金額的計算、提現(xiàn)金額的預計算處理，而提現(xiàn)系統(tǒng)進行提現(xiàn)的拆單處理。

圖22 統(tǒng)一提現(xiàn)處理流程

基于上述的方案，將整個統(tǒng)一錢包的提現(xiàn)業(yè)務(wù)流繪制成架構(gòu)圖，看看整個業(yè)務(wù)所涉及的范圍，以及每個環(huán)節(jié)要承載的任務(wù)，如圖23所示。

圖23 統(tǒng)一錢包提現(xiàn)處理架構(gòu)圖

通過上圖，就可以看清楚做這件事所涉及到的環(huán)節(jié)，以及要實現(xiàn)的能力有哪些，誰來做什么，上面的案例可以培養(yǎng)對整個錢包、賬戶、提現(xiàn)業(yè)務(wù)的認識，同樣，也是一個可以拿來即用的產(chǎn)品方案。