“电子钱包设计全攻略，从基础到进阶剖析。” 在数字化时代，电子钱包的应用日益广泛，那么其设计原理与流程是怎样的？如何确保其功能的完善与安全？一提多户等复杂场景又该如何应对？
钱包钱包，就是装钱的包，这个解释应该是最精准的了。但是谁说钱包只能装钱呢，装身份证行不行，装名片可不可以，装某人的照片是不是可行？一个不装钱的包还叫钱包么？本小节将解析用户电子钱包的设计思路和方法。
电子钱包是利用互联网技术手段实现数字货币线上管理的数字化钱包，我们看几个钱包示例：京东钱包、美团钱包、滴滴钱包、知识星球钱包。
图1 钱包案例
从这些案例中，不难发现，钱包可以抽象为一个资产管理工具，可以提供“存钱、借钱、花钱、结钱”的资金管理服务
由此，一个钱包常具备以下功能资金管理类功能：资产管理(余额)、信贷管理（借钱）、理财管理、基础交易（充值、提现、转账、消费支付）入口作用：商品入口、营销入口、重要活动通知入口
基础功能：卡管理、支付密码管理、实名认证 电子钱包，无非要满足2个条件，第一个是数字化的，第二点是用于管钱的，既然管钱就必然有“多少钱的余额”“怎么变化的流水”。钱包最核心的一个用途就是管钱，另一个非常重要的用途是用于支付交易。因为无论在银行还是在三方支付机构开通的钱包更多的目的是用于结算或者支付，所以暂且认为钱包的核心目的是支付，如图2所示。
图2 钱包用途
从另一个角度来看，钱包是一个金融工具，管理电子货币，并向用户提供充值、提现、转账、支付的交易能力。
钱包的底层能力其实就是账户；钱包的用户端无非就是个壳，如图3所示，应用层就是用户使用的钱包，底层是账户的基础能力，包括注册、绑卡、转账等交易能力。
图3 钱包的底层能力
常见的账户种类有央行的清算账户、银行结算账户、支付机构的支付账户、企业自建的虚拟账户等，其中，银行结算账户主要分个人结算账户和企业结算账户；支付机构也可以为用户开具账户，称之为支付账户；还有一种账户就是平台自建账户，当然这类账户就是虚拟记账，并不存有真实的资金，围绕自建账户也可以构建一个用户钱包体系。
钱包的本质是账户，账户的本质是资金，所以根据账户里的资金属性来看，钱包可以分为银行钱包、支付机构钱包、企业钱包、数字人民币钱包等，其中由银行基于银行结算账户体系构建的钱包应用是银行钱包，比如各个银行APP里的钱包；由支付机构基于支付账户体系提供钱包解决方案构建的钱包应用或者API经过商户封装后的钱包应用是支付机构钱包。
钱包的产品架构可以分为三层，如图4所示，其中，应用层主要为用户端钱包，为用户提供钱包的基础功能，例如余额管理和流水查看，银行卡绑定，实名认证等；支持系统为内部系统，为钱包提供各项服务能力，例如会员服务、银行卡服务、支付系统、账户系统等；最底层为外部的服务通道，例如支付通道、实名认证通道等。因此，可以说钱包是通过集成众多底层能力实现的。
图4 钱包产品架构
钱包的业务流程可以基于不同的服务去分析，如图5所示，钱包的注册开户流程、实名认证流程、余额流水查询流程、充值提现流程等，每一个流程都会涉及到内部相关的几个系统，例如注册开户会涉及到用户中心，为开户提供用户基础信息。
图5 钱包涉及到的系统体系
用户进入钱包应用以后首先需要先完成账号注册、账户开户、实名认证、设置密码，然后可以使用钱包相关的功能，例如支付相关功能、银行卡管理的相关功能、信息查询等，如图6所示。
图6 钱包的使用流程
钱包可以完全自己做，也可以接入三方支付机构等外部机构的钱包
接入外部钱包核心是接入外部钱包的各类服务，由渠道统一接入，向内提供统一的钱包服务给到支付系统、付款系统、基础服务等业务系统，整个结构如图7所示
图7 底层接入外部合规钱包
钱包的核心功能主要包括注册、实名认证、绑卡、充值提现、转账、支付等，下面分别做一个详细的解读。
注册：用户先注册为平台用户获得唯一身份ID，然后申请开通钱包功能，该钱包可以是平台自建，也可以是接入的三方的钱包，如果是接入的三方钱包，那么按照三方要求传送用户信息申请开户，如图8所示。
图 8 钱包注册及开户
实名认证，一般实名认证主要是2种，一个是通过三方支付的绑卡多要素鉴权实现认证；另一个是手机号，主要通过运营商的手机实名认证。
绑卡/解绑，绑卡鉴权有现成的服务接口，接入即可，四要素的，三要素的，五要素的；如果是自建钱包只是为了验证银行卡可不可用，那么使用三要素即可；如果是接入的三方支付公司的钱包服务，那么根据开的是几类支付账户进行鉴权认证选择即可。
充值/提现，有了钱包就需要充钱，钱包不用了就需要把钱提出来；如果是自建钱包没接入任何一方的话，使用微信支付宝进行充值即可，提现的话接入三方的付款通道即可，将资金付给用户；如果是接入了三方钱包的话，使用三方提供的交易能力即可。
转账，主要是指用户之间的钱包账户之间进行资金转移，一般不支持跨商户平台转账；有个人对个人转账，也有商户对个人转账，如图9所示。
图9 钱包之间的转账
余额支付，就是使用钱包进行下单支付，比如我们在购买商品用微信支付时支付方式可以选择微信钱包；平台也可以使用自己的虚拟账户体系构建余额支付能力。前端设计首先也考虑的就是钱包的基础能力，例如余额管理、充值提现、流水的查看等，完成基础能力建设以后，可以基于实际需要构建更多的其他能力，比如信贷、欠款偿还等，如图10所示是一款简单的B2B采购商城的商户钱包，主要用于商户采购下单支付。
图10 钱包页面
钱包的运营后台、账户系统、支付交易等独立系统单元这里就不介绍了，在其他章节有详细解析，钱包的开通情况记录可以通过一个后台列表实现，如图11所示，可以看到用户钱包的基础信息，钱包类型、认证状态、账户类别等。
图11 用户钱包列表
这是一个非常实用的案例，对综合素养要求较高，案例涉及面比较广。很多公司会存在多条业务，有些企业每个业务线都会有一个钱包业务，这样就造成了商家端钱包分散，一个商家在每个业务线都有一个钱包，分别管理余额、提现、绑卡、支付密码等，资金管理体验比较差，如图12所示。
图12 多个业务线
多个钱包此种情况可能就有了统一各业务线钱包的诉求，统一以后商家仅需管理一个钱包，绑定一张卡，设置一个密码，一次完成多账户的同时提现，提高资金管理效率，提升商家的结算体验，如图13所示。
图13 统一钱包结构
此种情况下，钱包的提现业务有2个核心问题要解决：第一个核心问题是“判断有多少可提”：需要有系统告诉钱包当前的可提金额是多少，以及这些余额分别来自哪些账户，每个账户各有多少。第二个核心问题是“怎么发起提现”：当商家输入提现金额时，需要有系统告知钱包，本笔提现要从哪些账户出，每个账户出多少，所以需要一个分配提现金额的策略。
以上统一钱包的诉求，可以转换为“钱包的余额查询、提现预加工的支持”这样两个更明确的诉求，其中有几个关键点要想明白。
可提余额并不一定等于账户可用余额的总和，因为有提现手续费，导致个别账户可能不满足最低提现金额要求，所以说可提金额不一定等于可用余额的总和。比如一个账户里只有2毛钱，而提现手续费要5毛，就无法完成提现，如表1所示。示例中主体001的可提余额计算结果=11.5元，因为账户3中的0.8元不满足最低提现要求，因此不可提，实际可提金额=1.5+10.00=11.5元，因此，钱包可用余额12.3元，可提金额=11.5元。表1 账户的最小可提金额示例
可提余额不代表用户要提的金额，因为用户可能只选择提取其中的一部分，所以要计算这部分金额应该如何分配到账户中，除非让用户选择那个账户提多少，但这样就失去了统一钱包的意义了，那么如图14所示，就需要设定一个策略，在用户属于一个提现金额时，计算出这么多金额分别从每个账户扣多少。
图14 提现金额
分配至账户的策略制定一个提现金额的分配策略，有很多种方法，可以做得简单一些，比如设定一个固定的顺序，以“ABC”的顺序进行扣款，如图15所示，先扣A账户，再扣B账户，最后扣C账户。
图15 固定的提现
扣款顺序也可以做成综合策略，比如如果一个账户就够了，那就只出一个账户，如果多个账户才能够，那就按照顺序扣款等，不过这样的算法成本会增高，可能带来的效果并不明显，所以，我们就选择第一种方法，按照固定顺序扣款，这样增加一个提现顺序的配置，如表2所示。表2 提现顺序配置
如例：可提金额是11.5，此时用户仅提现“8元”，根据提现扣款顺序的设定，如表2所示，实际扣款如表最后一列：账户1扣1.5，账户2扣6.5。用户每输入一次提现金额，就执行一次预计算，并实时反馈给用户钱包。
因为钱包底层是多个账户，每个账户都有总余额，可用余额，可提金额等信息，那么当钱包要查询账户余额信息时，对底层账户余额进行加工汇总的任务谁来完成？也就是通过执行以下三个公式：
钱包N总余额=账户A余额+账户B余额+账户C余额
钱包N可用余额=账户A可用余额+账户B可用余额+账户C可用余额
钱包N可提余额=账户A可提余额+账户B可提余额+账户C可提余额
无外乎有3种处理方法，分别是钱包进行处理、账户系统进行处理或者一个中间层来处理，下面分别分析每一种实现方式的利弊。
钱包进行处理：这种方法有个问题，耦合严重，钱包受底层账户的账户设置、制度政策的影响较大，如图16所示，钱包查询到各账户余额然后进行汇总加和得出账户各类总余额。
图16 钱包处理账户
余额的计算账户系统进行处理：这会让账户系统承载更多的计算任务，不利于资金管理的纯粹性，需要过渡承接业务的变化带来的迭代压力，如图17所示，账户系统对各账户余额进行汇总加和得出总账户余额，然后将结果告知钱包。
图17 账户处理账户
余额的计算清算系统进行处理：对于清算系统来说，进行大量的计算和处理是其最擅长的职能，交给它去完成，上下游都释放了压力，各自去做自己最纯粹的事情，如图18所示，清算系统获得各账户的余额以后进行汇总加和得出总余额，然后提供给钱包。
图18 清算系统处理账户
余额的计算其中，箭头代表余额数据的查询，123代表明细数据，N代表处理过的数据，清算系统查询到123明细数据，输出给钱包的是汇总数据N，并且包含了明细数据123。为了释放账户的压力，让账户专心做自己资金管理的职能，将一些处理事务交给清结算系统去做，包括对账户余额的加工处理，以及提现余额的分配计算等，如图19所示，增加一个钱包的统一处理服务层，完成统一钱包的预处理服务。
图19 钱包统一处理层
因为钱包侧用户只发起一笔提现请求，但是，最终要扣多个账户，出多笔资金，那么，这个从一提到多出的处理由谁来实现，也就是一笔提现变多笔提现。因为是提现业务，所以我们选择让提现处理系统来完成对提现的拆分，也就是钱包发起提现时，会请求清算系统对提现金额进行分配计算，然后得到计算结果，并封装成提现数据提交给提现系统。钱包提交的提现请求数据结构为：提现请求 {提现请求ID,提现金额X}；提现明细 {子提现请求1，子提现请求2}。提现系统将提现请求拆分成两笔提现：提现1，提现2，分别请求清算系统进行提现扣款处理，整个提现处理的业务流程如图20所示，清算中心分别进行可提金额的计算、提现金额的预计算处理，而提现系统进行提现的拆单处理。
图20 统一提现处理流程
基于上述的方案，将整个统一钱包的提现业务流绘制成架构图，看看整个业务所涉及的范围，以及每个环节要承载的任务，如图21所示。
图21 统一钱包提现处理架构图
通过上图，就可以看清楚做这件事所涉及到的环节，以及要实现的能力有哪些，谁来做什么，上面的案例可以培养对整个钱包、账户、提现业务的认识，同样，也是一个可以拿来即用的产品方案。推荐阅读详解最难的账务处理：订单用了各类券详解账务系统，从入门到精通88张图，把支付清结算串起来
本文由人人都是产品经理作者【陈天宇宙】，微信公众号：【陈天宇宙】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。