一、背景介绍
随着支付行业的发展,各种支付方式百花齐放,人们可以选择自己更喜欢的支付方式。
- 付款方式:
使用更便利的APP用来付款,如:微信、支付宝、银联云闪付、京东白条,美团闪付,美团钱包等等。 - 使用场景:
使用不同的App付款时会遇到一些营销活动,比如满立减,送优惠券,送红包,支付成功后随机减等等。这些营销活动目的在于提高用户的粘性,为平台拉新留存,刺激用户下一次消费。 - 营销系统的作用:
营销系统会使消费场景更一步的扩展及巩固,作为一家支付公司,在已经有的支付基础上设计营销系统也更为重要。++我司营销系统现在主要是各地分公司使用,分公司会关注银行的营销活动,或者主动和当地的银行合作。在使用营销系统前,分公司同事已经商定好营销活动的方案,方案包括营销合作方、营销预算、营销规则、针对商户、合作银行、方案效果等等。++
二、营销系统介绍
我司的营销系统目前支持消费交易金额优惠及商户手续费优惠两种,如果商户配置多个活动还可以两种优惠同时发生。
2.1 营销模式及参与方
2.1.1 交易金额优惠
活动发布方:发布营销活动的一方,也是营销活动资金提供方。
- 如果活动发布方是银行,往往会提供参与营销活动的卡bin。
- 如果活动发布方式是平台商,会提供子商户号。
营销系统:配置活动相关参与方、活动规则,上线活动。
合作商户:活动期间参与合作的商户(优质商户),在商户下消费的持卡人可获得优惠。
消费者:享受优惠。
合作场景:银行针对本行卡优惠活动。
2.1.2 商户手续费优惠
活动发布方:发布优惠活动,通常是平台商、银联。
营销系统:配置活动相关参与方、活动规则,上线活动。
合作商户:活动期间参与合作的商户,此商户可享受手续费优惠。
消费者:参与消费,如果商户参与了多种活动,消费者也可享受优惠。
合作场景:银联双免优惠(小额免密),合作平台商优惠活动。
2.2 营销活动介绍
-
满减(固定减,随机减)
举例:
满100减15—固定减
满100减10-15—随机减
满100减10-15,满200减15-35 —随机减
满100减10,满200减25 —固定减 -
打折(固定折、随机折)
举例:
满200—8.5折
满200—随机5-8折
满200—9折,
满500—8.5折
消费即8折—最高优惠50元
注:随机折可以配置分层占比几率 -
一口价
举例:
9元洗车,9.9元看电影
2.3 营销活动规则
一个活动下必须有一个活动规则,一个活动规则可以绑定多个商户 。
- 活动时间规则
活动开始日期,活动结束日期
举例:- 活动开始时间,活动结束时间(当日)
- 不参与活动星期 不参与活动日期
- 活动额度限制
总额度,总次数
周期:日月季年总次数,总金额
举例:- 活动总额4万,活动总次数100次
- 每月/周/季/年 150次
- 每月/周/季/年 10000元
- 活动累计规则
对象:商户、单卡、单商户单卡
周期:日月季年 总次数 总金额
举例:- 每月每商户总额1万,不限制刷卡人次数。
- 每月每商户次数50,限制商户能优惠几次,不限制总额
- 每月每卡一次,限制一张卡一月只能享受一次优惠
- 每月每个商户每卡限制优惠金额,最多可以优惠50元等
- 交易方式限制
支付方式:刷卡、扫码、云闪付、快捷、apple pay
消费卡类型:贷记卡、借记卡、预付费卡
卡片归属地:境内、境外
卡组织:银联、VISA、万事达等等,卡bin组、卡黑名单组、卡白名单组
活动截图参考:
活动一图示:
活动二图示:
2.4 营销系统模块
2.4.1 合作方管理
合作方是营销资金的来源,营销活动可以采用先付款、后付款两种模式。合作方信息包含合作方基本资料,合作方联系经理,合作方入款账户、合作方出款账户。后付款的模式是做交易时直接给商户优惠,活动结束后拿交易流水找银行进行对账收款(目前这种模式居多)。先付款模式是合作方先充值入账(授信),资金入账后再根据交易情况扣款。
功能菜单:合作方查询、合作方审核、合作方入账、合作方入账审核
2.4.2 活动管理
活动管理主要分为部分:主活动,子活动,活动规则,活动及商户绑定 。
- 为什么要有主活动和子活动?是因为有时候一些银行会做系列活动。一个系列活动会有很多种优惠方案。每一种优惠方案针对不同行业的优惠。
- 主活动主要控制着活动的付款方式(先付款、后付款)、入账周期、活动金额、活动次数,主活动可以有多个子活动,一个子活动只能属于一个主活动,子活动也有各自的活动金额,活动次数。一个子活动有且只有一个活动规则。
功能菜单:活动查询、活动审核、规则模版查询,规则模板审核。
2.4.3 商户管理
商户管理:营销系统的商户依旧用支付系统的商户,只有要参与营销活动的商户,填商户新增至营销管理系统成为营销系统的商户。
商户活动查询:商户活动查询可以查到商户参加的所有活动,活动状态及活动周期。
功能菜单:商户查询,商户活动查询;
2.4.4 交易管理
交易查询:记录每一笔营销流水的详情,包括交易金额,优惠金额,手续费金额,优惠手续费金额,优惠类型,支付方式,支付结果,是否参与清算,活动规则,活动id等等,反交易则有原交易流水号。
交易清算:营销交易是否要参与清算是根据营销系统产生的对账文件来区分的。交易清算查询以对账清算文件及清算周期为维度,显示每个对账单的交易笔数、实收总金额、优惠总金额、文件状态、创建时间等等。
2.4.5 报表资金管理
商户报表:有总计及明细,记录每天有多少商户参与活动,活动数有多少,成功交易总金额,优惠总额;
合作方交易报表:统计合作方下的每个商户交易成功笔数、成功金额、优惠金额、交易失败笔数,交易失败金额;
合作方资金报表: 先付费模式一样要记清楚合作方出入账情况,记录了合作方账户的上日余额、收入、支出、当日余额。收入及支出总额可以有明细来对账。
2.5 交易-营销-清算
在已有交易系统和清算系统的基础之上添加营销逻辑:
2.5.1 交易金额优惠
- 交易时传入原始交易金额(商户总价)
- 交易系统检查商户、终端权限状态,风控没业务转换等等
- 交易系统计费,按照原始交易金额计费
- 调用营销系统查询是否有营销活动,有营销活动,如果是交易金优惠,则返回优惠金额
- 没有营销活动,则按照原始金额发送上游交易,有营销活动则将实付金额发往上游
- 将上游返回的交易结果返回给营销系统,如果交易成功,营销系统做营销活动,营销活动结果不会影响交易结果。如果交易失败,营销也失败。如果交易成功,营销失败则不影响交易结果,但是商户会收不到营销的优惠款,事后可根据流水人工处理对账。
- 营销系统收到交易成功结果,开始做营销活动,营销活动成功后交易系统会重新计费,计算出实付金额的手续费
- 交易系统入账,记录科目
- 交易完成
- 营销系统T+1日生成清算文件,清算根据文件进行结算。
- 目前营销支持消费冲正、消费撤销,暂不支持退货(后续优化)
2.5.2 手续费优惠
- 交易时传入交易金额
- 交易系统检查商户、终端权限状态,风控没业务转换等等
- 交易系统计费,按照原始交易金额计费
- 调用营销系统查询是否有营销活动,有营销活动,如果是手续费优惠,返回标识
- 交易将交易金额发往上游
- 交易成功则同事营销系统,营销系统算出优惠手续费给交易系统,交易系统将优惠手续费进行入账处理、记录科目
- 交易失败,通知营销系统,营销系统撤销优惠活动交易,营销失败,同样营销活动结果不会影响交易结果,如果交易成功,营销失败则不影响交易结果,但是营销的优惠手续费不会收到,事后可根据流水人工处理对账。
- 交易完成
- 营销系统T+1日生成清算文件,清算根据文件进行结算。
- 目前营销支持消费冲正、消费撤销,暂不支持退货(后续优化)
Q&A
Q: 请问POS收单的时候,发卡行实时将个人的资金划扣到哪里去了?
A: 银行把消费的钱划到哪里,他们有他们的处理机制。这笔资金最后要到支付机构的备付金账户被监管着,T+1结算结算给商户,如果做D0,那就需要有一方出来承担垫资费用。
补充
- 我司的营销系统目前还比较简单,主要合作一些银行,和一些线上平台商,后续会继续设计 会员、卡卷营销的一些功能;
本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。