电子“钱包”设计，从入门到精通

电子“钱包”设计，从入门到精通

在数字化时代，电子钱包已成为人们日常生活中不可或缺的支付工具。从简单的资金管理到复杂的多账户统一处理，电子钱包的设计和实现涉及多个层面的技术和业务逻辑。本文将从基础概念出发，深入解析电子钱包的设计原理、功能架构以及复杂场景的解决方案，帮助读者全面了解这一金融科技产品。

1. 钱包概述

电子钱包是利用互联网技术手段实现数字货币线上管理的数字化钱包。我们来看几个钱包示例：京东钱包、美团钱包、滴滴钱包、知识星球钱包。

从这些案例中，不难发现，钱包可以抽象为一个资产管理工具，可以提供“存钱、借钱、花钱、结钱”的资金管理服务。由此，一个钱包常具备以下功能：

• 资金管理类功能：资产管理（余额）、信贷管理（借钱）、理财管理
• 基础交易：充值、提现、转账、消费支付
• 入口作用：商品入口、营销入口、重要活动通知入口
• 基础功能：卡管理、支付密码管理、实名认证

电子钱包，无非要满足2个条件，第一个是数字化的，第二点是用于管钱的，既然管钱就必然有“多少钱的余额”“怎么变化的流水”。钱包最核心的一个用途就是管钱，另一个非常重要的用途是用于支付交易。因为无论在银行还是在三方支付机构开通的钱包更多的目的是用于结算或者支付，所以暂且认为钱包的核心目的是支付。

从另一个角度来看，钱包是一个金融工具，管理电子货币，并向用户提供充值、提现、转账、支付的交易能力。

2. 钱包的底层能力

钱包的底层能力其实就是账户；钱包的用户端无非就是个壳。

应用层就是用户使用的钱包，底层是账户的基础能力，包括注册、绑卡、转账等交易能力。

常见的账户种类有央行的清算账户、银行结算账户、支付机构的支付账户、企业自建的虚拟账户等，其中，银行结算账户主要分个人结算账户和企业结算账户；支付机构也可以为用户开具账户，称之为支付账户；还有一种账户就是平台自建账户，当然这类账户就是虚拟记账，并不存有真实的资金，围绕自建账户也可以构建一个用户钱包体系。钱包的本质是账户，账户的本质是资金，所以根据账户里的资金属性来看，钱包可以分为银行钱包、支付机构钱包、企业钱包、数字人民币钱包等，其中由银行基于银行结算账户体系构建的钱包应用是银行钱包，比如各个银行APP里的钱包；由支付机构基于支付账户体系提供钱包解决方案构建的钱包应用或者API经过商户封装后的钱包应用是支付机构钱包。

3. 钱包的架构和流程

钱包的产品架构可以分为三层：

• 应用层：为用户提供钱包的基础功能，例如余额管理和流水查看、银行卡绑定、实名认证等
• 支持系统：为钱包提供各项服务能力，例如会员服务、银行卡服务、支付系统、账户系统等
• 外部服务通道：包括支付通道、实名认证通道等

因此，可以说钱包是通过集成众多底层能力实现的。

钱包的业务流程可以基于不同的服务去分析：

用户进入钱包应用以后首先需要先完成账号注册、账户开户、实名认证、设置密码，然后可以使用钱包相关的功能，例如支付相关功能、银行卡管理的相关功能、信息查询等。

钱包可以完全自己做，也可以接入三方支付机构等外部机构的钱包。接入外部钱包核心是接入外部钱包的各类服务，由渠道统一接入，向内提供统一的钱包服务给到支付系统、付款系统、基础服务等业务系统，整个结构如下：

4. 钱包的功能

钱包的核心功能主要包括注册、实名认证、绑卡、充值提现、转账、支付等，下面分别做一个详细的解读。

• 注册：用户先注册为平台用户获得唯一身份ID，然后申请开通钱包功能，该钱包可以是平台自建，也可以是接入的三方的钱包，如果是接入的三方钱包，那么按照三方要求传送用户信息申请开户。

• 实名认证：一般实名认证主要是2种，一个是通过三方支付的绑卡多要素鉴权实现认证；另一个是手机号，主要通过运营商的手机实名认证。

• 绑卡/解绑：绑卡鉴权有现成的服务接口，接入即可，四要素的，三要素的，五要素的；如果是自建钱包只是为了验证银行卡可不可用，那么使用三要素即可；如果是接入的三方支付公司的钱包服务，那么根据开的是几类支付账户进行鉴权认证选择即可。

• 充值/提现：有了钱包就需要充钱，钱包不用了就需要把钱提出来；如果是自建钱包没接入任何一方的话，使用微信支付宝进行充值即可，提现的话接入三方的付款通道即可，将资金付给用户；如果是接入了三方钱包的话，使用三方提供的交易能力即可。

• 转账：主要是指用户之间的钱包账户之间进行资金转移，一般不支持跨商户平台转账；有个人对个人转账，也有商户对个人转账。

• 余额支付：就是使用钱包进行下单支付，比如我们在购买商品用微信支付时支付方式可以选择微信钱包；平台也可以使用自己的虚拟账户体系构建余额支付能力。

前端设计首先也考虑的就是钱包的基础能力，例如余额管理、充值提现、流水的查看等，完成基础能力建设以后，可以基于实际需要构建更多的其他能力，比如信贷、欠款偿还等。

这是一款简单的B2B采购商城的商户钱包，主要用于商户采购下单支付。

钱包的运营后台、账户系统、支付交易等独立系统单元这里就不介绍了，在其他章节有详细解析，钱包的开通情况记录可以通过一个后台列表实现。

可以看到用户钱包的基础信息，钱包类型、认证状态、账户类别等。

5. 一提多户

这是一个非常实用的案例，对综合素养要求较高，案例涉及面比较广。很多公司会存在多条业务，有些企业每个业务线都会有一个钱包业务，这样就造成了商家端钱包分散，一个商家在每个业务线都有一个钱包，分别管理余额、提现、绑卡、支付密码等，资金管理体验比较差。

多个钱包此种情况可能就有了统一各业务线钱包的诉求，统一以后商家仅需管理一个钱包，绑定一张卡，设置一个密码，一次完成多账户的同时提现，提高资金管理效率，提升商家的结算体验。

此种情况下，钱包的提现业务有2个核心问题要解决：

1. 判断有多少可提：需要有系统告诉钱包当前的可提金额是多少，以及这些余额分别来自哪些账户，每个账户各有多少。
2. 怎么发起提现：当商家输入提现金额时，需要有系统告知钱包，本笔提现要从哪些账户出，每个账户出多少，所以需要一个分配提现金额的策略。

5.1. 解决几个关键问题

以上统一钱包的诉求，可以转换为“钱包的余额查询、提现预加工的支持”这样两个更明确的诉求，其中有几个关键点要想明白。

• 可提余额并不一定等于账户可用余额的总和，因为有提现手续费，导致个别账户可能不满足最低提现金额要求，所以说可提金额不一定等于可用余额的总和。比如一个账户里只有2毛钱，而提现手续费要5毛，就无法完成提现。

• 可提余额不代表用户要提的金额，因为用户可能只选择提取其中的一部分，所以要计算这部分金额应该如何分配到账户中，除非让用户选择那个账户提多少，但这样就失去了统一钱包的意义了，那么就需要设定一个策略，在用户属于一个提现金额时，计算出这么多金额分别从每个账户扣多少。

5.2. 计算账户余额

因为钱包底层是多个账户，每个账户都有总余额、可用余额、可提金额等信息，那么当钱包要查询账户余额信息时，对底层账户余额进行加工汇总的任务谁来完成？也就是通过执行以下三个公式：

• 钱包N总余额 = 账户A余额 + 账户B余额 + 账户C余额
• 钱包N可用余额 = 账户A可用余额 + 账户B可用余额 + 账户C可用余额
• 钱包N可提余额 = 账户A可提余额 + 账户B可提余额 + 账户C可提余额

无外乎有3种处理方法，分别是钱包进行处理、账户系统进行处理或者一个中间层来处理，下面分别分析每一种实现方式的利弊。

• 钱包进行处理：这种方法有个问题，耦合严重，钱包受底层账户的账户设置、制度政策的影响较大。

• 账户系统进行处理：这会让账户系统承载更多的计算任务，不利于资金管理的纯粹性，需要过渡承接业务的变化带来的迭代压力。

• 清算系统进行处理：对于清算系统来说，进行大量的计算和处理是其最擅长的职能，交给它去完成，上下游都释放了压力，各自去做自己最纯粹的事情。

为了释放账户的压力，让账户专心做自己资金管理的职能，将一些处理事务交给清结算系统去做，包括对账户余额的加工处理，以及提现余额的分配计算等，增加一个钱包的统一处理服务层，完成统一钱包的预处理服务。

5.3. 流程与架构

因为钱包侧用户只发起一笔提现请求，但是，最终要扣多个账户，出多笔资金，那么，这个从一提到多出的处理由谁来实现，也就是一笔提现变多笔提现。因为是提现业务，所以我们选择让提现处理系统来完成对提现的拆分，也就是钱包发起提现时，会请求清算系统对提现金额进行分配计算，然后得到计算结果，并封装成提现数据提交给提现系统。

钱包提交的提现请求数据结构为：

• 提现请求 {提现请求ID,提现金额X}
• 提现明细 {子提现请求1，子提现请求2}

提现系统将提现请求拆分成两笔提现：提现1，提现2，分别请求清算系统进行提现扣款处理，整个提现处理的业务流程如下：

清算中心分别进行可提金额的计算、提现金额的预计算处理，而提现系统进行提现的拆单处理。

基于上述的方案，将整个统一钱包的提现业务流绘制成架构图，看看整个业务所涉及的范围，以及每个环节要承载的任务。

通过上图，就可以看清楚做这件事所涉及到的环节，以及要实现的能力有哪些，谁来做什么，上面的案例可以培养对整个钱包、账户、提现业务的认识，同样，也是一个可以拿来即用的产品方案。