奇葩的异常支付场景

现代的订单支付、秒杀等业务，下单库存锁定后都有个倒计时功能，超过指定的阈值会释放掉订单，防止有人恶意锁单。
一般而言我的方案是这么做：
1.下单后对订单生成一个stub放在redis
2.用ttl进行倒计时
3.进页面后轮询key是否存在，不存在订单取消，存在则显示倒计时倒计时

现在有种场景：
用户在未超时的情况下点击付款后打开了第三方的app，比如支付宝进行支付，但是支付宝APP停留时间长，此时后台的ttl已经超时，被删除，但由于第三方支付已经打开，接口层面付款仍然是可以成功的。
所以这种情况算是下单成功还是失败？
再或者由于现在的支付回调大部分都是异步的，假设异步通知时候ttl过期，算成功还是失败？
更麻烦的是，假设算支付成功，成功后由于ttl过期，导致库存解锁，商品又被其他的订单锁定。。

目前想到的解决办法：
1.比较好的第三方支付渠道、支付宝、微信在API上都会提供一个最晚支付时间，如果超过这个时间未支付就不能支付了，比如订单超时是30分钟，那把这个时间减少个10秒传给支付宝，支付宝那边会保证这种场景的失败。
2.同步查询支付结果或者收到支付成功回调的话，判断一下订单的支付状态，如果已经超时，直接退款，但这种用户体验非常差，用户的账单明细会有两条记录，一条支付成功，一条退款成功。
3.看看第三方是否提供关闭订单的接口，ttl超时时先调用第三方的关闭接口，如果调用失败代表用户支付成功，续一下ttl，不要做后续的释放库存操作，如果调用关闭成功在做后续的释放库存业务，由于也是调用第三方和调用网络RPC，其实也没法保证严格的幂等。
4.前端拉起支付APP前调一下后台，后台看一下剩余时间，如果很快超时就续一小段时间，等待支付完毕。但有个风险，如果被人发现了这种机制，会一直反复唤起支付APP，长时间锁单。

没想到特别的好办法，由于支付宝和微信提供了最晚支付时间，所以目前是1和2结合的方案，但银联那边没提供，所以银联用的3。