关于 zf 消费券系统实现

[ArronJun]

现在有个发放消费券系统的需求，发放平台主要是 zfb,wx. 咨询下大佬做过 zf 消费券发放系统的，难度大不大

[sunjiayao]

依托于支付宝微信可以借助他们的身份系统避免一部分黑产刷券。核销得看怎么和商家对接了，粗略想的话提供给商家提供一套核销后台，然后还要有一套 OpenApi 核销接口用来对接需要接入自家平台的商家。最后对个账，划个款。就是财务的事了。

[ArronJun]

@sunjiayao 商家核销可不可以商家直接和微信支付平台对接

[cpstar]

平台确定了，那这不是个技术问题，是个商务问题吧。楼上说的，Z/W 肯定都有相对可用的服务。

[sunjiayao]

@ArronJun 微信应该是有代金券，支付宝可能叫商家红包。具体的得调研下。如果让商家走你的支付平台的话，就涉及个最后分账的逻辑，因为用户支付的钱是到你的账户下了。

[sujin190]

这种东西都支付宝微信都发过无数波了吧，所以只是想在支付宝微信上干这事，你不是应该直接去找支付宝微信商务去聊么，人家应该有现成方案的吧，发放、核销、分账、风控整套的吧，没必要在这问吧

[mrgeneral]

你说的这俩家有现成的风控体系，不过大部分是基于账号纬度的，细粒度或自定义的业务风控应该是你自己实现，他们就是一个发放平台。

[xingshu1990]

ZF 分发这块，本身在 2020 年什么时候 ，反正就是疫情封城的时候，为了促进百姓群众消费，维护市场的基本经济，主动联系支付宝和微信，线下商议优惠券分发等信息，这个第一时间考虑不给羊毛党薅羊毛。
这个不像淘宝客，就不用考虑乱七八糟的黑灰产技术了。

[shot]

对接的平台有成熟解决方案就直接用。
特别是抢券模块，预估好并发量，准备好机器，提前做好压力测试。

上个月合肥市发消费券，微信通道一上线连崩两天，第三天刷新页面上百次才抢到（美团通道倒是一切正常）。
怀疑又是层层转包给某个野鸡团队随便糊弄的。

[markgor]

支付宝不清楚；微信有支付券的，去和微信支付谈就行了。
也不涉及到核销的问题，消费券核销情况微信有接口拉取回来或异步通知的。
抽象点的说法：
客户抢卷->API->微信支付(创建消费红包)->微信通知用户现金券到账。
客户消费->微信支付->通知核销现金券（和消费商家没关系）

至于上面提到的风控问题，微信小程序有风控接口；
上面提到核销问题，和商家无关，是客户使用微信支付时候选择消费红包；

然后你自己需要关注的就是一个地方，用户抢卷的时候会是典型的高并发场景；
可以考虑:

小程序形式，（有图片的就上 CDN ）自己服务器别负担静态流量
抢卷的时候别直接发请求，做个定时器，随机 100~3000 毫秒才发送请求，界面就显示个 loadding ；（万金油，能避免并发的问题）
拦截器，请求超时提示 网络异常，请稍后再试。（把锅先甩了）
创建失败--一般是达到微信 QPS 或后端请求微信创建失败类的原因，就提示 微信异常，请稍后再试（不粘锅，能甩先甩）

[markgor]

上面漏了，压测，记得要出压测报告；
如果是基于小程序的，小程序本身有压测功能，量大的付费即可，别想省这笔钱，反正也不多；
但是记得保存压测结果。
到真出什么问题的时候，拿出报告；
1 、如果使用人数>压测人数，真要问责你就把压测结果拿出来，说我们按照这个预期人数设计的，但实际参与人数多了 xxxx ，然后一般都没问题，切记合同上要轻描淡写提及下并发数量。
2 、如果使用人数<压测人数，直接甩锅微信，压测报告中.....但实际情况....问题本身是微信压测结果不精准，我们能做的已经都做了，只是没想到微信压测会如此，下一步我们会加强自建压测平台，bababababa....

[zarvin]

上面的老哥很有经验啊

[caqiko]

@markgor 这么优秀一定不用 996

[markgor]

@caqiko
不优秀，只是被社会打磨得越来越圆滑罢了，现在 966 而已。
以前接触 ZF 的，基本对方对接都是一群 50+的，前期完全不管，后期天天跑来公司叫外卖拍照发他们工作群。
需要提高预算就一拖再拖，有问题就直接把外包推出来挡刀。
以前很好奇为什么政务办不成立个自己的技术部，这样他们各局的需求自行开发即可，慢慢我就明白了还是找外包好的道理，所以身为外包，肯定要有那么一两招防身