了解了账户从0到1的搭建相关，作者结合相关实战案例，本文从账户系统最常见的应用出发，分享在众多APP中都常见的钱包功能。希望对你有所帮助。
上一篇我们分享了账户系统的从0到1搭建，本篇我们从账户系统最常见的应用出发，分享一下APP中经常看到的钱包是怎么一回事？
一、概述
1. 什么是钱包
用一句话来概括：钱包是账户系统C端化、看板化的外壳，2个关键词：C端化、看板化，针对这两个关键词简单说一下。
C端化：在分享账户系统的时候我们说过，账户系统本身基本不承载业务规则，只是记录账户主体因为业务活动而造成的资产数据的变动，那钱包的主要功能则是把账户系统的数据显示给C端用户，同时提供一些业务活动（常见功能）的入口，例如充值/支付/提现等。
看板化：这个也是和账户系统的核心作用有关，我们知道账户系统的主要功能是记录资产数据的变动，某种意义来说账户其实是一个数据载体，实际场景中资产数据多种多样，有收入也有支出，支出可能又可以分为提现和支付，为了方便C端用户的理解，就需要进行分类/汇总展示，部分APP可能还会做成可视化看板，方便用户阅读。
2. 钱包的分类
钱包的分类与账户分类相同，因为本质上钱包只是账户的一个【壳】，如上篇文所说，根据钱包（账户）所属对象的不同大体上分为2类：平台钱包、支付机构/银行钱包，本质区别是开通需要的信息不同、资金存管的路径不同。
账户开通：支付机构/银行钱包（账户）开通，最基本也需要实名三要素鉴权，开通更高级别的钱包（账户）则需要更多类型的实名鉴权信息，这是合规要求。
开通平台钱包（账户），需要的信息则完全由平台自行决定，政策合规层面无此部分要求，只是手机号注册开通账户也是可以的，有人说，平台钱包也需要绑卡呀，部分原因是业务侧风控需要，部分原因则是因为用户提现/充值需要绑卡。
资金存放：平台钱包的资金由平台自由支配，支付钱包/银行钱包资金则都存放在机构在人行开通的备付金账户中，不可随意支配。
3. 钱包的作用
钱包的作用上文其实已经大概说了，主要展示账户资金数据与提供常见功能入口，资金数据展示逻辑根据自己业务需要展示即可，重点说下常见功能：充值、提现、余额支付、转账，上述功能中【转账】除了在微信/支付宝/银行APP中能见到，在其他实际业务场景比较少见，原因在账户系统已经分享过，在这不再赘述。
至于充值/提现/余额支付/提现这部分功能，钱包只是提供入口，复杂的是底层支撑系统与接口能力，重点会分享这部分。
二、钱包系统架构
从上图可以看到钱包的应用层面比较简单，仅是展示功能应用的入口，但每个功能应用后面都需要不同的底层系统支持才可以实现，也再次说明钱包本质上仅是一个壳，常见功能都是通过底层系统间相互交互来实现，后续分享也是以这几个功能的关键的核心流程展开。
三、如何从0到1搭建用户钱包
1. 概述
钱包的搭建主要分为3个方面：钱包开通、常见功能建设、前端数据展示，分开说明下：
开通钱包：本质就是为用户（个人/企业）开通账户，账户开通后，前端（APP/小程序）展示对应钱包入口即可，开通账户的流程比较简单，可以请求账户系统接口开通，可以直接在后台手动开通，详情可以看我上一篇文章，在这不再赘述。
功能建设：用户钱包最核心也是最常见的功能：充值、提现、余额支付、银行卡与密码管理，下面的重点也是围绕这几个功能的建设展开分享，先按下不表。
数据展示：数据展示这块比较简单，核心要点在于平台用户对什么数据比较关心，然后通过合适的形式展示即可，这个是交互层面的东西，不细说了，不知道怎么做可直接找比较好的借鉴（抄）即可，如下图外卖骑手APP截图：
2. 核心流程及主要页面说明
（1）充值
充值是钱包非常重要的1个流程，特别是用户侧钱包基本上可以说最重要的1个流程，因为大多数平台搭建用户侧做钱包正常都是为了让用户充值增加用户黏性，进而持续在平台消费带来营收，当然也不排除部分平台是为了资金沉淀，办不下去就卷款跑路（类比线下各种健身、培训班充值）。
流程说明：钱包充值的实现方案与电商的购买流程大致相同，可以简单理解为：用户购买平台1件虚拟商品（无实际价值），用户支付成功后，资金入账至用户在平台的账户中，详细流程详见下图，后续用户可以直接用此部分资金进行支付。
相对于传统电商购物流程，钱包充值流程不能使用优惠券，无需发货，不支持退款（通过提现实现），可以理解为为简化版的电商支付流程，所以整体流程复杂度尚可。
充值还有另1种实现方式：端上直接请求交易系统接口，创建交易与支付账单，省掉下单流程，但这种方式用的较少，主要原因在于不是通用流程，同时数据也形成了断层。
原型说明：原型这部分比较简单，大家直接看各APP的充值流程即可，基本上通用的，选择/输入充值金额，选择支付方式完成支付即可，如下图：
（2）余额支付
余额支付是与余额充值搭配的功能，用户充值的资金必须可以在平台使用才可以，不然用户肯定不会充值，充值功能也就没有存在的意义。
流程说明：余额支付的系统交互流程比较简单（详见下图），收银台页面新增【余额支付】的支付方式，前端调起收银台时，显示当前可用余额，余额不足则【置灰】不可点击。
简单说下要不要支持组合支付的问题，个人觉得没必要支持：
1、没有明显的业务收益，而且若只可余额足额支付，还能促进用户持续充值（钱包剩余金额不足以下次支付）
2、若组合支付涉及优惠、部分退款等场景，系统逻辑会做的比较复杂，带来较高的开发成本，简单总结一句话：投入产出比太低
（3）余额提现
余额提现系统交互流程也比较简单（详情见下图），有2个点单独说下，可用余额与手续费。
可用余额：劳动者侧钱包余额数据可分为三个：总余额、可用金额、冻结金额，总余额=可用金额+冻结金额，提现时只可提现可用金额，某些APP也把冻结金额叫待结算金额，只是一个叫法，金额的本质是一致的，具体可以查看上篇账户系统文章查看。
手续费：用户/劳动者提现时通道侧需要按笔/按比例收取手续费，设计这部分逻辑时候需要确定手续费的承担方，平台承担还是用户/劳动者承担，内扣还是外扣，即手续费单独从手续费账户出，还是直接从结算资金中扣除。
（4）银行卡/密码管理
这部分更简单，用户输入银行卡/姓名/身份证/手机号等实名信息后，平台请求实名鉴权通道验证用户信息是否有误，而后进行系统数据落库，返回端上鉴权结果即可，至于后续变更结算卡，这部分是一个交互层面的设计，在这不再赘述，密码管理流程类似。
四、总结
如开头所说：钱包可以看作账户系统的壳，其本身的产品设计很简单，更多是用户体验层面，核心与难点在于底层不同支撑系统的交互与设计（上图各流程图），可以着重学习下底层系统的产品设计，后续也会分享这些系统的设计方法，可以Mark下。
本文由 @鲸爷陆 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
上一篇
