本篇文章将以钱包业务流程设计为例,分析在面对分散、用户体验较差的业务时,该如何设计一个便捷、灵活的钱包业务,接下来,我们看看作者的思考。
(资料图)
这是一个非常实用的案例,并且,案例涉及面比较广,可以培养对整个钱包、账户、提现业务的认识,同样,也是一个可以拿来即用的产品方案。
一、一提多户的局面
很多公司会存在多条业务,这时候有些公司每个业务线都会有一个钱包业务,这样就造成了商家端钱包的分散。
一个商家在每个业务线都有一个钱包,分别管理余额、提现、绑卡、支付密码等,资金管理体验比较差。
此时,就可能要对各业务线的钱包进行统一,统一以后商家仅需管理一个钱包,绑定一张卡、设置一个密码,一次完成多账户的同时提现,提高资金管理效率,提升商家的结算体验。
此时,钱包的提现就就 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 数据。
所以,为了释放账户的压力,让账户专心做自己资金管理的职能,将一些处理事务交给清结算系统去做,包括对账户余额的加工处理,以及提现余额的分配计算。
四、怎么解决一提多出的问题
因为钱包只发起一笔提现请求,但是,最终要扣多个账户,出多笔资金。
那么,这个从一提到多出的处理由谁来实现,也就是一笔提现变多笔提现。
因为是提现业务,所以我们选择让提现处理系统来完成对提现的拆分。
也就是钱包发起提现时,会请求清算系统对提现金额进行分配计算,然后得到计算结果,并封装成提现数据提交给提现系统。
钱包提交的提现请求数据结构如下:
提现请求 ID
提现金额 X
提现明细 { 子提现请求 1,子提现请求 2} 由提现系统对提现请求拆分成两笔提现:提现 1,提现 2,分别请求清算系统进行提现扣款处理。
这样我们得到如下的业务流程:
五、把业务架构画出来,看看全局
我做方案喜欢搞这么个玩意,让我心有乾坤人不慌,看看整个业务所涉及的范围,以及每个环节要承载的任务。
通过上图,我们就可以看清楚做这件事所涉及到的环节,以及要实现的能力有哪些,谁来做什么?
专栏作家
陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;专注为 10 万支付产品经理和支付机构以及企业提供深度支付内容和服务!
本文原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议。
头条 23-07-09
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-08
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07
头条 23-07-07