8个支付“钱包”设计案例

来源：人人都是产品经理　2023-04-21 04:56:58

随着互联网的发展，钱包电子化已经成为了每个APP都必备的一大功能。那么在互联网中，设计好一个电子钱包需要考虑什么？本文总结了8个支付“钱包”设计案例，希望对你有所启发。

(资料图片)

有些概念就是源于生活——“钱”“包”，一个装钱的包。

什么是电子钱包，就是利用互联网技术手段实现数字货币线上管理的虚拟钱包，像微信钱包，支付宝钱包，以及刚刚推出的数字人民币钱包。

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

实际生活中我们的钱包能装什么，为了方便需要可以放很多东西，例如：放身份证、照片、火车票、戒指等。

所以，钱包本质上是以管理货币为核心的“储物”工具，只要放的下，有人愿意，就可以放，同样适用于电子钱包。

我们看几个钱包示例：京东钱包、美团钱包、滴滴钱包、知识星球钱包。

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

由此，一个钱包常具备以下功能：

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

要设计好一个电子钱包，往往需要思考清楚以下几个问题：

（1）钱包的用途是什么

钱包的用途最核心的一个就是管钱，另一个非常重要的用途就是用于支付交易，其他作用在不同类型平台侧重不同。

在银行还是三方支付机构的钱包更多的目的：用于资金管理、结算、支付。

在一些购物或者其他场景消费类平台：钱包还承载着消费贷以及营销的职能。

所以，钱包可以认为是一种“金融工具”，具备资金管理、信贷管理、理财管理、支付结算等职能。

（2）要做哪一类钱包

在设计钱包之前，要明白自己要设计哪一类钱包，而不同类型的钱包，设计方法以及要思考的核心点也会存在差别。

本质上，钱包是平台为用户提供的账户体系解决方案。

通过收集用户信息，注册，创建XX账户。然后根据用户指令，完成账户实名，绑卡，充值，提现，还款，转账和支付等基础账户操作，并集成贷款、理财、营销入口等其他业务诉求。

进而我们可以根据底层账户的不同，对钱包进行分类。

银行用户钱包：由银行基于银行结算账户体系构建的钱包应用，比如各个银行APP里的钱包。

支付机构用户钱包：由支付机构基于支付账户体系提供钱包解决方案构建的钱包应用或者API经过商户封装后的钱包应用。

数字人民币钱包：人行推出的数字人民币钱包平台自建钱包：各个平台自己基于自建账户搭建的虚拟钱包应用综合钱包：是以上几类账户共同构成账户基础的综合性钱包

（3）钱包的整体架构怎么样

在设计钱包之前要先站在整个业务视角，规划好整个业务流程以及产品架构，以此就有了整个钱包体系的顶层设计，后面的每一个部分的设计就会非常容易。

我们说的钱包一般是个用户产品，提供给终端用户使用，所以，先想明白用户会使用钱包干什么，常见的钱包一般是下面的使用流程。

那么，要提供这样一个使用流程的钱包应用，需要建立怎么样的业务体系，如下图所示。

最后，再想清楚这样的流程和业务架构下，如何设计钱包的产品架构，我们从钱包应用层、相关内部支持系统、依赖的外部服务三层来设计钱包的产品的架构，如下图所示。

（4）钱包需要的交易类型包含哪些

钱包存在意义前面讲了，要提供给用户“管钱、贷款、结算、支付等”的服务，那么最终可以抽象出哪些交易能力要想明白，常见的交易类型有这样几种。

充值/提现/还款：是指钱包账户与同人银行卡之间的转账，一般要求个人账户与个人银行卡归属于同一个用户实体（即同名，同身份证号）。

转账：指主要是指用户之间的钱包账户之间进行资金转移的过程。

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

以上就是对钱包的认识，以及设计钱包前要想明白的问题，要考虑的设计方面。

下面我们就看几个钱包的设计实例，以加深钱包的印象，看看在不同业务场景下的钱包都是怎么做的。

01 家政行业-劳动者钱包

想必大家对家政行业都不陌生，很多读者都请过保洁或者月嫂育儿嫂，家政平台就是撮合雇主和家政服务人员的平台，并提供基础的线上交易设施，以及对家政服务者收入的结算。

在这个过程中就需要为家政服务人员提供一个用于管理结算收入的钱包，钱包核心要实现的能力就是展示结算收入，提现结算收入，并且可以查看收入明细，绑定银行卡等功能。

而这部分我计划围绕钱包介绍一个场景的需求如何实现。

1.1 需求的背景和目标

背景是这样的，公司存在多条业务（保姆、月嫂、保洁），因为历史原因，造成商家端钱包分散，一个商家在每个业务线都有一个钱包，分别管理余额、提现、绑卡、支付密码管理，资金管理体验比较差。

需求要解决的问题就是对各业务线钱包进行统一，商家仅需管理一个钱包，绑定一张卡、设置一个密码，一次完成多账户的同时提现，提高资金管理效率，提升商家结算体验。

汇总之后，会存在一个核心的关系：前端余额是底层账户的汇总，即：

钱包余额=∑（保姆余额，月嫂余额，保洁余额）

1.2 统一后的钱包架构

通过钱包统一处理服务层，统一钱包的各项服务“余额查询、明细查询等”。

1.3 提现处理逻辑

统一以后，钱包中只有一个余额，但要一笔提现，应该怎么处理，整体需要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.4 账单管理

（1）账单有区别于账户余额流水

账单是提供给商家对账的全面的交易数据，便于商家对账；账户流水仅是其账户余额变动明细，便于商家管理结算收入，可以看一下微信钱包的账单以及零钱明细的区别在哪里。

账单的底层逻辑是清算系统汇集、处理获得的本月商家全部交易记录。

02 外卖-骑手钱包

外卖场景很多人都熟悉，现在订外卖是生活中非常高频的事项。

外卖业务中配送是非常重要的一个环节，而配送离不开骑手，配送完以后骑手会拿到配送收入。

这个过程跟家政业务很像，都是O2O范畴，所以这两个领域的支付人可以相互流通，非常高的匹配度。

既然业务非常相似，那么给骑手结算用的钱包也就非常相似了，下图是美团的骑手钱包页面。

其中结算余额、余额提现、账户明细、银行卡管理、账单管理都是非常通用的模块。

可见，如果要设计一个结算用途的钱包，这些功能是少不了的。

而我们要介绍另一个特殊外卖场景的骑手钱包，就是国际外卖，像UBER、DIDIFOOD等。

国际外卖场景与国内整体业务有很多相似之处，但也会存在一些差异。

这些差异主要体现在：面临复杂的政策环境，不同国家的支付基础设施水平不同，劳动法不同，税收政策不同，用户的支付习惯不同等等，造成了在设计钱包时需要考虑这些因素。

比如：

在国外一些国家有小费文化，那么骑手的收入当中有一部分就是“小费”。

不同国家对骑手的税收政策不同，有些国家不需要代扣代缴但需要申报，有些国家需要代扣代缴，那么在税收的计算和账务处理上就会存在差异，而这些差异也会体现在钱包中。

还有一个特别大的差异就是“现金支付”，国外一些国家的现金支付订单特别多，甚至能够达到70%比重，用户下单时选择现金支付，这时候就需要骑手帮其垫付餐费给到商户，等餐送到以后，用户再将餐费给到骑手，骑手还给平台。

这个过程中就会出现骑手结算账户的“负值”，需要骑手进行充值偿还这部分现金收款。

因此，钱包的设计要先梳理清楚钱包的应用环境，基于环境和业务诉求进行模块的规划和建设。

03 宠物电商平台-用户钱包

本部分主要介绍一个宠物B2B电商的钱包案例，该钱包的用户主要用于消费支付使用，所以相比于前面的几个结算用途的钱包，消费用途钱包主要核心就是“充值和余额支付”，而结算用途的钱包主要核心是“提现结算收入”。

从这一点上就可以看出来，不同用途的钱包，其设计核心存在差异。

互联网宠物行业主要包含：宠物社交、宠物电商、宠物问诊等模式。

而这个行业的供应链包括：品牌商、渠道商、代理商、电商平台、宠物店/宠物医院、个人消费者等主体，他们之间构成了如下的关系。

而其中的垂直宠物电商，链接上游代理商与宠物店和宠物医院——平台价值主要是提升行业撮合效率，主打正品；业务的难点是“地域性、品牌限价、线下客勤关系”等。

整个电商平台依赖的最基础的产品体系如图所示：

那么在这样的体系里，为什么要给用户做一个消费下单的钱包呢？

可见，设计钱包要先搞清楚整个业务场景。

因为作为B2B批发平台，大额交易较多，往往单笔支付在10万甚至20万上百万的金额，因此传统的支付渠道很难满足这样的额度需求。

当初设计的钱包的核心目的就是“预充值”突破支付限额。

又因为平台为创业快跑阶段，为了提高平台的GMV，提供了充值返利的活动，因此充一笔资金会赠送一部分余额，上面就是钱包的主页，非常简洁，核心是充值功能，不支持提现，以及支付密码的设置、消费明细。

余额支付就是预充值以后，使用平台的账户余额进行支付。相比外部渠道，平台自身的余额支付体验更好，限额更容易控制，实现超大额支付。

这里会将底层账户模拟出成一条虚拟通道，与微信支付宝通级别进行建设。设计余额支付的支付流程，与微信支付宝在平台内的处理保持一致。

04 在线租车平台-钱包解析

随着出游需求的高涨，大家对于用车的需求也就水涨船高，而租车由于其便捷、舒适和灵活性，成为越来越多年轻人和家庭出游的首选方式，比如目前火热的租车自驾游。那大家试想一下，如果你去租车，第一步要做什么？那肯定是找一家靠谱的租车平台。

要租车就涉及到交易，不管是对租车人还是对提供租车出行服务的租赁企业，支付和资金安全都是刚需。毕竟，租车是一件很严肃的事情，有一定的风险（感兴趣的小伙伴可以网上搜搜），而租赁费也可能是一笔不菲的费用。

4.1 钱包需求

对于那些撮合租车人和租赁企业的租车平台来说，比如专为租赁企业提供数字化解决方案的租车SaaS平台，如何在自身合规的基础上（如规避资金池和二清问题），为用户（主要是租赁企业，即商户）的交易和资金安全保驾护航，就尤为关键。

而对于租车SaaS平台的商户，核心诉求就是保障其资金安全和灵活调度，既要平台为其算明白收支账目，又要管理好钱。那钱要怎么管理，如何才能管理好呢？

4.2 钱包需求分析

对于没有支付牌照的广大租车SaaS平台来说，主要是通过接入第三方支付的方式提供交易见证和资金担保服务，而为了弱化第三方支付，平台往往会采取自建钱包的方式，为商户提供会员账户服务，其本质还是基于第三方支付账户封装出来的钱包应用。

钱包的性质是一个虚拟电子账户（管理电子货币的金融工具），核心功能是管钱和支付交易，底层就是账户能力，比如认证绑卡、支付、提现等。

商户开通钱包后，业务收入即时入账钱包，资金流水有账单核对，钱包余额实时可查，余额提现灵活高效，账目和资金尽在掌握！

4.3 钱包设计方案

首先，梳理钱包的业务流程。

其次，设计钱包的产品架构。

（1）钱包账户设计

钱包底层是账户能力，那就必须得稳定可靠，轻便灵活，要充分考虑业务场景需求（比如考虑收支分离、营销等）去设计账户体系。下图是平台与第三方支付合作共建的账户体系，在此基础上平台包装钱包账户，采用一个钱包账户多个余额的模式，目的是满足业务应收应付和实收实付分离的场景诉求。

（2）钱包主要功能分解

根据钱包业务流程，主要实现开户、资金处理、银行卡管理、信息查询等主要功能。

（3）钱包资金流设计

根据费用类型记录钱包入账及资金变动过程。将业务的记账请求通过入账和冻结规则处理，进入账户系统并生成账户流水，然后更新钱包账户余额。

最后，输出产品需求方案。

（1）钱包产品前端原型

前端即钱包的用户端界面，面向商户，主要实现钱包的开通、余额及账单查询，以及提现或充值操作等。在满足基础功能的同时，更多是体验，比如如何让开户流程更简单顺畅，资金更快到账，账目清晰准确等。

下方是钱包开户的流程：包括企业（平台商户）身份校验（企业工商+法人实名认证）、银行账户认证（支持对公账户、对私账户）。

下方是钱包余额和提现页面：

下方是账单列表和详情页面：

（2）钱包产品后端原型

后端即钱包的管理端界面，面向平台，主要实现查询钱包开通记录、钱包流水和余额等。

下方是钱包账户列表：记录所有商户钱包的开通结果，包括账户的基本信息，所属主体，钱包余额等内容，还可联查账户流水明细。

下方是钱包流水列表：记录所有商户钱包的资金变动明细，包括对手账户、收支方向、金额、费用类型等基本信息。

钱包的出入账原则是支付成功才入账，扣账成功才出款。比如用户成功支付租金后，这笔费用会实时入账商户钱包，记录为冻结余额，在交易双方签署合同且用户提车后，才会将租金分账给商户，则这笔费用由冻结余额转为可用余额，可用余额可提现。

注意：租车押金属于担保资金，不属于商户应收，所以支付成功不入账商户钱包。

05 旅游门店-钱包

旅游门店系统，由于过往业务发展快，为了配合业务发展，系统的钱包设计没有区分各个交易场景，所有收入支出都很混乱，不利于门店对账。原有的钱包设计可拓展性低，也无法在原有基础上改造，因此需要重新设计开发一款钱包体系。

5.1 钱包需求分析

旅游门店系统的用户是门店负责人或门店员工，主要用于门店日常支付订单、门店日常规范管理（如支付员工工资等），该系统承担用户充值资金、支付订单、冻结资金、支付员工工资及提现等功能。

为了解决门店对账的痛点，我们做了2大点的设计：按资金用途给门店设计不同功能的钱包；根据各业务场景，结合上游订单系统、下游财务结算系统，设计输出一套钱包流程。

（1）钱包分类

资金钱包：用于门店订单的支付，支持充值、提现。

利润钱包：用于门店日常经营管理时的支出，如门店员工工资等，支持提现，不支持充值，仅支持门店正常的利润流转。

（2）钱包功能

根据业务场景来设计。门店加盟后，系统会为其开通钱包，开通后即可使用。

钱包开通：门店只需要签约成功，即可开通钱包，因前置加盟时已做相关校验，此时无需其他校验。

日常使用：如上所述，门店日常使用细节划分如下：

5.2 钱包产品方案

（1）钱包开通

若门店已签约成功，正式开户，自动开通门店钱包。

（2）钱包充值

如上所述，充值有3个场景。一个是客人直接支付卖价、一个是门店充值、一个是分公司管理人员调账（因流程简单，上图并未画出）

客人支付卖价：

客人去门店后，若决定在该门店下单，则会先行支付给门店卖价。客人可以通过微信、支付宝等方式进行扫码支付，输入价格后，系统调取银联，客人直接支付好后，会立即充值至门店的资金钱包。

门店发起充值：

门店的支付方式有多种，银联扫码、POS刷卡、转账充值等。管理人员会在后台配置每种支付方式是否需要审核，是否需要支付手续费，谁来支付手续费等。如转账充值，需要管理人员审核公司是否收到转账，若收到了，需要管理人员操作审核通过，方能将资金成功充值至门店的资金钱包。

管理人员调账：

因为这个场景是管理人员直接操作，所以无需审核，操作成功后，会直接充值至门店的资金钱包。

（3）钱包扣款

资金钱包扣款也有多种场景，一个是门店支付卖价，一个是门店提现，一个是管理人员操作扣款。

门店支付卖价后，系统会将卖价部分从资金钱包扣下，并冻结，底价部分用于支付供应商，利润部分保持冻结状态，直至达到条件后解冻。

门店提现的操作，需要门店发起提现申请，由门店的管理人员去审核，管理人员审核通过后方可退款。需要注意的是，当门店提交申请时，此时也会产生资金冻结，这部分资金不可再用于其他用途。

管理人员操作扣款，仅是资金钱包扣款，并不会有其他系统动作。这种场景主要是门店人员线下与管理人员进行协调后，管理人员操作的。

5.3 钱包产品架构图

钱包系统会需要承载钱包的各种信息，以及跟各种业务系统进行交互，交互时会有自己的场景出现，比如充值、支付、提款等。这些看似不大的场景，也需要根据底层的一些配置来判断流程需要怎么走。

5.4 钱包产品原型

（1）门店端

门店端查看自己钱包的信息（包括资金钱包和利润钱包），也可以在下方查看各个钱包的流水。

（2）管理端

管理后台可以看到多家门店的钱包信息以及汇总数据。

钱包系统的设计需要结合收银台系统的设计，二者相互影响。更需结合业务场景，需要深入业务场景去调研，不可对业务说明的场景言听计从，需要刨根问底，多问为什么，为什么有这样的业务场景，为什么不可以有其他那样，参考别人的做法，多思考别人是怎么做的。否则系统一旦上线后，出了结构性的问题，改起来十分复杂。

06 食堂钱包设计解析

食堂钱包（以下简称钱包）是企业为员工建的一个虚拟账户，员工可通过钱包在食堂消费。钱包支持企业为员工注册、注销钱包，打入餐费补贴。员工可通过线下方式向钱包充值、食堂消费、员工间转账、提现操作。以下主要从员工钱包侧进行说明。

6.1 钱包主要流程

（1）钱包注册、注销

员工办理入职手续后，人力资源将新入职员工的工号、姓名、手机号码等基础要素提供给钱包业务系统，开通员工钱包。

员工办理完离职手续及将账户中的金额提取出来后，人力资源系统会调用钱包注销能力，进行钱包注销。

（2）钱包充值

入职初期或钱包没钱，员工想使用食堂钱包进行消费，需联系管理人员，线下通过现金、微信等方式支付充值金额给管理人员，管理人员通过钱包系统，为该员工进行充值。

入职后的每个月月初，ERP根据员工的出勤情况及补贴标准，计算出公司员工的补贴金额后，调用钱包系统的充值能力，为员工的补贴钱包充值。

（3）员工间转账

支持员工间的转账，但不同类型的钱，会转到不同类型的钱包，比如充值进来的钱，转账时，也会进入收款方的充值钱包；补贴钱包中出来的钱，转账时，会进入收款方的补贴钱包。

（4）钱包提现

员工需要将钱包中的钱提出来时，若是充值进去的钱，可直接申请提现，通过银企直联的方式，将钱打入到申请人银行卡中；若是公司的补贴的钱，则需要通过ERP报销的方式，提供相应的发票，才能将金额提现到银行卡中。

（5）钱包消费

员工在食堂消费时，可通过主扫或被扫的方式进行支付，扣款时，根据员工自行设置的扣款优先级进行扣费，一般默认有限扣补贴钱包的钱。钱收到商家钱包后，企业通过月结的方式给商家提供结算单，商家确认结算单没有问题后，通过银企直联给商家打款。

6.2 钱包功能结构图

钱包主要分成3个系统，分为钱包业务系统、员工钱包和商家钱包，钱包业务系统用于钱包各方面的管理，及单据查看；员工钱包提供给员工使用，主要提供钱包余额查看及消费，另外提供充值、提现等操作；商家钱包提供给收款商家使用，主要为商家提供钱包余额、交易流水、确认结算单的操作。

6.3 产品原型

（1）员工钱包页面及交易明细

（2）商家钱包管理页面及提现页面

07 高速ETC钱包建设

曾经网上有人发起一个帖子，征集移动互联网带走了哪些行当。其中有人说了一样东西，钱包。确实现实中的钱包已经被大多数人遗忘了，而手机里的钱包则天天在使用。回忆类比现实中的钱包，其实主要作用就是用来装钱、装银行卡、以及各类卡和券等。需要交易支付的时候，则把钱包掏出来付款，通过现金或者刷卡等形式。

咱们手机里的钱包，无非也是这些个作用。

7.1 钱包需求背景

作为一家高速ETC发行企业，用户钱包的建设也是很重要的一个环节。由于过往业务快速发展期间一切为了求快，钱包只是简单地建了一张表，把身份证等用户信息放进来，再加多几个字段标识余额等金额，就上线使用了，但是该钱包模块拓展性低，已经无法继续支撑业务发展，因此需要重新设计开发一个拓展性高的钱包体系。

7.2 需求描述与分析

高速ETC的用户往往是司机或运输行业的企业，因此该钱包系统承担着用户存放通行路费和冻结押金、支付路费和提现等主要功能。

要规划好该钱包系统，先从以下2方面的思考入手，即根据不同的业务定义出我们所需的钱包类型和；以及根据不同的业务场景规划钱包系统的功能。

（1）钱包类型

钱包类型如何定义，需要基于实际业务需求来进行规划。

首先用户需要存钱用于扣路费，名正言顺“ETC钱包”必不可少。

基于风险角度考虑，有必要针对用户不同的风险行为，此时就需要一个“押金钱包”，并考虑是否根据不同的风险行为下挂不同的子钱包。

出于营销层面，对用户发放路费补贴金和奖励金，这些金额是不能被提现的，因此有必要设置一个“ETC红包”用于区别用户真实充的钱。

营销升级之后还会给用户发各种卡券，则需要一个“券包”，他不是记录某个金额数值，而是记录营销中心发给用户各种各样的券。

（2）钱包功能

规划系统功能的时候，有几个方向可以进行分析和打开思路：直接参考竞品；对标实体物品；以及根据业务流和场景去规划。

下面根据业务流和场景来规划。

钱包开通：

日常使用：

日常我们使用钱包，无非就是看看还剩多少钱；放钱、放卡；拿钱、刷卡付款；以及钱包弃用了把钱抽走等，我们对应一一分析。

7.3 需求方案

本次方案ETC钱包、押金钱包、ETC红包以及券包4个钱包都需要，但为了降低开发复杂度，暂不规划押金的子钱包，代价是缺失了押金相关的灵活性，比如想要统计违约产生的押金就只能去实时跑流水。

其次功能层面提供统一的钱包开通、充值、扣款和前台的对应查询功能，其余功能暂不开发或沿用旧有系统。

（1）钱包开通

钱包的开通上游依赖于业务层的用户进件，而且这里需要考虑是否区分企业和个人，以及对用户的实名验证问题。

钱包开通前校验：

该用户是否已存在钱包且未注销，防止重复创建钱包；入参的信息是否合法，如身份证、手机号。

（2）钱包充值

钱包充值可以说是用户侧最重要的功能，用户没有充值则钱包没有余额，那么就无法用钱包进行有效扣款。

设计钱包充值的流程时，一定要确认了用户真正支付成功之后再处理账户插入流水和加钱，切记顺序不要颠倒过来，否则容易给用户“免费充值”；

其次为了避免通道侧回调不及时或者网络错误等原因，导致用户实际支付成功，但却充值失败没到账。因此需要对没有获取到最终支付状态的充值订单设计补偿机制，如定时轮询，成功后通知账户侧后续流程。

（3）钱包扣款

由于业务定位原因，钱包的扣款仅支持系统扣路费，暂不支持用户主动发起其他扣款。

与钱包充值刚好相反，进行钱包扣款的时候，切记要先处理完钱包之后，再返回给业务侧扣款成功，否则如果业务侧收到扣款成功之后，钱包的处理报错，则相当于免费给用户做嫁衣，如若当批量出错的时候，后果将不堪设想。

体现在高速ETC场景就会导致用户该扣的通行账单全部是扣款成功，但是钱包余额未减，用户无限通行，企业无限垫资亏损。

7.4 产品架构图

钱包的产品架构，底层对支付系统输出支付相关的能力，并规划钱包信息、银行卡和卡券子模块串联起整个钱包模块。

钱包的开通依赖于用户系统的主体信息，实名认证则通过外部实名通道，支付和卡券系统给钱包加钱扣钱、发券核券，一个基本的钱包架构就完善起来了。

7.5 产品原型

前台主要提供余额查看、充值以及调整扣款顺序的功能。由于该产品用户偏向40-50岁的中年人，而且载体是微信小程序产品，因此页面设计偏向微信风格。

另外考虑到一些用户会等到欠款才来充值还款，导致已经被高速限制通行了，因此我们在充值页面除了默认帮用户选中合适的金额之外，还会提示用户还钱欠款后需要等待24小时才能解除通行限制，这就是有“场景感”的设计，同时也能减少一部分不必要的客服咨询。

扣款设置页面，借鉴长按拖拉调整顺序的交互。这里额外说明一点，调整成功后页面最好给一个提示说明，强化用户感知。

管理后台主要设计钱包列表，以供客服和运营人员查看相关信息。

考虑到数据安全和后期数据量会巨大的问题，页面加载的时候可不展示任何信息，需操作人员输入一定的查询条件之后再根据查询条件展示相关的钱包。

其次企业交易量比较大，钱包交易流水每月可达千万条数据量，需要和开发大哥提前沟通规划好分表，再根据分表考虑查询功能的设计，不然当数据量大的时候查询会很缓慢，直接结果就是产研被吐槽（因为其他人是无法理解这种数据量大的问题的）。

页面的交互采取点击对应钱包的余额字段，则跳转或弹窗展示对应钱包的流水，这种交互适合客服人员针对性查看，但是不适合运营和财务去拉取流水统计数据。

钱包系统的设计，除了规划功能之外，需要设计什么类型的钱包也是至关重要的，这决定了后续业务功能拓展的难易程度。不同行业具有各自业务的差异性，如果照着正统的支付行业来设计钱包也许会水土不服。作为产品经理，还是要多结合各方知识，加以吸收和思考之后回归业务，结合场景，才能设计出和合适的产品。

08 线下游乐-用户钱包

线下游乐指的是诸如电玩城、真人CS、密室逃脱等依托线下实体的休闲娱乐场所。此类休闲娱乐场所出于快速回款以及营销需要普遍会提供会员卡业务，用户加入会员并进行预充值就可以用会员价购买商品或服务，达到用户获得优惠、商家获得盈利的双赢局面，这里的会员卡其实就是一个简单的钱包。

在“品牌方-加盟商-用户”的模型下，一般会由品牌方提供及维护加盟商日常运营中所需要用到的在线操作系统，会员就是其中的一部分。为了快速开展业务，品牌方一般会在初期采用点对点的系统交付方式，即虽然给所有的加盟商都是使用的同一套系统，但是各个加盟商之间的数据不会打通。拿会员卡举例就是可能存在一个用户拥有多个加盟商的会员卡的情况。

为了满足现代化的实体门店运营，需要保证用户能在线上线下都便捷的享受到会员服务，那么从会员卡的注册到会员卡的充值、消费等都需要考虑到线上、线下两个场景都能正常运转业务且数据是互通的。同时，为了吸引顾客充值，除了享受会员价外还有一种有效的促销手段就是充值余额赠送积分（积分可直接用于消费），于是会员卡需要支持多种账户余额和流水的查询。