20170802-收银台优惠

Posted by PaymentGroup on August 2, 2017

一、专题分享:收银台优惠

自我介绍:大家好,我主要负责一款银行信用卡app的用户支付模块的开发,我们的app基于信用卡的工作也做了很多扩展延伸,在业界也算小有名气,但面对互联网大神们,还是挺心虚的,希望大家多多包涵。今天给大家分享的主题是收银台优惠。

不管是收银台优惠还是商户优惠,总会对应到促销活动,而活动包含了很多的要素,包括基本信息(活动名称,时间限制,活动预算,促销模式等),客群要求(信用卡客群,借记卡客群,20到35岁之间的女性,等等),资格(其实是活动的前置条件,譬如需要在app上首次绑定卡片,需要连续5天支付满100元等等),范围(活动涉及的商户列表、门店、城市、或者是业务类型),支付方式(支付使用的卡片类型、卡种等)。

支付规则(其实就是把活动规则翻译成规则脚本,像满100则减5元,满200则减15元等等),优惠券(因为收银台上需要展示优惠,但同时如果用户持有优惠券,则需要叠加优惠券)

目前优惠模式主要包含满减模式、积分抵现金模式、满折扣模式、指定特价模式(这个更倾向于商户自己实现,而不是由收银台来做)、固定金额随机减模式(有0.5元、1元、5元、10元这些固定金额,支付时随机减)、正态分布随机减(按照正态分布的概率分布随机减金额)、分区间随机减(基于正态分布,划分区间随机减)、固定比例的人数优惠(纯看运气)、固定人数可以免单(运气,我们一般和其他模式一起)

流程上来说,交易进入收银台后,我们会兵分两路,一路去风控,一路去优惠中心,分别拿取当前支付的风控反馈和优惠反馈,优惠这边先根据支付本身的参数,并四处获取该用户本身的属性特征和行为、商户的特征等,所有数据汇集在一起送至规则引擎中进行匹配,匹配完成后得到该笔支付需要在收银台上展示的优惠列表,以及每条记录对应的优惠金额和客户实际需要支付的金额

当然这里有个问题,随机减的场景,如果我们在支付前展示优惠金额的话,必然会遭遇黄牛党的攻击,所以我们会根据不同的活动配置不同的展示模式,把金额放在支付完成时才展示出来,另外还有些黄牛党会在借记卡里只存10元,然后不停的尝试,期待试出更高的金额,这个我们也做了一些防范措施,主要是活动优惠金额会跟人走。

我们优惠规则部分主要利用了开源的drools来实现,主要考虑到他社区比较活跃,功能比较强大,规则里我们又区分了基本规则组合、特定算法规则系列,基本规则主要检查一些固定的限制例如时间,参与商户等,特定算法主要针对不同的促销模式实现不同的算法控制

整体流程上会先做活动基本信息过滤,次数户数统计信息过滤,预算过滤,客群资格等信息过滤,满足条件后才会做优惠的计算,并缓存,得到该笔支付可以享受的优惠列表后,会根据活动配置的优先级来进行排序,客户选择某个优惠活动后,并走完验证流程进入最终支付时,从缓存中获取之前计算好的优惠信息,提交支付。

这种优惠中心,是通用的,收银台可以用,其实其他场景也是可以用的,例如还款、消费分期等,钱的返还方式可以是当即减,也可以是支付后返现。

二、Q&A

Q1:咱们的促销优惠成本谁承担?
A1:这个提供了比例配置,可以是银行全承担,可以是商户全承担,也可以按比例分配
A2:优惠都是平台出资,商户出资及混合模式。规则系统如果并发比较高的时候要特别看一下性能。

Q2:商户分担费用的话,商户事后转账给支付通道?
A1:不是走事后转账,支付时双方分摊的金额已经计算完毕,后续走清算

Q3:请问商户出资,需要预存保证金?
A1:目前合作商户不需要

Q4:能不能举个实际的业务场景说明下信息过滤的规则跟匹配流程?听上去流程好像多个纬度的规则然后匹配多次?
A1:这个按类型做了分类,并排好优先级,丢进drools里跑

Q5:请问待支付金额(优惠金额)是放在前端计算还是服务端计算?
A1:服务端计算好的,前端只做展示

Q6:如果有多个优惠券是用户会自己选的吧,用户看到的待支付金额场景呢
A1:多个的话,我们会根据不同的活动配置告诉前端是否展示待支付金额,一般随机的会在支付成功才告知,满减的支付前告知

Q7:有没有类似有多张优惠券的场景,比如优惠券两张5元,两张6元,这个时间用户在前端可以选择使用哪张?这个时候需要计算后显示给用户待支付金额的吧,那是前端计算后传给后端,还是后端再计算一次?
A1:我们做的时候是自动选优惠最大的,后端不用算,前端传过来哪个扣哪个
A2:后端要校验的,不能相信前端传来的值,不然容易被钻空子
A3:前端只做展示,所有的计算都在后端,想想业务再复杂一些多重优惠还有互斥,前端怎么算,算了也没有意义
A4:应该是后端对前端计算的二次确认,一致刚支付,不一致报错,扣款以后端为准
A5:前端做的事都是为了用户体验,后端才能保证准确性

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。