钱包和红包是什么大家都了解的叭！但是对于红包、钱包产品设计的架构和流程了解吗？下面是笔者对于红包和钱包的相关内容做一个分析整理，大家一起往下看，多多了解吧！

掌握了理论知识以后，应用于实践是对理论考察的最佳手段，本章以红包和钱包设计为实际案例，了解支付中架构和逻辑在设计中的应用。

一、红包设计

发红包，领红包，普通红包，拼手气红包，在用户使用层面大家都不陌生，因为经常会用到红包这个功能，但红包底层的支付流程及算法规则、涉及的支撑系统都有哪些，估计很多人并不知道，本小节就分析一下“红包”背后的秘密，掌握如何设计一套红包体系。

1. 红包概述

红包对于用户来说是一种娱乐手段、生活工具，对于企业来说是一种营销手段，大家最熟悉的是经常使用的微信红包，像钉钉、脉脉等很多应用内也都有红包模块。

红包实质上是用户账户之间的“转账”能力；一个用户的账户扣一笔钱，拆分后转给多个账户；至于每个账户转多少金额，就是红包金额的算法，普通红包简单，平均总金额就行；拼手气红包稍微麻烦，既要保证红包最低金额，又要保证金额随机，已经领过的不能再领，过期的红包不能再领且要退回发红包的账户，如图1所示。

图1 红包发放的账户处理

常见的红包类型按照发放者类型可以分为个人对个人和企业对个人，按照领红包对象可以分为指定单个对象或者不指定多个多像，也就是群发红包，按照红包的金额又可以分为固定金额的红包也就是普通红包或者不固定金额的拼手气红包。

红包体系涉及到的相关系统包括前端的应用、订单、账户、营销、运营等，其中：

• 前端应用：用户发放领取的前端展示页，收银台等；
• 订单系统：红包的支付订单，用户领取后的转账订单；
• 账户系统：金额查询，红包余额的转出转入；
• 营销系统：红包规则创建，查询，比如发了多少个，什么类型的红包等；
• 运营系统：查看管理红包发放和领取记录。

2. 架构和流程

红包的功能结构如图2所示，主要包括红包的分类，领取模式，红包的规则，红包的支付方式等模块组成。

图2 红包功能脑图

指定用户的一对一发放场景，是指在一对一聊天场景，发红包给朋友，相当于指定了这个用户领取红包，整个发放和领取流程如图3所示。

图3 指定用户发红包流程

• 发送用户1的状态必须为已实名；
• 指定用户，前端需传输用户2的userid
• 余额支付：用户1使用余额支付时，用户2未领取前，发送金额冻结；
• 绑卡支付：用户1使用银行卡支付时，支付金额先充值到1的资金账户中并冻结；
• 领取：用户2确认领取后，解冻1资金后通过转账，入账至2的资金账户中；
• 退回：用户2到期未领取，发送金额解冻后，遵循原路退回原则，退回用户1；
• 用户1撤销发送：只要用户2未领取，均可解冻资金并退回资金。

不指定用户发放红包可以发放一个，也可以发放多个，由设置的红包数量决定，如图4所示。

图4 不指定用户红包发放流程

对其中比较重要的字段进行说明：

• 发送用户：1；
• 接收用户：n(n=2,3,4…)；
• 发送红包数：K；
• 发送总金额：M；
• 整个流程图中的几个关键点说明如下：
• 发送用户1的状态必须为已实名；
• 接收用户n的状态在领取时不需要为已实名；
• 从设置的红包数/可领取人数K确认，是对单用户还是多用户场景；
• 资金冻结成功后，按照随机规则直接创建K个子红包。
• 用户1使用余额支付时，只要有用户未领取，剩余发送金额都保持冻结态；
• 用户1使用银行卡支付时，支付金额会先充值到1的资金账户中，并冻结该资金。

二、钱包设计

钱包钱包，就是装钱的包，这个解释应该是最精准的了。但是谁说钱包只能装钱呢，装身份证行不行，装名片可不可以，装某人的照片是不是可行？一个不装钱的包还叫钱包么？本小节将解析用户电子钱包的设计思路和方法。

1. 钱包概述

电子钱包是利用互联网技术手段实现数字货币线上管理的数字化钱包，如微信钱包，如图5所示，支付宝钱包，以及刚刚推出的数字人民币钱包。

图5 微信钱包截图

电子钱包，无非要满足2个条件，第一个是数字化的，第二点是用于管钱的，既然管钱就必然有“多少钱的余额”“怎么变化的流水”。

钱包最核心的一个用途就是管钱，另一个非常重要的用途是用于支付交易。因为无论在银行还是在三方支付机构开通的钱包更多的目的是用于结算或者支付，所以暂且认为钱包的核心目的是支付，如图6所示。

图6 钱包用途

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

2. 钱包的底层能力

钱包的底层能力其实就是账户；钱包的用户端无非就是个壳，如图7所示，应用层就是用户使用的钱包，底层是账户的基础能力，包括注册、绑卡、转账等交易能力。

图7 钱包的底层能力

常见的账户种类有央行的清算账户、银行结算账户、支付机构的支付账户、企业自建的虚拟账户等，其中，银行结算账户主要分个人结算账户和企业结算账户；支付机构也可以为用户开具账户，称之为支付账户；还有一种账户就是平台自建账户，当然这类账户就是虚拟记账，并不存有真实的资金，围绕自建账户也可以构建一个用户钱包体系。

钱包的本质是账户，账户的本质是资金，所以根据账户里的资金属性来看，钱包可以分为银行钱包、支付机构钱包、企业钱包、数字人民币钱包等，其中由银行基于银行结算账户体系构建的钱包应用是银行钱包，比如各个银行APP里的钱包；由支付机构基于支付账户体系提供钱包解决方案构建的钱包应用或者API经过商户封装后的钱包应用是支付机构钱包。

3. 钱包的架构和流程

钱包的产品架构可以分为三层，如图8所示，其中，应用层主要为用户端钱包，为用户提供钱包的基础功能，例如余额管理和流水查看，银行卡绑定，实名认证等；支持系统为内部系统，为钱包提供各项服务能力，例如会员服务、银行卡服务、支付系统、账户系统等；最底层为外部的服务通道，例如支付通道、实名认证通道等。因此，可以说钱包是通过集成众多底层能力实现的。

图8 钱包产品架构

钱包得业务流程可以基于不同的服务去分析，如图9所示，钱包的注册开户流程、实名认证流程、余额流水查询流程、充值提现流程等，每一个流程都会涉及到内部相关的几个系统，例如注册开户会涉及到用户中心，为开户提供用户基础信息。

图9 钱包涉及到的系统体系

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

图10 钱包的使用流程

4. 钱包的功能

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

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

图 11 钱包注册及开户

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

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

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

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

图12 钱包之间的转账

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

前端设计首先也考虑的就是钱包的基础能力，例如余额管理、充值提现、流水的查看等，完成基础能力建设以后，可以基于实际需要构建更多的其他能力，比如信贷、欠款偿还等，如图13所示是一款简单的B2B采购商城的商户钱包，主要用于商户采购下单支付。

图13 钱包页面

钱包的运营后台、账户系统、支付交易等独立系统单元这里就不介绍了，在其他章节有详细解析，钱包的开通情况记录可以通过一个后台列表实现，如图12-14所示，可以看到用户钱包的基础信息，钱包类型、认证状态、账户类别等。

图14 用户钱包列表

三、一提多户

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

图15 多个业务线多个钱包

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

图12-15 统一钱包结构

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

第一个核心问题是“判断有多少可提”：需要有系统告诉钱包当前的可提金额是多少，以及这些余额分别来自哪些账户，每个账户各有多少。

第二个核心问题是“怎么发起提现”：当商家输入提现金额时，需要有系统告知钱包，本笔提现要从哪些账户出，每个账户出多少，所以需要一个分配提现金额的策略。

1. 解决几个关键问题

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

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

示例中主体001的可提余额计算结果=11.5元，因为账户3中的0.8元不满足最低提现要求，因此不可提，实际可提金额=1.5+10.00=11.5元，因此，钱包可用余额12.3元，可提金额=11.5元。

表1 账户的最小可提金额示例：

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

图16 提现金额分配至账户的策略

制定一个提现金额的分配策略，有很多种方法，可以做得简单一些，比如设定一个固定的顺序，以“ABC”的顺序进行扣款，如图17所示，先扣A账户，再扣B账户，最后扣C账户。

图17 固定的提现扣款顺序

也可以做成综合策略，比如如果一个账户就够了，那就只出一个账户，如果多个账户才能够，那就按照顺序扣款等，不过这样的算法成本会增高，可能带来的效果并不明显，所以，我们就选择第一种方法，按照固定顺序扣款，这样增加一个提现顺序的配置，如表2所示。

表2 提现顺序配置

如例：可提金额是11.5，此时用户仅提现“8元”，根据提现扣款顺序的设定，如表2所示，实际扣款如表最后一列：账户1扣1.5，账户2扣6.5。用户每输入一次提现金额，就执行一次预计算，并实时反馈给用户钱包。

2. 计算账户余额

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

1. 钱包N总余额=账户A余额+账户B余额+账户C余额；
2. 钱包N可用余额=账户A可用余额+账户B可用余额+账户C可用余额；
3. 钱包N可提余额=账户A可提余额+账户B可提余额+账户C可提余额。

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

钱包进行处理：这种方法有个问题，耦合严重，钱包受底层账户的账户设置、制度政策的影响较大，如图18所示，钱包查询到各账户余额然后进行汇总加和得出账户各类总余额。

图18 钱包处理账户余额的计算

账户系统进行处理：这会让账户系统承载更多的计算任务，不利于资金管理的纯粹性，需要过渡承接业务的变化带来的迭代压力，如图19所示，账户系统对各账户余额进行汇总加和得出总账户余额，然后将结果告知钱包。

图19 账户处理账户余额的计算

清算系统进行处理：对于清算系统来说，进行大量的计算和处理是其最擅长的职能，交给它去完成，上下游都释放了压力，各自去做自己最纯粹的事情，如图20所示，清算系统获得各账户的余额以后进行汇总加和得出总余额，然后提供给钱包。

图20 清算系统处理账户余额的计算

其中，箭头代表余额数据的查询，123代表明细数据，N代表处理过的数据，清算系统查询到123明细数据，输出给钱包的是汇总数据N，并且包含了明细数据123。为了释放账户的压力，让账户专心做自己资金管理的职能，将一些处理事务交给清结算系统去做，包括对账户余额的加工处理，以及提现余额的分配计算等，如图21所示，增加一个钱包的统一处理服务层，完成统一钱包的预处理服务。

图21 钱包统一处理层

四、流程与架构

因为钱包侧用户只发起一笔提现请求，但是，最终要扣多个账户，出多笔资金，那么，这个从一提到多出的处理由谁来实现，也就是一笔提现变多笔提现。

因为是提现业务，所以我们选择让提现处理系统来完成对提现的拆分，也就是钱包发起提现时，会请求清算系统对提现金额进行分配计算，然后得到计算结果，并封装成提现数据提交给提现系统。钱包提交的提现请求数据结构为：提现请求 {提现请求ID,提现金额X}；提现明细{子提现请求1，子提现请求2}。

提现系统将提现请求拆分成两笔提现：提现1，提现2，分别请求清算系统进行提现扣款处理，整个提现处理的业务流程如图22所示，清算中心分别进行可提金额的计算、提现金额的预计算处理，而提现系统进行提现的拆单处理。

图22 统一提现处理流程

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

图23 统一钱包提现处理架构图

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

专栏作家

陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。