关于在最后一秒支付的业务逻辑问题

我有一个需求, 比如说有一个商品, 用户下单后(还未支付), 我先锁定改商品, 10分钟未支付就还原状态, 但是用户在9分59秒的时候支付了, 此时商品还原队列优先执行了, 把商品设置为了正常状态并把订单设置为过期, 然后支付回调检测到订单过期了, 肯定不能正常下单了, 这种业务逻辑改如何优化?

补充: 其实还有种情况, 就是用户在输入支付密码的界面等待

让PHP再次伟大
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
最佳答案

一般这样处理就已经 可以了,系统自动发起售后,退款给用户。

如果 产品一定要刁难你,那你可以提供一个方案,就是不管剩下还剩多少秒,统一给用户有3~5分钟的拖延时间。

定时任务检查一下最近一次payment 的数据。

如果时间要结束了&& 最近有吊起支付记录,不停止该单状态,重新计算再次进队列

2年前 评论
Neilyozの鱼不浪 2年前
jxdr 2年前
讨论数量: 8

一般这样处理就已经 可以了,系统自动发起售后,退款给用户。

如果 产品一定要刁难你,那你可以提供一个方案,就是不管剩下还剩多少秒,统一给用户有3~5分钟的拖延时间。

定时任务检查一下最近一次payment 的数据。

如果时间要结束了&& 最近有吊起支付记录,不停止该单状态,重新计算再次进队列

2年前 评论
Neilyozの鱼不浪 2年前
jxdr 2年前
自由与温暖是遥不可及的梦想

这个问题

我面试的时候问过

解决很简单

1 在发起支付的时候 告诉第三方支付公司 我最后可用让用户支付的时间即可

2年前 评论

释放时间延长,一般第三方超时多少时间就不能支付了,以第三方可付款时间为准。10分钟在应用内部不可点击去付款,实际11分钟或者更久更改状态。

2年前 评论

如果比较严谨就是在59秒的时候发起支付,支付成功后回调发现订单是取消状态,做退款处理,如果不是很严谨则可以延长库存返回,比如15分钟后才返回,留出五分钟缓冲,如果用户在第三方支付页面停留时间超过五分钟,也可以退款处理

2年前 评论

一般这样处理就已经 可以了,系统自动发起售后,退款给用户。

如果 产品一定要刁难你,那你可以提供一个方案,就是不管剩下还剩多少秒,统一给用户有3~5分钟的拖延时间。

定时任务检查一下最近一次payment 的数据。

如果时间要结束了&& 最近有吊起支付记录,不停止该单状态,重新计算再次进队列

2年前 评论
Neilyozの鱼不浪 2年前
jxdr 2年前

订单过期 20 分钟
第三方订单过期 19 分钟

1 分钟时间差, 避开就好~

其实也不用差 1 分钟这么久….😂

2年前 评论
勇敢的心 (楼主) 2年前
自由与温暖是遥不可及的梦想

这个问题

我面试的时候问过

解决很简单

1 在发起支付的时候 告诉第三方支付公司 我最后可用让用户支付的时间即可

2年前 评论

这个很简单吧,比如你要订单15分钟自动取消,那你延时队列的时候设置16分钟呗,一般第三方支付时间不可能超过一分钟的

2年前 评论

老哥。这个简单呀,订单有效期 一般都和第三方支付的有效期是一致的,就是过了这个时间一定不能支付,第三方也会关闭这个订单,还原的时候按策略请求第三方主动核对一下未支付的订单就好了。 还有一种就是回调延迟(如果有库存控制,那么直接重新激活订单,扣除应该减少的库存。库存不够再走退款的操作,我们以前是不让退款的,退款了让客户再付款就有点难了。 根据自己行业来调整策略。我们以前的订单虽然有过期时间,但是对于回调的信息来说。 实际上是做的永不过期。因为我们库存不需要实的 :joy:

2年前 评论

这个简单,像微信支付,在预支付订单接口可以传订单交易结束时间,这个时间设置为订单过期时间,超过时间无法支付,

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!