我理解一下,第一次下单的时候ABC都已经减库存并生成订单,没有支付而已 。第二次对A下单,在生成订单前要去判断库存是否够,不够无法下单,够的话直接购买,不冲突 。 至于你说的第一次里面已经有商品A了,所以第二次不允许购买A,这是业务需求的,而不是程序能不能和该不该的问题 。 比如说我去超市,第一次买了1瓶农夫和1瓶怡宝,觉得农夫有点甜,所以想再买1瓶,这个时候超市说对不起你已经买过1瓶农夫了,不允许再次购买 。 你咋想 ? 农夫超级稀有1人限购1瓶 ? 搞促销只能参加1次? 这些都是规则(你公司的业务要求)。跟微信支付毛线关系都没有。
问一个微信支付下单前,限制重复支付的业务流程问调用微信支付下单接口,是可以同时多个进行的。问业务系统设计问题。请从后端的角度理解。 注:文中的支付订单是支付纬度,不是商城纬度的那个订单。 现在用户想结算购物车的A+B+C物品,生成一条微信支付订单,当弹出“确认支付”框的时候,用点关闭窗口(或者杀微信进程),这个微信支付订单会关闭并回调支付失败吗? 如果不会,那就会产生一情况,用户现在再次发起结算,但单独结算A物品,就会又生成一条微信支付订单了。因为微信支付关单接口要下单5分钟后才能关,所以第一笔微信支付订单是没关的(https://pay.weixin.qq.com/wiki/doc/api/wxa/wxa_api.php?chapter=9_3)。 你们是怎么防止A物品重复支付的? 第一种方案:结算ABC三个物品时的微信支付订单,要锁定三个物品的状态为处理中,让第二次单独结算A物品时不能发起支付,但是这样要用户等5分钟,用户体验就不是很好。 第二种方案:结算ABC三个物品时,生成了微信支付订单,用户看到小程序弹出“确认支付”那个按钮的框,但是关闭这个框,去结算A物品,生成一条新微信支付订单(因为金额不一样了)。那这样系统是没有限制A是否重复购买的。用户如果得到h5页面,看f12,其实可以同时调用jsapi根据prepare_id唤出“确认支付”那个窗口,然后都去支付。最后就要退款处理重复部分。 其实看麦当劳点餐,买ABC唤起“确认支付”弹窗后,点关闭窗口(或者杀微信进程),可以去买A,他们就不怕遇到作的用户,触发两个微信订单然后都支付吗?因为两个发起两次微信统一下单是可以先后执行,所以分布式锁拦不住的。 图: 确认支付弹框 [图片] 待支付状态 [图片]
2020-11-28