本篇文章将以钱包业务流程设计为例，分析在面对分散、用户体验较差的业务时，该如何设计一个便捷、灵活的钱包业务，接下来，我们看看作者的思考。
这是一个非常实用的案例，并且，案例涉及面比较广，可以培养对整个钱包、账户、提现业务的认识，同样，也是一个可以拿来即用的产品方案。
很多公司会存在多条业务，这时候有些公司每个业务线都会有一个钱包业务，这样就造成了商家端钱包的分散。
一个商家在每个业务线都有一个钱包，分别管理余额、提现、绑卡、支付密码等，资金管理体验比较差。
此时，就可能要对各业务线的钱包进行统一，统一以后商家仅需管理一个钱包，绑定一张卡、设置一个密码，一次完成多账户的同时提现，提高资金管理效率，提升商家的结算体验。
此时，钱包的提现就就2个核心问题要解决：
接下来我们做的就是解决这2个核心诉求。
以上的诉求，我们可以转换为“钱包的余额查询、提现预加工的支持”这样两个更明确的诉求，其中有几个关键点要想明白。
1）可提余额并不一定等于账户可用余额的总和
因为有提现手续费的存在，导致个别账户可能不满足最低提现金额要求，所以说可提金额不一定等于可用余额的总和。
就比如一个账户里只有2毛钱，而提现手续费要5毛，那就无法完成提现。
上表示例中主体001的可提余额计算结果=11.5元。
因为账户3中的0.8元不满足最低提现要求，所以不可提。
实际可提金额=1.5+10.00=11.5元
因此，钱包余额12.3元，可提金额=11.5元。
2）可提余额不代表用户要提的金额
因为他可能只选择提取其中的一部分，所以要计算这部分金额应该如何分配到账户；除非让用户选择那个账户提多少，但这样就失去了统一钱包的意义了。
3)如何制定一个提现金额的分配策略
有很多种方法，可以做得简单一些，比如就设定一个固定的顺序，ABC的顺序进行扣款。
也可以做成综合的策略，比如如果一个账户就够了，那就只出一个账户，如果多个账户都够了，那就按照顺序扣款等，不过这样的算法成本会增高，可能带来的效果并不明显。
如例：可提金额是11.5；此时用户仅提现“8元”，该怎么处理，根据提现扣款顺序的设定，如上表所示；顺序代表扣款顺序。
实际扣款如表最后一列：账户1扣1.5，账户2扣6.5。
用户每输入一次提现金额，就执行一次预计算，并实时反馈给用户。
因为底层是多个账户，每个账户都有总余额，可用余额，可提金额等信息。
那么当钱包要查询账户余额信息时，对底层账户余额进行加工汇总的任务谁来完成？也就是以下三个公式：
钱包N总余额=账户A余额+账户B余额+账户C余额
钱包N可用余额=账户A余额+账户B余额+账户C余额
钱包N可提余额=账户A余额+账户B余额+账户C余额
无外乎有3种处理方法：
如上图所示，箭头代表余额数据的查询，123代表明细数据，N代表处理过的数据，最后选择清算系统来做（绿的箭头），此时清算系统查询到123明细数据，输出给钱包的是N汇总数据，并且包含了明细123数据。
所以，为了释放账户的压力，让账户专心做自己资金管理的职能，将一些处理事务交给清结算系统去做，包括对账户余额的加工处理，以及提现余额的分配计算。
因为钱包只发起一笔提现请求，但是，最终要扣多个账户，出多笔资金。
那么，这个从一提到多出的处理由谁来实现，也就是一笔提现变多笔提现。
因为是提现业务，所以我们选择让提现处理系统来完成对提现的拆分。
也就是钱包发起提现时，会请求清算系统对提现金额进行分配计算，然后得到计算结果，并封装成提现数据提交给提现系统。
钱包提交的提现请求数据结构如下：
提现明细{子提现请求1，子提现请求2}由提现系统对提现请求拆分成两笔提现：提现1，提现2，分别请求清算系统进行提现扣款处理。
这样我们得到如下的业务流程：
我做方案喜欢搞这么个玩意，让我心有乾坤人不慌，看看整个业务所涉及的范围，以及每个环节要承载的任务。
通过上图，我们就可以看清楚做这件事所涉及到的环节，以及要实现的能力有哪些，谁来做什么？
专栏作家
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。