发红包，领红包；普通红包，拼手气红包；想必在用户应用层面大家都不陌生，但是红包底层的支付流程以及红包算法规则，涉及的支撑系统，估计很多人不知道了，今天我们就讲一下“红包”背后的秘密，教你如何设计一套红包体系。
1、什么是红包
红包对于用户来说更多的是一种娱乐手段，生活工具；对于企业来说更多是一种营销手段；微信红包是大家最熟悉的了，像钉钉，脉脉等很多应用内部都有红包功能
红包本质上是用户虚拟账户之间的“转账”能力；一个用户的账户扣一笔钱，然后拆分后转给多个账户；至于每个账户转多少金额，就是红包金额的算法，普通红包简单，平均总金额就行；拼手气红包稍微麻烦，既要保证红包最低金额，又要保证金额随机；
已经领过的不能再领，过期的红包不能再领且要退回发红包的账户……
今天我们重点说说个人红包的设计方法
2、红包种类
个人对个人类型
- 指定单个对象：金额固定
- 不指定对象（单个/多个）：群红包，金额随机或均等金额
企业对个人
企业发送给个人的红包可以是随机金额或者固定金额。
3、红包体系涉及到的系统
前端应用：用户发放领取的前端展示页，收银台等。
订单系统：红包的支付订单，用户领取后的转账订单。
账户系统：金额查询，红包余额的转出转入。
营销系统：红包规则创建，查询，比如发了多少个，什么类型的红包等。
运营系统：查看管理红包发放和领取记录。
每个系统都会有单独的文章详解，这里不做介绍；默认读者所有系统全部熟知，有不熟悉的系统可以去支付专题查找相关系统进行阅读。
4、红包业务框架
5、红包业务流程
重点讲解各个红包类型不同场景下的发放和领取流程。
5.1指定用户-一对一场景
主要是在一对一聊天场景，发红包给朋友，相当于指定了这个某个用户领取红包。
整体业务流程图
- 发送用户1状态：用户1状态必须为已实名；
- 接收用户2状态：需指定用户，前端需传输用户2的userid
- 余额支付：用户1使用余额支付时，用户2未领取前，发送金额以冻结状态存储在
的资金账户中；
- 绑卡支付：用户1使用银行卡支付时，支付金额会先充值到1的资金账户中，并冻
结该资金。
- 领取(红包状态为可领取）：
用户2确认领取后，解冻1资金后通过转账，入账至2的资金账户中；
- 退回
用户2到期未领取：发送金额解冻后，遵循原路退回原则，退回用户1；
- 用户1撤销发送：只要用户2未领取，均可解冻资金并退回资金。
发放业务流程
领取退回业务流程
5.2不指定用户
可以不指定发放一个，也可以发放多个，根据设置的红包数量确定
整体业务流程图
字段说明：
- 发送用户：1；
- 接收用户：n(n=2,3,4…)；
- 发送红包数：K；
- 发送总金额：M；
关键点说明：
1.发送用户1状态：用户1状态必须为已实名；
2.接收用户n状态：领取时n状态不需要为已实名。不需指定用户，从设置的发送红包数/可领取人数K确认，是对单用户还是多用户场景；
3.红包创建：资金冻结成功后，按照随机规则直接创建K个子红包。
3.支付：
3.1)余额支付：用户1使用余额支付时，只要有用户未领取，剩余发送金额都以冻结状态
存储在1的资金账户中；
3.2)绑卡支付：用户1使用银行卡支付时，支付金额会先充值到1的资金账户中，并冻结该资金。确认领取过程同3.1。
发放业务流程
领取退回业务流程
6、总结
好了，红包我们点到为止；我们来思考几个问题。
底层服务至少给应用提供那几个服务接口，传参和出参应包含那几个字段？
发放红包使用中间账户和不使用中间账户有什么区别，那么方式更优？
你觉得微信红包的随机金额算法是怎么样的？
