支付实战：红包与钱包设计

掌握了理论知识以后，应用于实践是对理论考察的最佳手段，我们以红包和钱包设计为实际案例，了解支付中架构和逻辑设计应用

全文6000字，建议先收藏慢慢看

1

“红包”产品设计

发红包，领红包；普通红包，拼手气红包；想必在用户应用层面大家都不陌生，但是红包底层的支付流程以及红包算法规则，涉及的支撑系统，估计很多人不知道了，今天我们就讲一下“红包”背后的秘密，教你如何设计一套红包体系

1.1什么是红包

红包对于用户来说更多的是一种娱乐手段，生活工具；对于企业来说更多是一种营销手段；微信红包是大家最熟悉的了，像钉钉，脉脉等很多应用内部都有红包功能

红包本质上是用户虚拟账户之间的“转账”能力；一个用户的账户扣一笔钱，然后拆分后转给多个账户；至于每个账户转多少金额，就是红包金额的算法，普通红包简单，平均总金额就行；拼手气红包稍微麻烦，既要保证红包最低金额，又要保证金额随机。如图1所示

图1 红包发放的账户处理

已经领过的不能再领，过期的红包不能再领且要退回发红包的账户，今天我们重点说说个人红包的设计方法

1.2红包种类

（1）个人对个人类型

指定单个对象：金额固定

不指定对象（单个/多个）：群红包，金额随机或均等金额

（2）企业对个人

企业发送给个人的红包可以是随机金额或者固定金额

1.3红包体系涉及到的系统

前端应用：用户发放领取的前端展示页，收银台等

订单系统：红包的支付订单，用户领取后的转账订单

账户系统：金额查询，红包余额的转出转入

营销系统：红包规则创建，查询，比如发了多少个，什么类型的红包等

运营系统：查看管理红包发放和领取记录

每个系统都会有单独的文章详解，这里不做介绍；默认读者所有系统全部熟知，有不熟悉的系统可以去支付专题查找相关系统进行阅读

1.4红包功能框架

图2 红包功能脑图

1.5红包业务流程

重点讲解各个红包类型不同场景下的发放和领取流程

（1）指定用户-一对一场景

主要是在一对一聊天场景，发红包给朋友，相当于指定了这个某个用户领取红包，如图3所示

图3 指定用户发红包流程

发送用户1状态：用户1状态必须为已实名；

接收用户2状态：需指定用户，前端需传输用户2的userid

余额支付：用户1使用余额支付时，用户2未领取前，发送金额以冻结状态存储在的资金账户中；

绑卡支付：用户1使用银行卡支付时，支付金额会先充值到1的资金账户中，并冻结该资金。

领取(红包状态为可领取）：用户2确认领取后，解冻1资金后通过转账，入账至2的资金账户中；

退回：用户2到期未领取，发送金额解冻后，遵循原路退回原则，退回用户1；

用户1撤销发送：只要用户2未领取，均可解冻资金并退回资金。

（2）不指定用户

可以不指定发放一个，也可以发放多个，根据设置的红包数量确定，如图4所示

图4 不指定用户红包发放流程

字段说明

发送用户：1；

接收用户：n(n=2,3,4…)；

发送红包数：K；

发送总金额：M；

关键点说明

发送用户1状态：用户1状态必须为已实名；

接收用户n状态：领取时n状态不需要为已实名。不需指定用户，从设置的发送红包数/可领取人数K确认，是对单用户还是多用户场景；

红包创建：资金冻结成功后，按照随机规则直接创建K个子红包。

支付

余额支付：用户1使用余额支付时，只要有用户未领取，剩余发送金额都以冻结状态存储在1的资金账户中；

绑卡支付：用户1使用银行卡支付时，支付金额会先充值到1的资金账户中，并冻结该资金。

1.6总结

好了，红包我们点到为止；我们来思考几个问题

底层服务至少给应用提供那几个服务接口，传参和出参应包含那几个字段？

发放红包使用中间账户和不使用中间账户有什么区别，那么方式更优?

你觉得微信红包的随机金额算法是怎么样的？

2

钱包的设计方法

钱包钱包，就是装钱的包，这个解释应该是最精准的了；但是谁说钱包只能装钱呢，装身份证行不行，装名片可不可以，装某人的照片是不是可行？一个不装钱的包还叫钱包么？这不是个哲学问题，这是个无聊的问题；今天我们就聊一聊有的聊的用户电子钱包设计

2.1什么是用户电子钱包

什么是钱包，我想大家第一感觉应该想到的是这样的，我觉得没有错，这就是钱包！！！很多时候我们要善于观察现实世界跟虚拟世界在某些维度上的共性

有些概念就是源于生活

什么是电子钱包，就是利用互联网技术手段实现数字货币线上管理的虚拟钱包，像微信钱包（如图5所示），支付宝钱包，以及刚刚推出的数字人民币钱包

电子钱包嘛，无非要满足2个条件，第一个是肯定是数字化的，第二点肯定是管钱的，既然管钱那么就必然有“多少钱的余额”“怎么变化的流水”

图5 微信钱包截图

2.2用户钱包的用途

钱包的用途最核心的一个就是管钱，另一个非常重要的用途就是用于支付交易；因为我们无论在银行还是三方支付机构的钱包更多的目的是用于结算或者支付，所以暂且认为钱包的核心目的是支付，如图6所示

图6 钱包用途

从另一个角度来看，钱包是一个金融工具，管理电子货币；并向用户提供充值，提现，转账，支付的交易支付能力

2.3用户钱包的底层能力

钱包的底层能力其实就是账户；钱包的表面无非就是个“皮”；如图7所示

图7 钱包的底层能力

账户我们前面的文章已经做了详细的介绍，这里我们重点站在资金属性的角度来重新看一下账户的分类

（1）银行账户

银行账户主要分储蓄账户和结算账户两大类，其中结算账户分类管理办法有更细的定义了结算账户的分类

2016年4月1日，《关于**个人银行账户服务 加强账户管理的通知》（银发〔2015〕392号）正式实施，建立了个人银行账户分类管理机制。根据开户申请人身份信息核验方式和风险等级，个人银行结算账户分为Ⅰ、Ⅱ、Ⅲ类。其中，Ⅰ类户为当前个人在银行柜面开立、现场核验身份的账户，具有全功能；Ⅱ、Ⅲ类户为通过银行柜面或者互联网等电子渠道开立的银行账户，具有有限功能，且需要与Ⅰ类户绑定使用。

（2）支付机构账户
支付机构也可以为用户开具虚拟账户，我们称之为支付账户，按照人行规定，支付账户做了如下的细分

2016年7月1日，人民银行《非银行支付机构网络支付业务管理办法》（中国人民银行公告〔2015〕第43号）正式实施，建立了个人支付账户分类管理机制。同样，根据开户申请人身份信息核验方式和风险等级，个人支付账户分为Ⅰ、Ⅱ、Ⅲ类。其中，Ⅰ类户仅需要通过一个渠道验证身份信息，开户便捷性最高，账户余额可用于消费和转账，但限额较低；Ⅱ、Ⅲ类户分别需通过至少三个、五个渠道验证身份信息，或者通过面对面方式核实身份，具有更高的余额**限额；Ⅲ类户的余额除了消费和转账外，还可用于购买投资理财产品。

注意：我们可以看到，银行结算账户有三类账户，支付机构的支付账户也有三类账户，要注意区分，不要搞混了

（3）自建账户

以上两种账户都是合规合法的，还有一种账户就是平台自建账户，当然这类账户就是虚拟记账，并不存有真实的资金（其实支付机构的支付账户真实资金也是被监管在人行备付金账户）；围绕这个自建账户我们也可以构建一个用户钱包体系

2.4钱包分类与区别

认为钱包的本质是账户，账户的本质是资金，所以我们按照账户里的资金属性来看，钱包如何分类

银行用户钱包，由银行基于银行结算账户体系构建的钱包应用，比如各个银行APP里的钱包

支付机构用户钱包，由支付机构基于支付账户体系提供钱包解决方案构建的钱包应用或者API经过商户封装后的钱包应用

数字人民币钱包，人行推出的数字人民币钱包

平台自建钱包，各个平台自己基于自建账户搭建的虚拟钱包应用

2.5如何选择钱包类型

考虑业务需要，成本，灵活性，合规性，其实我们有多种选择

接入三方支付机构钱包

接入银行钱包

自建钱包

因为接入三方机构或者接入银行的钱包，对方都会给完整的钱包方案以及接入文档，所以按照要求接入就行了，这里我们重点讲的还是钱包的前端应用设计以及必要的交易支付体系

2.6钱包的架构和流程

产品功能架构，说起钱包的架构，我们从用户到底层来看可以这么分层，如图8所示

图8 钱包产品架构

业务流程架构，这部分我们点到为止，不做过多介绍，由于涉及到的系统都有单独的详细章节介绍，如图9所示

图9 钱包涉及到的系统体系

用户使用流程，用户完成账号注册，账户开户，实名认证，设置密码后可以使用钱包的相关功能，如图10所示

图10 钱包的使用流程

2.7设计钱包的功能

钱包的核心功能主要有这个

注册，用户先注册为平台的用户获得用户的唯一身份ID，然后申请开通钱包功能，该钱包可以是平台自建，也可以是接入的三方支付，如果是接入的三方支付，那么按照三方要求传送用户信息以及开户申请，如图11所示

图 11 钱包的注册

实名认证，一般实名认证主要是2种一个是姓名和身份证实名，主要通过公安部的实名认证接口实现；或者通过三方支付的绑卡多要素鉴权实现认证；另一个是手机号，主要通过运营商的手机实名认证

绑卡/解绑，绑卡鉴权有现成的服务接口，接入即可，四要素的，三要素的，五要素的；如果是自建钱包只是为了验证银行卡可不可用，那么使用三要素即可；如果是接入的三方支付公司钱包服务，那么按照开的是几类支付账户进行鉴权认证选择即可；比如开三类支付账户那就需要五要素鉴权了

充值/提现，有了钱包就需要充钱，钱包不用了就需要把钱提出来；如果是自建钱包没接入任何一方的话，那么其实使用微信支付宝的收单通道就行了，做一个假的充值，提现的话就需要接入打款通道了，将资金付给用户；如果是接入了三方支付的话，那么使用三方提供的充值提现支付接口即可

转账，主要是指用户之间的钱包账户之间进行资金转移的过程，一般不支持跨商户平台转账，微信支付宝除外；有个人对个人转账，也有商户对个人转账，如图12所示

图12 钱包之间的转账

余额支付，就是使用钱包进行下单支付，比如我们在微信购买东西时可以支付方式可以用微信钱包；平台也可以使用自己的虚拟账户体系构建余额支付能力。

2.8设计钱包前端应用

前端设计我觉得不需要做太多介绍，因为这个很容易调研，比如微信钱包，支付宝钱包；很多应用的钱包，很容易借鉴参考，如图13所示

图13 钱包页面

2.9搭建钱包底层账户服务

这部分在账户系统设计详解中很详细介绍如何设计一个账户系统，该部分与之类似

2.10构建钱包附属支付服务体系

充值，提现，转账，绑卡鉴权，支付安全，钱包流水等

支付交易的本质就是通过支付通道操作账户完成资金的处理

支付相关的后面的支付核心，交易核心，打款系统会有其他文章详细介绍

2.11钱包的运营后台

钱包的运营后台，账户系统，支付交易等独立系统单元这里就不介绍了；重点要说一下钱包特有的部分，比如钱包开通情况列表，如图14所示

图14 用户钱包列表

拓展阅读

你这是干了嘛！钱呢！

最近在看“杨光的快乐生活”，说啥都想加个“嘛”，你说这是因为嘛！但是今天我们不聊电视，聊正事：一段费钱的代码

账务系统对于一个公司来说非常重要，不仅管理这客户的各项交易信息和余额，也记录这公司内部的相关核算数据；对它的准确性和安全性要求极高；你可以想象你的100万存在某银行，他的数据丢失了，你找谁要钱去！是不是突然感觉你的银行存款不安全了。货币电子化带来方便的同时，必然潜在着巨大的风险；今天我们就聊一个我接手的一个账务系统中的一段“奇葩”代码，它是怎么样像寄生虫一样吸干了用户的余额......

1.警惕不为人知的逻辑

我想大家都有这样的经历，就是技术在实现产品方案时，会按照自己的理解增加一些逻辑，而这些逻辑有时候没有人知道，但是随着时间的推移，它在慢慢侵蚀着一切。也不能说他是病毒，只能说是一个逻辑漏洞。如果症状不明显，没有人会发现，直到有一天它爆发了！所以特别是账务系统，一定要不断地强化校验机制，确保数据准确性

2.旧主体转新主体

有些公司的业务在经营一段时间以后会更换公司主体，那么势必要进行新旧主体相关事物的清算，特别是用户的债权债务关系的转移

我们今天的主角是商家保证金；很多平台都会要求商家缴纳经营性的保证金。当要从旧经营主体转为新经营主体时，商家的保证金也要跟着转过去，而这个转移需要签订一个债权转移协议，并基于电子合同指令对账务进行处理，如图15所示

图15 新旧主体保证金账户

批量转签，起初全部商家签订新主体协议，然后基于签约电子合同消息，对商家保证金账户发起转账指令，完成余额转移；但是这里要提一个旧系统的问题，就是账户并没有分2个账户，而是为账户打了一个标志，这个标志是“新/旧”，也就是真正的转账动作实际上是把账户的“旧”标志改成了“新”标志，并插入转出转入的2条流水，如图16所示

图16 保证金新旧主体转签的账务处理

收到合同转签指令以后，如果商家账户有余额则将账户的标志改为“新”，然后插入2条流水，如果旧账户没有余额，直接将账户标志改为“新”即可；如果后续商家进行充值，实际上账务流水标志是“新”，所以债权是在新主体

到目前为止，整个产品方案是没有问题的......但是，经过一段时间的运行之后发现问题了：财务发现旧保证金科目余额慢慢的成为了“负”值，而且截止到开始排查问题时，这个负值近百万，这意味着什么，这意味本来是你欠商家的保证金，变成了商家欠你保证金，就像你的工资成了负值，你要给公司发工资一样，这是一个比较荒唐的事情

这个问题的产生要从一串代码说起

3.如果没有就插入

这段代码是在核算历史明细的时候发现的，发现有些商家的保证金账户明细多了一对流水，而这一对流水给新充值的流水时间几乎一致，如图17所示

图17 保证金账户流水表

这里就是问题所在，你核对新旧的结转发现能对的上，你核对充值跟银行资金收款也能对的上，但是你单单看两个主体，你就会发现问题，商家的旧主体保证金是-1000了，新主体是2000；但是财务又不会去核算单个商家的账户余额，所以这个问题在正常的记账过程中没有发现

直到保证金账户余额出现了负的情况，才意识到，账务有问题

排查之后发现了这样一段逻辑：商家充值保证金记账时，如果账户中没有结转记录就插入2笔结转流水，如图18所示

图18 转签校验逻辑

就是这个逻辑，让很多商家的旧主体保证金成为负发生额，并且绕过了很多核算不断地积累到很大的规模，幸好把新旧主体放到一起整体来看企业和用户都没有损失，通过账务反向入账抵消不应该存在的发生额即可修复整体账务问题，但是有些时候可能就没这么幸运了；就像之前遇到过刷数据回滚账务造成已经提现的余额回滚问题，这个就真丢钱了；在某更大的企业也出现过因为运营直接找到技术做了一个简单的处理，瞬间几十万就没有......

前一段工作中也遇到的账务问题，因为业务侧的一些改动造成了重复扣了商家几十万的税，这里就不细说了；总之账务无小事，一定要盯紧，定期核算检查核心逻辑，核对关键的环节，但无论怎样，事前拦截是一方面，事中校验也很重要，事后核算也很重要；一旦事故发生，制定账务调整策略及时封住漏洞修复账务数据也很重要。

总之，丰富全面的会计知识，会有助于你全局的去制定合理的账务处理方案；账务无小事，一朝不慎，轻则不能晋升没有年终奖，重则小组全开！

--推荐阅读--