您当前的位置: 首页 >>  新闻资讯 > 内容页

钱包“高阶”玩法

时间:2023-07-09 08:37:05    来源:人人都是产品经理

本篇文章将以钱包业务流程设计为例,分析在面对分散、用户体验较差的业务时,该如何设计一个便捷、灵活的钱包业务,接下来,我们看看作者的思考。

这是一个非常实用的案例,并且,案例涉及面比较广,可以培养对整个钱包、账户、提现业务的认识,同样,也是一个可以拿来即用的产品方案。


(相关资料图)

一、一提多户的局面

很多公司会存在多条业务,这时候有些公司每个业务线都会有一个钱包业务,这样就造成了商家端钱包的分散。

一个商家在每个业务线都有一个钱包,分别管理余额、提现、绑卡、支付密码等,资金管理体验比较差。

此时,就可能要对各业务线的钱包进行统一,统一以后商家仅需管理一个钱包,绑定一张卡、设置一个密码,一次完成多账户的同时提现,提高资金管理效率,提升商家的结算体验。

此时,钱包的提现就就 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 元 ",该怎么处理,根据提现扣款顺序的设定,如上表所示;顺序代表扣款顺序。[page]

实际扣款如表最后一列:账户 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 万支付产品经理和支付机构以及企业提供深度支付内容和服务![page]

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

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

标签:

招募

精彩推送

X 关闭

X 关闭