知识吧 知识资讯 钱包“高阶”玩法 | 人人都是产品经理

钱包“高阶”玩法 | 人人都是产品经理

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

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

一、一提多户的局面

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

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

钱包“高阶”玩法 | 人人都是产品经理

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

钱包“高阶”玩法 | 人人都是产品经理

此时,钱包的提现就就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 协议。

该文观点仅代表作者本人,知识吧平台仅提供信息存储空间服务。



本文来自网络,不代表知识吧立场,转载请注明出处:https://zhishiba.net/6325.html
上一篇
下一篇

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

返回顶部

Warning: error_log(/www/wwwroot/www.zhishiba.net/wp-content/plugins/spider-analyser/#log/log-2403.txt): failed to open stream: No such file or directory in /www/wwwroot/www.zhishiba.net/wp-content/plugins/spider-analyser/spider.class.php on line 2900