隨著互聯網的發展，錢包電子化已經成為了每個APP都必備的一大功能。那么在互聯網中，設計好一個電子錢包需要考慮什么？本文總結了8個支付“錢包”設計案例，希望對你有所啟發。

有些概念就是源于生活——“錢”“包”，一個裝錢的包。

什么是電子錢包，就是利用互聯網技術手段實現數字貨幣線上管理的虛擬錢包，像微信錢包，支付寶錢包，以及剛剛推出的數字人民幣錢包。

(資料圖片)

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

實際生活中我們的錢包能裝什么，為了方便需要可以放很多東西，例如：放身份證、照片、火車票、戒指等。

所以，錢包本質上是以管理貨幣為核心的“儲物”工具，只要放的下，有人愿意，就可以放，同樣適用于電子錢包。

我們看幾個錢包示例：京東錢包、美團錢包、滴滴錢包、知識星球錢包。

從這些案例中，不難發現，錢包可以抽象為一個資產管理工具，可以提供“存錢、借錢、花錢、結錢”的資金管理服務。

由此，一個錢包常具備以下功能：

要設計好一個電子錢包，往往需要思考清楚以下幾個問題：

（1）錢包的用途是什么

錢包的用途最核心的一個就是管錢，另一個非常重要的用途就是用于支付交易，其他作用在不同類型平臺側重不同。

在銀行還是三方支付機構的錢包更多的目的：用于資金管理、結算、支付。

在一些購物或者其他場景消費類平臺：錢包還承載著消費貸以及營銷的職能。

所以，錢包可以認為是一種“金融工具”，具備資金管理、信貸管理、理財管理、支付結算等職能。

（2）要做哪一類錢包

在設計錢包之前，要明白自己要設計哪一類錢包，而不同類型的錢包，設計方法以及要思考的核心點也會存在差別。

本質上，錢包是平臺為用戶提供的賬戶體系解決方案。

通過收集用戶信息，注冊，創建XX賬戶。然后根據用戶指令，完成賬戶實名，綁卡，充值，提現，還款，轉賬和支付等基礎賬戶操作，并集成貸款、理財、營銷入口等其他業務訴求。

進而我們可以根據底層賬戶的不同，對錢包進行分類。

銀行用戶錢包：由銀行基于銀行結算賬戶體系構建的錢包應用，比如各個銀行APP里的錢包。

支付機構用戶錢包：由支付機構基于支付賬戶體系提供錢包解決方案構建的錢包應用或者API經過商戶封裝后的錢包應用。

（3）錢包的整體架構怎么樣

在設計錢包之前要先站在整個業務視角，規劃好整個業務流程以及產品架構，以此就有了整個錢包體系的頂層設計，后面的每一個部分的設計就會非常容易。

我們說的錢包一般是個用戶產品，提供給終端用戶使用，所以，先想明白用戶會使用錢包干什么，常見的錢包一般是下面的使用流程。

那么，要提供這樣一個使用流程的錢包應用，需要建立怎么樣的業務體系，如下圖所示。

最后，再想清楚這樣的流程和業務架構下，如何設計錢包的產品架構，我們從錢包應用層、相關內部支持系統、依賴的外部服務三層來設計錢包的產品的架構，如下圖所示。

（4）錢包需要的交易類型包含哪些

錢包存在意義前面講了，要提供給用戶“管錢、貸款、結算、支付等”的服務，那么最終可以抽象出哪些交易能力要想明白，常見的交易類型有這樣幾種。

充值/提現/還款：是指錢包賬戶與同人銀行卡之間的轉賬，一般要求個人賬戶與個人銀行卡歸屬于同一個用戶實體（即同名，同身份證號）。

轉賬：指主要是指用戶之間的錢包賬戶之間進行資金轉移的過程。

余額支付：就是使用錢包進行下單支付，比如我們在微信購買東西時可以支付方式可以用微信錢包；平臺也可以使用自己的虛擬賬戶體系構建余額支付能力。

以上就是對錢包的認識，以及設計錢包前要想明白的問題，要考慮的設計方面。

下面我們就看幾個錢包的設計實例，以加深錢包的印象，看看在不同業務場景下的錢包都是怎么做的。

01 家政行業-勞動者錢包

想必大家對家政行業都不陌生，很多讀者都請過保潔或者月嫂育兒嫂，家政平臺就是撮合雇主和家政服務人員的平臺，并提供基礎的線上交易設施，以及對家政服務者收入的結算。

在這個過程中就需要為家政服務人員提供一個用于管理結算收入的錢包，錢包核心要實現的能力就是展示結算收入，提現結算收入，并且可以查看收入明細，綁定銀行卡等功能。

而這部分我計劃圍繞錢包介紹一個場景的需求如何實現。

背景是這樣的，公司存在多條業務（保姆、月嫂、保潔），因為歷史原因，造成商家端錢包分散，一個商家在每個業務線都有一個錢包，分別管理余額、提現、綁卡、支付密碼管理，資金管理體驗比較差。

需求要解決的問題就是對各業務線錢包進行統一，商家僅需管理一個錢包，綁定一張卡、設置一個密碼，一次完成多賬戶的同時提現，提高資金管理效率，提升商家結算體驗。

匯總之后，會存在一個核心的關系：前端余額是底層賬戶的匯總，即：

錢包余額=∑（保姆余額，月嫂余額，保潔余額）

通過錢包統一處理服務層，統一錢包的各項服務“余額查詢、明細查詢等”。

統一以后，錢包中只有一個余額，但要一筆提現，應該怎么處理，整體需要4個核心環節。

（1）計算可提余額

可提余額并不一定等于賬戶可用余額的總和，因為有提現手續費的存在，導致個別賬戶可能不滿足最低提現金額要求。

例如，如果提現手續費是0.5元，那么提現金額需要大于0.5元。

所以，可提余額應該等于每個賬戶的真正可提金額之和，排除那些不滿足最小提現金額要求的賬戶。

上表示例中主體001的可提余額計算結果=11.5元，因為賬戶3中的0.8元不滿足最低提現要求，所以不可提。

實際可提金額=1.5+10.00=11.5元，因此，錢包余額12.3元，但，可提金額=11.5元。

（2）提現預計算

可提余額不代表用戶要提的金額，因為他可能只提取了一部分，所以要計算這部分金額應該如何分配到賬戶；除非讓用戶選擇那個賬戶提多少，但這樣就失去了統一錢包的意義了。

既然是部分提現的金額分配，那就需要一個分配的策略；這里我們用簡單的排序分配方法。

如例：可提金額是11.5；此時用戶僅提現“8元”，該怎么處理？需要建立一個提現扣款順序，如表所示；順序代表扣款順序。

實際扣款如表最后一列；賬戶1扣1.5，賬戶2扣6.5。

用戶每輸入一次提現金額，就執行一次預計算，并實時反饋給用戶。

（3）提現拆單

對統一余額的提現，雖然用戶側是一筆，但是底層還是對應多個虛擬賬戶，多個出款賬戶；所以需要將一筆提現拆成多個提現單。

拆的依據：就是清算系統預計算返回的結果。

誰拆？

可以錢包拆，提交多筆提現請求，這樣的好處是提現系統不用改造；也可以提現系統拆，這樣提現系統需要進行拆單改造。

（4）提現扣款

賬戶扣款：提現系統根據拆好的提現單，請求賬戶系統進行賬戶扣款；扣款成功以后提交渠道進行出款。

（1）賬單有區別于賬戶余額流水

賬單是提供給商家對賬的全面的交易數據，便于商家對賬；賬戶流水僅是其賬戶余額變動明細，便于商家管理結算收入，可以看一下微信錢包的賬單以及零錢明細的區別在哪里。

賬單的底層邏輯是清算系統匯集、處理獲得的本月商家全部交易記錄。

02 外賣-騎手錢包

外賣場景很多人都熟悉，現在訂外賣是生活中非常高頻的事項。

外賣業務中配送是非常重要的一個環節，而配送離不開騎手，配送完以后騎手會拿到配送收入。

這個過程跟家政業務很像，都是O2O范疇，所以這兩個領域的支付人可以相互流通，非常高的匹配度。

既然業務非常相似，那么給騎手結算用的錢包也就非常相似了，下圖是美團的騎手錢包頁面。

其中結算余額、余額提現、賬戶明細、銀行卡管理、賬單管理都是非常通用的模塊。

可見，如果要設計一個結算用途的錢包，這些功能是少不了的。

而我們要介紹另一個特殊外賣場景的騎手錢包，就是國際外賣，像UBER、DIDIFOOD等。

國際外賣場景與國內整體業務有很多相似之處，但也會存在一些差異。

這些差異主要體現在：面臨復雜的政策環境，不同國家的支付基礎設施水平不同，勞動法不同，稅收政策不同，用戶的支付習慣不同等等，造成了在設計錢包時需要考慮這些因素。

比如：

在國外一些國家有小費文化，那么騎手的收入當中有一部分就是“小費”。

不同國家對騎手的稅收政策不同，有些國家不需要代扣代繳但需要申報，有些國家需要代扣代繳，那么在稅收的計算和賬務處理上就會存在差異，而這些差異也會體現在錢包中。

還有一個特別大的差異就是“現金支付”，國外一些國家的現金支付訂單特別多，甚至能夠達到70%比重，用戶下單時選擇現金支付，這時候就需要騎手幫其墊付餐費給到商戶，等餐送到以后，用戶再將餐費給到騎手，騎手還給平臺。

這個過程中就會出現騎手結算賬戶的“負值”，需要騎手進行充值償還這部分現金收款。

因此，錢包的設計要先梳理清楚錢包的應用環境，基于環境和業務訴求進行模塊的規劃和建設。

03 寵物電商平臺-用戶錢包

本部分主要介紹一個寵物B2B電商的錢包案例，該錢包的用戶主要用于消費支付使用，所以相比于前面的幾個結算用途的錢包，消費用途錢包主要核心就是“充值和余額支付”，而結算用途的錢包主要核心是“提現結算收入”。

從這一點上就可以看出來，不同用途的錢包，其設計核心存在差異。

互聯網寵物行業主要包含：寵物社交、寵物電商、寵物問診等模式。

而這個行業的供應鏈包括：品牌商、渠道商、代理商、電商平臺、寵物店/寵物醫院、個人消費者等主體，他們之間構成了如下的關系。

而其中的垂直寵物電商，鏈接上游代理商與寵物店和寵物醫院——平臺價值主要是提升行業撮合效率，主打正品；業務的難點是“地域性、品牌限價、線下客勤關系”等。

整個電商平臺依賴的最基礎的產品體系如圖所示：

那么在這樣的體系里，為什么要給用戶做一個消費下單的錢包呢？

可見，設計錢包要先搞清楚整個業務場景。

因為作為B2B批發平臺，大額交易較多，往往單筆支付在10萬甚至20萬上百萬的金額，因此傳統的支付渠道很難滿足這樣的額度需求。

當初設計的錢包的核心目的就是“預充值”突破支付限額。

又因為平臺為創業快跑階段，為了提高平臺的GMV，提供了充值返利的活動，因此充一筆資金會贈送一部分余額，上面就是錢包的主頁，非常簡潔，核心是充值功能，不支持提現，以及支付密碼的設置、消費明細。

余額支付就是預充值以后，使用平臺的賬戶余額進行支付。相比外部渠道，平臺自身的余額支付體驗更好，限額更容易控制，實現超大額支付。

這里會將底層賬戶模擬出成一條虛擬通道，與微信支付寶通級別進行建設。設計余額支付的支付流程，與微信支付寶在平臺內的處理保持一致。

04 在線租車平臺-錢包解析

隨著出游需求的高漲，大家對于用車的需求也就水漲船高，而租車由于其便捷、舒適和靈活性，成為越來越多年輕人和家庭出游的首選方式，比如目前火熱的租車自駕游。那大家試想一下，如果你去租車，第一步要做什么？那肯定是找一家靠譜的租車平臺。

要租車就涉及到交易，不管是對租車人還是對提供租車出行服務的租賃企業，支付和資金安全都是剛需。畢竟，租車是一件很嚴肅的事情，有一定的風險（感興趣的小伙伴可以網上搜搜），而租賃費也可能是一筆不菲的費用。

對于那些撮合租車人和租賃企業的租車平臺來說，比如專為租賃企業提供數字化解決方案的租車SaaS平臺，如何在自身合規的基礎上（如規避資金池和二清問題），為用戶（主要是租賃企業，即商戶）的交易和資金安全保駕護航，就尤為關鍵。

而對于租車SaaS平臺的商戶，核心訴求就是保障其資金安全和靈活調度，既要平臺為其算明白收支賬目，又要管理好錢。那錢要怎么管理，如何才能管理好呢？

對于沒有支付牌照的廣大租車SaaS平臺來說，主要是通過接入第三方支付的方式提供交易見證和資金擔保服務，而為了弱化第三方支付，平臺往往會采取自建錢包的方式，為商戶提供會員賬戶服務，其本質還是基于第三方支付賬戶封裝出來的錢包應用。

錢包的性質是一個虛擬電子賬戶（管理電子貨幣的金融工具），核心功能是管錢和支付交易，底層就是賬戶能力，比如認證綁卡、支付、提現等。

商戶開通錢包后，業務收入即時入賬錢包，資金流水有賬單核對，錢包余額實時可查，余額提現靈活高效，賬目和資金盡在掌握！

首先，梳理錢包的業務流程。

其次，設計錢包的產品架構。

（1）錢包賬戶設計

錢包底層是賬戶能力，那就必須得穩定可靠，輕便靈活，要充分考慮業務場景需求（比如考慮收支分離、營銷等）去設計賬戶體系。下圖是平臺與第三方支付合作共建的賬戶體系，在此基礎上平臺包裝錢包賬戶，采用一個錢包賬戶多個余額的模式，目的是滿足業務應收應付和實收實付分離的場景訴求。

（2）錢包主要功能分解

根據錢包業務流程，主要實現開戶、資金處理、銀行卡管理、信息查詢等主要功能。

（3）錢包資金流設計

根據費用類型記錄錢包入賬及資金變動過程。將業務的記賬請求通過入賬和凍結規則處理，進入賬戶系統并生成賬戶流水，然后更新錢包賬戶余額。

最后，輸出產品需求方案。

（1）錢包產品前端原型

前端即錢包的用戶端界面，面向商戶，主要實現錢包的開通、余額及賬單查詢，以及提現或充值操作等。在滿足基礎功能的同時，更多是體驗，比如如何讓開戶流程更簡單順暢，資金更快到賬，賬目清晰準確等。

下方是錢包開戶的流程：包括企業（平臺商戶）身份校驗（企業工商+法人實名認證）、銀行賬戶認證（支持對公賬戶、對私賬戶）。

下方是錢包余額和提現頁面：

下方是賬單列表和詳情頁面：

（2）錢包產品后端原型

后端即錢包的管理端界面，面向平臺，主要實現查詢錢包開通記錄、錢包流水和余額等。

下方是錢包賬戶列表：記錄所有商戶錢包的開通結果，包括賬戶的基本信息，所屬主體，錢包余額等內容，還可聯查賬戶流水明細。

下方是錢包流水列表：記錄所有商戶錢包的資金變動明細，包括對手賬戶、收支方向、金額、費用類型等基本信息。

錢包的出入賬原則是支付成功才入賬，扣賬成功才出款。比如用戶成功支付租金后，這筆費用會實時入賬商戶錢包，記錄為凍結余額，在交易雙方簽署合同且用戶提車后，才會將租金分賬給商戶，則這筆費用由凍結余額轉為可用余額，可用余額可提現。

注意：租車押金屬于擔保資金，不屬于商戶應收，所以支付成功不入賬商戶錢包。

05 旅游門店-錢包

旅游門店系統，由于過往業務發展快，為了配合業務發展，系統的錢包設計沒有區分各個交易場景，所有收入支出都很混亂，不利于門店對賬。原有的錢包設計可拓展性低，也無法在原有基礎上改造，因此需要重新設計開發一款錢包體系。

旅游門店系統的用戶是門店負責人或門店員工，主要用于門店日常支付訂單、門店日常規范管理（如支付員工工資等），該系統承擔用戶充值資金、支付訂單、凍結資金、支付員工工資及提現等功能。

為了解決門店對賬的痛點，我們做了2大點的設計：按資金用途給門店設計不同功能的錢包；根據各業務場景，結合上游訂單系統、下游財務結算系統，設計輸出一套錢包流程。

（1）錢包分類

資金錢包：用于門店訂單的支付，支持充值、提現。

利潤錢包：用于門店日常經營管理時的支出，如門店員工工資等，支持提現，不支持充值，僅支持門店正常的利潤流轉。

（2）錢包功能

根據業務場景來設計。門店加盟后，系統會為其開通錢包，開通后即可使用。

錢包開通：門店只需要簽約成功，即可開通錢包，因前置加盟時已做相關校驗，此時無需其他校驗。

日常使用：如上所述，門店日常使用細節劃分如下：

（1）錢包開通

若門店已簽約成功，正式開戶，自動開通門店錢包。

（2）錢包充值

如上所述，充值有3個場景。一個是客人直接支付賣價、一個是門店充值、一個是分公司管理人員調賬（因流程簡單，上圖并未畫出）

客人支付賣價：

客人去門店后，若決定在該門店下單，則會先行支付給門店賣價。客人可以通過微信、支付寶等方式進行掃碼支付，輸入價格后，系統調取銀聯，客人直接支付好后，會立即充值至門店的資金錢包。

門店發起充值：

門店的支付方式有多種，銀聯掃碼、POS刷卡、轉賬充值等。管理人員會在后臺配置每種支付方式是否需要審核，是否需要支付手續費，誰來支付手續費等。如轉賬充值，需要管理人員審核公司是否收到轉賬，若收到了，需要管理人員操作審核通過，方能將資金成功充值至門店的資金錢包。

管理人員調賬：

因為這個場景是管理人員直接操作，所以無需審核，操作成功后，會直接充值至門店的資金錢包。

（3）錢包扣款

資金錢包扣款也有多種場景，一個是門店支付賣價，一個是門店提現，一個是管理人員操作扣款。

門店支付賣價后，系統會將賣價部分從資金錢包扣下，并凍結，底價部分用于支付供應商，利潤部分保持凍結狀態，直至達到條件后解凍。

門店提現的操作，需要門店發起提現申請，由門店的管理人員去審核，管理人員審核通過后方可退款。需要注意的是，當門店提交申請時，此時也會產生資金凍結，這部分資金不可再用于其他用途。

管理人員操作扣款，僅是資金錢包扣款，并不會有其他系統動作。這種場景主要是門店人員線下與管理人員進行協調后，管理人員操作的。

錢包系統會需要承載錢包的各種信息，以及跟各種業務系統進行交互，交互時會有自己的場景出現，比如充值、支付、提款等。這些看似不大的場景，也需要根據底層的一些配置來判斷流程需要怎么走。

（1）門店端

門店端查看自己錢包的信息（包括資金錢包和利潤錢包），也可以在下方查看各個錢包的流水。

（2）管理端

管理后臺可以看到多家門店的錢包信息以及匯總數據。

錢包系統的設計需要結合收銀臺系統的設計，二者相互影響。更需結合業務場景，需要深入業務場景去調研，不可對業務說明的場景言聽計從，需要刨根問底，多問為什么，為什么有這樣的業務場景，為什么不可以有其他那樣，參考別人的做法，多思考別人是怎么做的。否則系統一旦上線后，出了結構性的問題，改起來十分復雜。

06 食堂錢包設計解析

食堂錢包（以下簡稱錢包）是企業為員工建的一個虛擬賬戶，員工可通過錢包在食堂消費。錢包支持企業為員工注冊、注銷錢包，打入餐費補貼。員工可通過線下方式向錢包充值、食堂消費、員工間轉賬、提現操作。以下主要從員工錢包側進行說明。

（1）錢包注冊、注銷

員工辦理入職手續后，人力資源將新入職員工的工號、姓名、手機號碼等基礎要素提供給錢包業務系統，開通員工錢包。

員工辦理完離職手續及將賬戶中的金額提取出來后，人力資源系統會調用錢包注銷能力，進行錢包注銷。

（2）錢包充值

入職初期或錢包沒錢，員工想使用食堂錢包進行消費，需聯系管理人員，線下通過現金、微信等方式支付充值金額給管理人員，管理人員通過錢包系統，為該員工進行充值。

入職后的每個月月初，ERP根據員工的出勤情況及補貼標準，計算出公司員工的補貼金額后，調用錢包系統的充值能力，為員工的補貼錢包充值。

（3）員工間轉賬

支持員工間的轉賬，但不同類型的錢，會轉到不同類型的錢包，比如充值進來的錢，轉賬時，也會進入收款方的充值錢包；補貼錢包中出來的錢，轉賬時，會進入收款方的補貼錢包。

（4）錢包提現

員工需要將錢包中的錢提出來時，若是充值進去的錢，可直接申請提現，通過銀企直聯的方式，將錢打入到申請人銀行卡中；若是公司的補貼的錢，則需要通過ERP報銷的方式，提供相應的發票，才能將金額提現到銀行卡中。

（5）錢包消費

員工在食堂消費時，可通過主掃或被掃的方式進行支付，扣款時，根據員工自行設置的扣款優先級進行扣費，一般默認有限扣補貼錢包的錢。錢收到商家錢包后，企業通過月結的方式給商家提供結算單，商家確認結算單沒有問題后，通過銀企直聯給商家打款。

錢包主要分成3個系統，分為錢包業務系統、員工錢包和商家錢包，錢包業務系統用于錢包各方面的管理，及單據查看；員工錢包提供給員工使用，主要提供錢包余額查看及消費，另外提供充值、提現等操作；商家錢包提供給收款商家使用，主要為商家提供錢包余額、交易流水、確認結算單的操作。

（1）員工錢包頁面及交易明細

（2）商家錢包管理頁面及提現頁面

07 高速ETC錢包建設

曾經網上有人發起一個帖子，征集移動互聯網帶走了哪些行當。其中有人說了一樣東西，錢包。確實現實中的錢包已經被大多數人遺忘了，而手機里的錢包則天天在使用。 回憶類比現實中的錢包，其實主要作用就是用來裝錢、裝銀行卡、以及各類卡和券等。需要交易支付的時候，則把錢包掏出來付款，通過現金或者刷卡等形式。

咱們手機里的錢包，無非也是這些個作用。

作為一家高速ETC發行企業，用戶錢包的建設也是很重要的一個環節。由于過往業務快速發展期間一切為了求快，錢包只是簡單地建了一張表，把身份證等用戶信息放進來，再加多幾個字段標識余額等金額，就上線使用了，但是該錢包模塊拓展性低，已經無法繼續支撐業務發展，因此需要重新設計開發一個拓展性高的錢包體系。

高速ETC的用戶往往是司機或運輸行業的企業，因此該錢包系統承擔著用戶存放通行路費和凍結押金、支付路費和提現等主要功能。

要規劃好該錢包系統，先從以下2方面的思考入手，即根據不同的業務定義出我們所需的錢包類型和；以及根據不同的業務場景規劃錢包系統的功能。

（1）錢包類型

錢包類型如何定義，需要基于實際業務需求來進行規劃。

首先用戶需要存錢用于扣路費，名正言順“ETC錢包”必不可少。

基于風險角度考慮，有必要針對用戶不同的風險行為，此時就需要一個“押金錢包”，并考慮是否根據不同的風險行為下掛不同的子錢包。

出于營銷層面，對用戶發放路費補貼金和獎勵金，這些金額是不能被提現的，因此有必要設置一個“ETC紅包”用于區別用戶真實充的錢。

營銷升級之后還會給用戶發各種卡券，則需要一個“券包”，他不是記錄某個金額數值，而是記錄營銷中心發給用戶各種各樣的券。

（2）錢包功能

規劃系統功能的時候，有幾個方向可以進行分析和打開思路：直接參考競品；對標實體物品；以及根據業務流和場景去規劃。

下面根據業務流和場景來規劃。

錢包開通：

日常使用：

日常我們使用錢包，無非就是看看還剩多少錢；放錢、放卡；拿錢、刷卡付款；以及錢包棄用了把錢抽走等，我們對應一一分析。

本次方案ETC錢包、押金錢包、ETC紅包以及券包4個錢包都需要，但為了降低開發復雜度，暫不規劃押金的子錢包，代價是缺失了押金相關的靈活性，比如想要統計違約產生的押金就只能去實時跑流水。

其次功能層面提供統一的錢包開通、充值、扣款和前臺的對應查詢功能，其余功能暫不開發或沿用舊有系統。

（1）錢包開通

錢包的開通上游依賴于業務層的用戶進件，而且這里需要考慮是否區分企業和個人，以及對用戶的實名驗證問題。

錢包開通前校驗：

該用戶是否已存在錢包且未注銷，防止重復創建錢包；入參的信息是否合法，如身份證、手機號。

（2）錢包充值

錢包充值可以說是用戶側最重要的功能，用戶沒有充值則錢包沒有余額，那么就無法用錢包進行有效扣款。

設計錢包充值的流程時，一定要確認了用戶真正支付成功之后再處理賬戶插入流水和加錢，切記順序不要顛倒過來，否則容易給用戶“免費充值”；

其次為了避免通道側回調不及時或者網絡錯誤等原因，導致用戶實際支付成功，但卻充值失敗沒到賬。因此需要對沒有獲取到最終支付狀態的充值訂單設計補償機制，如定時輪詢，成功后通知賬戶側后續流程。

（3）錢包扣款

由于業務定位原因，錢包的扣款僅支持系統扣路費，暫不支持用戶主動發起其他扣款。

與錢包充值剛好相反，進行錢包扣款的時候，切記要先處理完錢包之后，再返回給業務側扣款成功，否則如果業務側收到扣款成功之后，錢包的處理報錯，則相當于免費給用戶做嫁衣，如若當批量出錯的時候，后果將不堪設想。

體現在高速ETC場景就會導致用戶該扣的通行賬單全部是扣款成功，但是錢包余額未減，用戶無限通行，企業無限墊資虧損。

錢包的產品架構，底層對支付系統輸出支付相關的能力，并規劃錢包信息、銀行卡和卡券子模塊串聯起整個錢包模塊。

錢包的開通依賴于用戶系統的主體信息，實名認證則通過外部實名通道，支付和卡券系統給錢包加錢扣錢、發券核券，一個基本的錢包架構就完善起來了。

前臺主要提供余額查看、充值以及調整扣款順序的功能。由于該產品用戶偏向40-50歲的中年人，而且載體是微信小程序產品，因此頁面設計偏向微信風格。

另外考慮到一些用戶會等到欠款才來充值還款，導致已經被高速限制通行了，因此我們在充值頁面除了默認幫用戶選中合適的金額之外，還會提示用戶還錢欠款后需要等待24小時才能解除通行限制，這就是有“場景感”的設計，同時也能減少一部分不必要的客服咨詢。

扣款設置頁面，借鑒長按拖拉調整順序的交互。這里額外說明一點，調整成功后頁面最好給一個提示說明，強化用戶感知。

管理后臺主要設計錢包列表，以供客服和運營人員查看相關信息。

考慮到數據安全和后期數據量會巨大的問題，頁面加載的時候可不展示任何信息，需操作人員輸入一定的查詢條件之后再根據查詢條件展示相關的錢包。

其次企業交易量比較大，錢包交易流水每月可達千萬條數據量，需要和開發大哥提前溝通規劃好分表，再根據分表考慮查詢功能的設計，不然當數據量大的時候查詢會很緩慢，直接結果就是產研被吐槽（因為其他人是無法理解這種數據量大的問題的）。

頁面的交互采取點擊對應錢包的余額字段，則跳轉或彈窗展示對應錢包的流水，這種交互適合客服人員針對性查看，但是不適合運營和財務去拉取流水統計數據。

錢包系統的設計，除了規劃功能之外，需要設計什么類型的錢包也是至關重要的，這決定了后續業務功能拓展的難易程度。不同行業具有各自業務的差異性，如果照著正統的支付行業來設計錢包也許會水土不服。作為產品經理，還是要多結合各方知識，加以吸收和思考之后回歸業務，結合場景，才能設計出和合適的產品。

08 線下游樂-用戶錢包

線下游樂指的是諸如電玩城、真人CS、密室逃脫等依托線下實體的休閑娛樂場所。此類休閑娛樂場所出于快速回款以及營銷需要普遍會提供會員卡業務，用戶加入會員并進行預充值就可以用會員價購買商品或服務，達到用戶獲得優惠、商家獲得盈利的雙贏局面，這里的會員卡其實就是一個簡單的錢包。

在“品牌方-加盟商-用戶”的模型下，一般會由品牌方提供及維護加盟商日常運營中所需要用到的在線操作系統，會員就是其中的一部分。為了快速開展業務，品牌方一般會在初期采用點對點的系統交付方式，即雖然給所有的加盟商都是使用的同一套系統，但是各個加盟商之間的數據不會打通。拿會員卡舉例就是可能存在一個用戶擁有多個加盟商的會員卡的情況。

為了滿足現代化的實體門店運營，需要保證用戶能在線上線下都便捷的享受到會員服務，那么從會員卡的注冊到會員卡的充值、消費等都需要考慮到線上、線下兩個場景都能正常運轉業務且數據是互通的。同時，為了吸引顧客充值，除了享受會員價外還有一種有效的促銷手段就是充值余額贈送積分（積分可直接用于消費），于是會員卡需要支持多種賬戶余額和流水的查詢。

我們首先從產品的架構開始設計，從以上場景中我們可以簡單總結出我們的錢包需要提供注冊、充值、余額查詢、流水查詢、消費等功能。其中注冊環節需要和用戶管理系統打通，充值需要支付系統的支持，進行消費和訂單系統會產生聯系，以上的交易行為又能通過賬戶管理進行查詢。整個架構如下圖所示：

注意事項：一般的錢包還會有一個重要的功能便是退款。但是在線下交易當中退款遠不如線上交易那般頻繁，且用戶充值余額一般不直接存于用戶的賬戶當中，而是進了加盟商的口袋。若發生退款，一般采用線下人工處理的方法進行退還，流程如下：

用戶提出退款申請→加盟商向平臺方發起用戶賬戶清空請求→平臺方清空用戶賬戶→加盟商通過打款或現金的方式將金額退還

我們先從在線下開設會員卡說起。在提供給加盟商的收銀臺系統中集成開設會員卡的功能，為了促成交易需要盡量縮短注冊流程。所以只需要用戶告知昵稱和手機號并選擇充值金額完成支付即可成功開設會員卡。原型圖如下：

需要注意的是加盟商可以選擇是否需要進行手機號驗證，因為短信驗證一般是需要收費的，品牌方和加盟商如果都不想承擔這筆費用那么就可以去掉這一個環節。

但考慮到線下開設會員卡不利于積累粉絲和進行活動推廣，所以我們也提供線上商城供用戶自行或經過工作人員引導開設會員卡。為了吸引用戶進入線上商城，加盟商一般會給予在線上商城注冊的用戶更多的優惠。

考慮到本錢包主要服務于線下行業，用戶有較強的目的性（要在門店中消費），且線下場景中受限于門店地理位置的影響可能導致手機信號不穩定，所以為了方便用戶在門店中順暢的使用線上商城開通錢包，我們需要盡可能的減少自主注冊的步驟。

所以在我的設計當中用戶注冊線上商城就默認開通了錢包，但是和線下開設會員卡不同的是在線上商城注冊登錄并不需要先進行充值，這是為了不給非線下途徑進入的用戶造成困惱（因為用戶沒有在線下門店，對商品和服務還沒有直觀的感受，一開始就要充值容易勸退用戶）。

用戶注冊之后就可以在線上商城中看到自己的會員卡信息和充值相關的功能，這個頁面基本上涵蓋了本錢包的所有功能。如下圖所示：

注冊之后為了使用會員卡用戶需要先進行充值（如果是線下收銀臺開設會員卡就已經完成了充值的過程），那么用戶充值的前提是加盟商對用戶充值的擋位進行配置，管理后臺中的配置表如下：

需要注意的是增設開始時間和結束時間是為了方便加盟商開展短期的充值促銷活動。

在充值完成之后，用戶通過錢包可以直接查看自己的可用余額，同時加盟商在管理后臺的用戶管理中就可以看到用戶賬戶信息更新了，如下圖所示：

充值完成之后，用戶通過線上商城購買商品時便可以直接選用會員卡進行支付，如下圖所示

在線下門店中使用會員卡支付則簡單一些，要么直接輸入手機號進行扣款，要么點擊“會員碼”通過收銀臺掃描用戶的會員二維碼進行扣款。同樣因為處于成本和安全的權衡，管理后臺要支持配置線下門店可以使用哪種方式扣款，每種方式又是否有額外的限制，如下圖所示：

針對手機號扣款，需要設置的就是是否采用短信驗證個人身份。針對會員碼扣款，需要設置的就是選擇會員碼的單次展示有效時間。

以上的錢包設計非常簡單，非常利于快速產出最小可行性產品，對于小中企業來說足夠支撐其完成業務的初步驗證，看業務能否正常的開展。

當業務模式跑通后（加盟商發展到一定的數量或品牌具有一定的影響力后），為了品牌健康可持續的發展必須考慮為用戶建立統一的賬戶和錢包進行統一的管理。但考慮到品牌方和加盟商已經基于現有的產品和服務簽訂了合同，品牌方顯然是不能一刀切，直接強行將每個用戶在所有加盟商下的賬戶和錢包合并在一處。

于是品牌方需要考慮過渡階段如何設計賬戶和錢包，在用戶側表現為統一的賬戶和錢包，在加盟商側又是各自獨立的。下面將給出一種解決方案，但是不涉及具體的實施細節。

我們依然為每一個用戶建立一個統一的賬戶和錢包，但統一賬戶只具備記錄的功能而并不產生實際的金額交互，統一錢包內的余額是用戶在所有加盟商下的余額累加。用戶的充值和消費依舊是在每個錢包內獨立完成，如果某個獨立的錢包內的余額不足以支付本次消費的費用，就會發生獨立錢包間的金額流轉。

專欄作家

陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！

本文原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

關鍵詞