1.项目背景
某行开发的聚合支付系统,聚合了微信扫码支付、支付宝扫码支付以及本行手机银行扫码支付。 通过对本行手机银行扫码支付满减活动来提升本行手机银行扫码支付占比,进而促进客户开通手机银行及开卡。 每笔满减金额付款方和收单商户按比例分成,同时让商户更有积极性引导付款方使用银行app。
这里只做本行扫码的支付立减,一个是促进本行手机银行app的使用,二是资金结算上更可控。 实际运营数据统计下来,微信支付占比90% 支付宝支付占比8% 本行app扫码只有2%左右,相信这个占比也是各家 银行做聚合支付的痛。
2.项目需求
接着看下具体的需求。
试点扫码支付满减活动。针对近期美食街发展新商户,择优选取n户作为特惠商户,针对本行手机银行扫码付款客户,满10元每笔随机优惠最高10元,单个商户单日封顶20笔,其中优惠金额50%由商户享受,50%由付款方享受。优惠费用由银行实时补贴,系统从商户归属网点xxxxxx科目支出清算给商户。 其中,为保证营销效果要求80%的优惠笔数在7元-9元之间。
如:每户每天优惠20笔,每笔上限额10元,则其中16笔的优惠金额应在7元至9元之间,确保优惠效果。
示例:付款方支付100元优惠10元,商户得5元补贴,付款方得5元优惠。付款方实际支付95元,商户实际收款105元,银行补贴10元。
这个需求里有两点:
-
随机减的金额由银行补贴,但是是付款人收款方各得50%
-
不是纯随机,要求一定的比例在在一定的额度之上。
3.项目方案
总体流程是这样的
运营人员在运营管理平台创建活动,输入各种参数。
交易系统根据交易参数判断是否满足随机立减条件,满足则调用优惠交易。
清算上,这个聚合支付系统对本行app扫码是实时清算,所以付款方下账金额加上商户所得优惠金额,一笔清算给商户。
下面是一些原型展示,首先管理台的活动列表页以及活动详情页
在商户的收单页面上,要显示奖励金额。
而在用户的支付侧界面,显示已优惠的金额。
最 后重点说一下里面关于随机减的一个设计,考虑需求里的要求80%的优惠在7-9元之间,而且优惠是每天20笔的,所以在方案设计时采用了提前生成随机数的方案,可以说是一种完全的伪随机,类似于扑克发牌。系统里在每天开始时为每个活动商户生成优惠的金额,相当于为每位玩家发20张扑克牌,在发牌的过程中确保满足80%的优惠额符合要求即可。
最后总结一下,这在我们聚合支付系统刚上线的时候很好的拉动了本行app的使用率,也让商户更愿意给客户推介本行app的扫码支付方式,因为他们也可以获得奖励。这种方案可以在没有完善的营销系统时临时性的解决问题。在后期的产品迭代中,在营销平台完善后,我们逐步的把这种随机减放到了营销平台,以优惠券的方式进行了发放。
谢谢大家,这个简单的案例就分享到这里。有问题的地方欢迎大家指正。
Q&A
Q1问下满减方案是由你们运营添加的,但是金额是由银行承担。这个金额银行是有规定的吧
-
A1聚合支付系统完全由银行运营,我们是产品设计和实施方。
-
Q1这样就没有问题了[OK]
-
A1实际上也是由银行的运营来自己添加,金额也完全由银行来承担,而且是由分行、支行自行承担
-
Q1银行也要控数据啊,不然数据都给微信支付宝了。银行头疼
-
感觉这个补贴如果有,用户会用,一旦停掉,用户马上就流失了
-
Q1问个问题,像微信支付后领取的红包,下次使用抵扣,假如领取1元,下次购买5元商品。用户支付4元,抵扣1元,给到商家是5元么?这个1元是由微信出的么?
-
A1 微信官方的活动商户是收到含补贴额的 ,商户自建活动发优惠分两种 提前重置的可以拿到含补贴结算款,不充值的只能后结算
-
Q1 [抱拳]了解了 谢谢
Q2退款的话是怎么处理呢
Q3 有个问题想请教下,为什么说这个比例会让支付聚合头疼呢?这是站在哪个角度来看呢?[抱拳](实际运营数据统计下来,微信支付占比90% 支付宝支付占比8% 本行app扫码只有2%左右,相信这个占比也是各家 银行做聚合支付的痛。)
Q4满10元每笔随机优惠最高10元,单个商户单日封顶20笔,其中优惠金额50%由商户享受,50%由付款方享受。优惠费用由银行实时补贴,系统从商户归属网点xxxxxx科目支出清算给商户。看到这里我有个问题,商户再运营的时候,具体该怎么体现立减金额?