订单取消的时候，客户支付了。怎么处理好？

从描述中可知：

1. 支付是第三方异步回调来的，所以收到支付回调就代表用户已经支付完成。
2. 问题中说的同时可以理解成处理支付回调和处理取消请求是同时

那么可以通过加锁的方式做以下处理：

1. 正在处理支付回调的时候，进来了新的取消请求，驳回取消，保证支付
2. 正在处理取消请求的时候，进来了新的支付回调，回滚取消，保证支付
3. 刚处理完支付回调，进来了新的取消请求，按正常流程，取消即可
4. 刚处理完取消请求，进来了新的支付回调，进行退款，同时添加警告日志，重点跟进该类订单

加锁

取消订单前我们都会去支付宝或者微信查一下，如果支付了就改状态，如果没支付就调用他们的关单防止客户支付

回调的时候，如果不能接受把取消的订单变成正常订单，只有一种解决方式： 退款

取消订单的时候会去尝试把它相关的各种渠道的支付关闭一下,如果关闭不了并且已经支付的话就不能关闭了

我说下我目前的方法。一直也是觉得不是很好。所以想看看大家的。当要取消这个订单的时候，首先看看这个用户的登录日志和操作日志。如果是处在支付页面。此时要慎重，或者再打一次电话。或者等几分钟。或者和网友说的一样去渠道关闭订单。

回调加判断就好了吧，如果是取消就再走一个原路退回，记录起来

支付前应该是要请求支付参数的吧，这个服务端肯定会保存这些数据的比如支付的订单号。 取消前可以判断一下这个，没有可以直接取消，有的话就再另外一种情况。 如果已经有支付订单生成了可以再考虑几种解决方案，1、判断这个支付订单n分钟内有没有支付完成，一般支付这个动作2分钟内就能完成了吧,所以可以判断是不是这个支付订单是不是已经生成超过2分钟了，超了直接取消。（这样 支付完成 同时 订单被取消 的可能性已经很低了，估计几千个出不了一个，等客户找客服解决就行了吧 :joy:）。2、. . .

大概看了一下，你这个根本问题是：订单的状态的变化。
我的想法是，用户支付的优先级最高，所以在支付回调那里加一个锁好了。如果客服取消动作先执行了，那么支付回调那里就可以覆盖掉这个状态。
如果支付回调先执行了，上一个锁，让客服取消动作无法执行。

如果用户支付了之后，回调查询订单状态是取消，那直接调用退款接口，把钱退给用户不就好了

订单支付状态单独一个字段记录，收到支付成功的回调就更新为已付款。如果订单被取消就可以根据支付状态自动退款或者人工退款

订单取消 期限规定为 24小时 可以在后台规定订单实际25小时的时候改为取消状态 ,后端不再返回 超过24小时的订单暴露给用户,用户在23点59分支付的时候 回调接口 照常接收 支付的回调最多十几分钟 半小时 不会超过1小时 这样子是不是更简单 :stuck_out_tongue_closed_eyes: