惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
V2EX
博客园 - 叶小钗
WordPress大学
WordPress大学
N
Netflix TechBlog - Medium
M
MIT News - Artificial intelligence
美团技术团队
aimingoo的专栏
aimingoo的专栏
博客园_首页
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Microsoft Security Blog
Microsoft Security Blog
Last Week in AI
Last Week in AI
The GitHub Blog
The GitHub Blog
小众软件
小众软件
T
Tailwind CSS Blog
Martin Fowler
Martin Fowler
B
Blog RSS Feed
月光博客
月光博客
量子位
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Hugging Face - Blog
Hugging Face - Blog
IT之家
IT之家
Y
Y Combinator Blog
B
Blog
MyScale Blog
MyScale Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
一户多卡,钱包账户
刚哥 · 2025-01-05 · via 人人都是产品经理

在支付领域,钱包账户的设计与实现是构建高效、便捷支付体系的关键。本文将从钱包架构、一户多卡模式、余额与账户关系,以及钱包账户交互等多个维度,深入剖析钱包账户的核心要素与运作逻辑。

引子:老板要做个支付宝

我听过很多老板画的饼,最有意思的一个就是我们要做这个行业的支付宝。记得一次和公司总裁参加一个银行的商务交流活动。说到与银行的合作,总裁就兴奋起来了“我们要做这个行业的支付宝,通过你们银行的金融服务可以给会员提供零钱账户在我们平台消费,不用的钱给会员购买理财,大额消费可以用银行的消费分期。。。。”巴拉巴拉一大堆,我也在旁边随声附和着。

会后有另一个同事问我“老板要做个支付宝,我看你一直在帮着老板接话,你知道怎么做了?”(由于总裁是我们这个业务线直属最大的领导,所以我们都叫他老板)

我说:“老板就是想搞个营销活动薅银行的羊毛,会员那开个营销入口,用一户多卡模式去绑定银行的金融产品就行了”。

同事说“不是吧,老板说的很大的规划呀?”

我说“你真要去做个支付宝出来,得把老板吓得中风了。支付宝钱包可不是一个简单的钱包,而是一套牌照和一系列的金融系统,你给老板做破产了也做不完”。

其实,听话要听其核心目标,就像这里的对话中,总裁主要就是消费、理财、分期等几个金融产品如何服务客户,银行能够提供多少营销费用。

当然我今天不是给大家介绍怎么做个支付宝,而是介绍怎么通过一户多卡来实现钱包的扩展功能。

一、钱包架构

钱包从架构层面的划分上来说就是对会员和账户能力的一层可视化展现,通过核心能力的包装钱包展现出了千变万化的场景适应能力。

1.1 业务架构

图 1钱包应用架构(持牌机构)

钱包应用通过对网关和收银台的包装为用户提供了从注册、登录、商业应用、金融产品等一系列的服务。

1、钱包应用

为了构建这样的钱包体系,分为C端和B端都需要在支付体系内开户。

1)C端应用:用户提供账户和钱包支付能力。

2)B端应用:为场景提供方,为用户提供营销卡券、生活类应用和金融服务。

2、账户体系

为了实现资金在平台内的流动,就需要开出对应的中间科目。通过这些中间科目清算不同商业主体之间资金流转。当然这里的账户之间的清算在我国是监管很严的。现在普遍通过收银台跳转到持牌机构的方式为用户提供金融服务。这样账务中心也就逐步减少这些中间科目了。

1.2 集成关系

图 2钱包集成关系

从集成关系就能看到,钱包应用就是一层可视化的前端应用,他包含了开户登录和交易功能的集成。

1)开户登录

开户过程涉及实名认证、密码设置、银行卡绑卡等,用户的身份信息会都要保存到会员系统内。用户下次登录和交易是可以直接通过这些信息对用户身份进行验证。

2)交易功能:

钱包的交易功能通过跳转收银台或者直接API访问来进行充值、提现、转账以及消费。

1.3 一户多卡

以上介绍的都是最基础的钱包功能,如果要实现一个支付宝一样兼具银行卡、账户、理财、分期支付功能的钱包产品呢?这里就要介绍到一户多卡的模式了。

所谓的一户多卡,定义如下

1.3.1、一户:

内部的余额账户为“户”,通过一个主账户来保障消费者与平台内商户基本的消费交易。

1.3.2、多卡:

外部合作账户被称为“卡”,当主账户余额不足时,系统会自动通过已绑定的银行卡进行支付。理财账户和分期账户同样采用绑定银行卡的方式进行管理,并且在支付时会跳转至合作机构的收银台以完成交易。

图 3一户多卡领域模型

1.3.3、两种清算方式

要实现一户多卡的模式,其实对资金的结算能力有很高的要求,因此可以有两种资金清算方式;

1)中间科目清算:

通过一家全牌照机构合作,实现账户、银行卡、理财、分期产品的合作,通过银行开通多个中间科目来实现金融产品间的清算。

这也是支付宝最早的模式,随着监管的加强,这种混业经营模式也不再被允许,需要隔离不同金融产品之间的清算。所以普通机构、商户只能与银行开展。

2)合作机构直清:

就是与银行的Ⅱ/Ⅲ类户、理财账户、信贷分期产品合作,然后相关的商家在银行开户,银行给商家提供给直接清算的服务。由于这种模式需要平台内的商户去银行开户,因此这种模式普通用于营销活动当中,并不是一个稳定的钱包生态体系。

1.4 核心流程

图 4钱包账户核心流程

钱包账户是基于应用场景来流转的,它在用户使用过程中逐步地引导用户完成注册和实名认证。

1)快速注册:为了快速的获客,钱包通过简单的短验、联合登录或登录密码就能快速开出会员账号,让用户登录使用。

2)实名开户:用户在钱包使用过程中引导用户进行实名认证,并开出对应的账户。

3)转化服务:通过广告、领券、消费过程中的营销让用户完成开卡、分期和零钱理财等产品升级服务。

二、余额与账户关系

2.1 会员与账户映射

图 5会员钱包应用

这类属于支付机构直接提供的钱包账户,他与底层的资金账户是直接映射的关系。这种余额使用简单清晰,也能很好地进行会计账务处理。

2.2 多种余额形式

一般情况下余额都是对账户余额的直接展示,一些钱包为了适应场景的特定需求对余额进行了定制化的包装。以下的的案例都是在会员和资金账户基础上做的一层额度的应用包装。

图 6钱包余额的多种形式

2.2.1 提现额度

例如微信、支付宝为了提高用户资金的留存和减少手续费支出,增加了一层提现额度的控制。系统要按照提现额度的规则,准实时的累计金额,并扣减用户的提现额度来实现“可提余额”的管理。这种实现比较简单,提现时计算下可提现余额就行了,放在钱包应用或限额管理模块都可以。

提现额度控制

1)可提现=Σ年提现额度2.2.2 交易账户:

交易类账户用户比较关注资金提现到账,而平台希望平台内的资金可以被最大化使用。因此就有了“待结算资金可用,但不可提现”的需求。

因此这里的可用余额需要重新包装“可用余额、可提余额、在途余额”。

交易账户余额公式

1)钱包总金额=可用余额+可提冻结+在途冻结

2)可用余额=可提余额+待结余额

这种模式最简单的实现方式就是,由钱包应用来做余额包装,向交易系统下单的时候分别来传送对应的账号完成账务处理。当然配套的交易层面和账务系统也要进行改造,避免很多的过多的交易订单呈现给用户造成困扰。

2.2.3 多维账户

我们很多钱包像支付宝一样有很多的账户,例如有支付账户、理财账户、融资账户等。这些都是通过会员账户与外部账户建立关联关系,然后在钱包层面分开展示即可。(这块了解即可,详细内容我们后面单独文章介绍)

三、钱包账户交互

3.1 钱包注册交互

为了能给用户有良好的体验,个人钱包开户可以先注册开通一个会员账号,需要账户充值的时候再开户。

图 7钱包注册与登录

用户在注册时需要调用短信通道验证手机有效性,然后就能生成一个会员号,并让用户设置登录密码,这样用户就能浏览APP和网站上登录了。在用户需要支付的时候再引导用户开户,为用户提供了良好的支付体验,

3.2 钱包开户交互

用户开户过程还是比较复杂而繁琐的,因此可以通过营销活动来引导用户开户。

图 8钱包开户流程

用户开户过程需要提交个人实名信息,身份证,并且要进行人脸与身份证的比对,确保是用户本人。开户过程中用户还要设置一个支付密码,与登录密码不同的是这个密码是专门用于支付的。

图 9支付账户实名等级

支付账户也有类似银行Ⅱ/Ⅲ类账户的认证等级,最低是L1账户,最高是L3账户。一般给个人开通的都是L2账户,通过手机号、身份证、银行卡三类外部通道来完成实名认证。

用户填写基本用户信息后,会通过“认证渠道”对用户的手机号、身份证进行实名认证。通过后会引导用户绑卡,这样就达到了L2的账户等级。随后通过加密平台生成支付密码串将其保存在会员系统,最后调用支付核心完成L2账户的开户。

四、钱包支付交互

4.1 钱包充值

图 10充值交互流程

用户向钱包充值,输入金额并选取支付方式,随后输入短信验证码后提交支付,随后系统跨行完成收款并展示支付结果。

4.2 钱包提现

用户提现时需要展示用户可提现余额,用户输入密码后选择绑定的同名银行卡并输入密码后提交,系统验证密码无误后,通过支付系统扣减客户的余额,并向开户银行完成支付。

图 11提现交互流程

4.3 钱包转账

钱包转账分为转账到卡和转账到户,其中转账到卡与提现相同,知识不判断同名,因此我们这里来介绍下转账到户。

图 12转账到户

用户通过查询或者输入对方账号找到交易对手,输入金额后并提交,支付系统验证密码,然后完成收付款人账户之间的余额转账。

最后:做个像支付宝的钱包

钱包本身只是一个可视化的界面,通过页面和交互的包装让后台的能力释放出来给客户使用。并且现在金融服务也很成熟的了,虽然做个完整的支付宝不太可能,但是通过巧妙的包装做个像支付宝一样的营销钱包也不是很难。

本文由人人都是产品经理作者【刚哥】,微信公众号:【刚哥白话】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

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