在电商及金融类的系统中，用户在下完单之后没有立即付款，订单处于未支付状态，默认情况下订单会有30分钟或者1小时左右(具体时间可以设置)的超时时间。在此期间用户可以选择立即付款，支付成功后订单进入待发货状态，等待商家发货。若超过规定的付款时间，那么订单会被关闭，库存及使用到的优惠(包含优惠券、积分)都将会被返还。那么如果订单超时时间到期需要关闭订单，并且此时正好用户也支付成功了，对于订单服务来说该如何处理呢？

明确订单终态

正常情况下，支付业务只有支付成功和支付失败(用户取消)两种状态，两者中必有一个能进入到终态。必须明确一点的是，无论哪一个都代表着业务的最终态，不能被改变。如果终态随便转换，那么在设计上一定是不合理的。

业务处理

有两种情况:

• 第一种: 用户支付成功处理成功，订单超时关闭处理失败;

• 第二种：订单超时关闭处理成功，用户支付成功处理失败。

针对上面的这两种情况，如果用户已经支付成功，面对订单超时关闭的请求可以直接拒绝，也符合正常的业务逻辑。不过，要是出现订单超时关闭成功，但支付成功处理失败了，这样的情况该如何处理呢？用户的钱怎么处理？原路返回吗？

没错，就是原路返回。订单超时关闭了，用户支付成功会触发支付回调，开发人员可以在回调处理的过程中，如果发现订单已经被关闭了，那么就得触发退款流程，把钱退给用户。 这样，即使订单超时关闭了，但是用户付过的钱已经退回了，对用户来说也并不存在损失。

❝

注：退款流程可能存在失败的情况，开发人员需要做好幂等以及兜底方案。

❞

对账机制

类似这些与支付有关的业务，引入对账机制是必要的。根据支付流水以及支付单的状态以及用户的支付、退款情况，逐一比对(支付金额=冲退金额)。如果发现不一致的情况，要根据用户的实付金额进行退款重试，直到完全一致。

加锁

具体来说就是出现了并发问题，无论是用户支付成功回调还是订单即将超时关闭订单，在执行业务逻辑之前，都需要加锁控制，并且一定是分布式锁。谁抢到了这笔单子的锁，谁先处理，没抢到的只能等待下次重试。这样做不仅能够解决并发问题，而且也能够避免异常情况的出现。

总结

上面的方案整体看下来，能够很好的解决订单超时到期关闭，同时用户也支付成功出现的并发问题，不过除此之外，仍需做好幂等以及兜底方案，确保实际业务系统能够正常稳定运行。