V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ArronJun
V2EX  ›  Java

关于 zf 消费券系统实现

  •  1
     
  •   ArronJun · 173 天前 · 3762 次点击
    这是一个创建于 173 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    13 条回复    2022-01-12 13:01:57 +08:00
    sunjiayao
        1
    sunjiayao  
       173 天前   ❤️ 1
    依托于支付宝微信可以借助他们的身份系统避免一部分黑产刷券。核销得看怎么和商家对接了,粗略想的话提供给商家提供一套核销后台,然后还要有一套 OpenApi 核销接口用来对接需要接入自家平台的商家。最后对个账,划个款。就是财务的事了。
    ArronJun
        2
    ArronJun  
    OP
       173 天前 via iPhone
    @sunjiayao 商家核销可不可以商家直接和微信支付平台对接
    cpstar
        3
    cpstar  
       173 天前
    平台确定了,那这不是个技术问题,是个商务问题吧。楼上说的,Z/W 肯定都有相对可用的服务。
    sunjiayao
        4
    sunjiayao  
       173 天前
    @ArronJun 微信应该是有代金券,支付宝可能叫商家红包。具体的得调研下。如果让商家走你的支付平台的话,就涉及个最后分账的逻辑,因为用户支付的钱是到你的账户下了。
    sujin190
        5
    sujin190  
       173 天前
    这种东西都支付宝微信都发过无数波了吧,所以只是想在支付宝微信上干这事,你不是应该直接去找支付宝微信商务去聊么,人家应该有现成方案的吧,发放、核销、分账、风控整套的吧,没必要在这问吧
    mrgeneral
        6
    mrgeneral  
       173 天前
    你说的这俩家有现成的风控体系,不过大部分是基于账号纬度的,细粒度或自定义的业务风控应该是你自己实现,他们就是一个发放平台。
    xingshu1990
        7
    xingshu1990  
       173 天前
    ZF 分发这块,本身在 2020 年什么时候 ,反正就是疫情封城的时候,为了促进百姓群众消费,维护市场的基本经济,主动联系支付宝和微信,线下商议优惠券分发等信息,这个第一时间考虑不给羊毛党薅羊毛。
    这个不像淘宝客,就不用考虑乱七八糟的黑灰产技术了。
    shot
        8
    shot  
       173 天前
    对接的平台有成熟解决方案就直接用。
    特别是抢券模块,预估好并发量,准备好机器,提前做好压力测试。

    上个月合肥市发消费券,微信通道一上线连崩两天,第三天刷新页面上百次才抢到(美团通道倒是一切正常)。
    怀疑又是层层转包给某个野鸡团队随便糊弄的。
    markgor
        9
    markgor  
       173 天前   ❤️ 3
    支付宝不清楚;微信有支付券的,去和微信支付谈就行了。
    也不涉及到核销的问题,消费券核销情况微信有接口拉取回来或异步通知的。
    抽象点的说法:
    客户抢卷->API->微信支付(创建消费红包)->微信通知用户现金券到账。
    客户消费->微信支付->通知核销现金券(和消费商家没关系)

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

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

    小程序形式,(有图片的就上 CDN )自己服务器别负担静态流量
    抢卷的时候别直接发请求,做个定时器,随机 100~3000 毫秒才发送请求,界面就显示个 loadding ;(万金油,能避免并发的问题)
    拦截器,请求超时提示 网络异常,请稍后再试。(把锅先甩了)
    创建失败--一般是达到微信 QPS 或后端请求微信创建失败类的原因,就提示 微信异常,请稍后再试(不粘锅,能甩先甩)
    markgor
        10
    markgor  
       173 天前   ❤️ 2
    上面漏了,压测,记得要出压测报告;
    如果是基于小程序的,小程序本身有压测功能,量大的付费即可,别想省这笔钱,反正也不多;
    但是记得保存压测结果。
    到真出什么问题的时候,拿出报告;
    1 、如果使用人数>压测人数,真要问责你就把压测结果拿出来,说我们按照这个预期人数设计的,但实际参与人数多了 xxxx ,然后一般都没问题,切记合同上要轻描淡写提及下并发数量。
    2 、如果使用人数<压测人数,直接甩锅微信,压测报告中.....但实际情况....问题本身是微信压测结果不精准,我们能做的已经都做了,只是没想到微信压测会如此,下一步我们会加强自建压测平台,bababababa....
    zarvin
        11
    zarvin  
       172 天前
    上面的老哥很有经验啊
    caqiko
        12
    caqiko  
       172 天前 via Android
    @markgor 这么优秀一定不用 996
    markgor
        13
    markgor  
       172 天前
    @caqiko
    不优秀,只是被社会打磨得越来越圆滑罢了,现在 966 而已。
    以前接触 ZF 的,基本对方对接都是一群 50+的,前期完全不管,后期天天跑来公司叫外卖拍照发他们工作群。
    需要提高预算就一拖再拖,有问题就直接把外包推出来挡刀。
    以前很好奇为什么政务办不成立个自己的技术部,这样他们各局的需求自行开发即可,慢慢我就明白了还是找外包好的道理,所以身为外包,肯定要有那么一两招防身
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2352 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 05:32 · PVG 13:32 · LAX 22:32 · JFK 01:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.