如何设计避免订单出现重复支付的逻辑？（幂等）

A.后台设计逻辑：

   1.参与的主体：

        电商系统

        网银或者第三方支付平台

        电商用的结算平台(例如商户支付宝，商户翼支付等)

   2.设计的主要流程：

        电商系统调起网关支付，订单跳转到网银或者第三方支付平台中进行实际支付，这时订单中包含的信息是由电商用的结算平台先生成的一个支付订单信息(这个支付信息包含与电商系统与网银或者第三方支付平台的关联)；用户在网银或者第三方支付平台中进行实际支付(这个支付交互是网银或者第三方支付平台与结算平台的交互)，成功之后才是结算平台反馈支付信息给电商系统。

       下列图中

                 是用户调起网关支付，订单跳转到网银或者第三方支付平台中进行实际支付。

                 是用户支付成功后，订单反馈至电商系统。

现在出现重复付款的问题就是出现在中的网银或者第三方支付平台到电商用的结算平台出现了延迟的情况，导致在电商系统中的订单一直处于未付款状态，部分用户以为未支付就最终产生了重复付款。

B.如何避免

   针对这个问题，思考了各种场景以及情况，这种模式是无法避免重复付款的（必须得看结算平台的处理效率-一般情况下还是比较好的，还是少有延迟的情况）。只能后台检测重复付款的订单，异常走退款流程。

   除非系统本身具有支付平台的功能。

C.延伸问题，如何处理因为支付成功后因延迟回调而订单被取消

   这个问题的出现背景也是因为第三方结算平台延迟反馈而造成用户错以为没有支付而取消订单或者是系统到时时自动取消订单

    解决办法：

           建立异常处理机制，机制如下：

        结算平台延迟返回成功的支付信息给电商系统时，如果判断出此订单已经取消。则进入异常处理机制，更改订单为已收款状态，并再次扣减订单中库存以及各种优惠（例如：价保，返利，促销费，优惠等等）的回退。当然再此扣减的时候需要先判断相关产品的库存以及用户的各种优惠是否满足订单的扣减，不满足则不允许转化。

    这里是应该先判断再次扣减的库存以及各种优惠，再修改订单状态，步骤以及相关的支付信息为成功。

第三方返回的状态实际是3种，返回成功，返回失败和无返回。当无返回时，如果处理成返回失败，就会让用户支付两笔，这本身是一种最糟糕的选择。沿着这个最糟糕的选择去做退款逻辑，是错上加错。

我们应该引入一个单独的支付层，它可以做两个事情：1.delay第2次支付请求  2.通过另一组接口查询第1次支付状态。 在最无能为力的情况下，提示用户异常并在24小时内对账后处理解决。当然用户如果确实急的不行，另下一单即可。

说回真实情况，支付宝等第三方成熟的支付平台，自然会根据重复的购物订单号来做好预防

问题：

• 如果用户出现了2次支付并且都成功了，后台逻辑退款这一块如何设计？

这块其实要通过账务的对账长款能区分出来，理论上来讲第二天支付通道返回的交易流水文件每一笔跟你的订单交易记录是一一对应的。一旦有一笔订单支付N次的话，则可能出现一个现象就是支付通道返回的交易流水会多出（N-1）笔，那这些就是长款，财务确认无误后可以手动发起退款。

• 是否可以避免这种情况的发生？如果可以怎么去避免呢。

理论上每一笔订单发起支付的时候都会有统一下单的过程，会把订单单号作为外部交易流水号加上其他信息打包去支付方生成支付订单，如果一笔订单在支付方已经支付的话，用户再次打开这个页面应该是会被提示订单已支付。除非每次点击“支付”生成的支付通道流水号都不是唯一，则可能出现。

同时，建议你在后端做一些未支付订单主动查询的动作，例如：最近15分钟生成的未支付订单后端主动查询一下支付状态”等等，可以优化这块的困扰。

参考4）

接口支持幂等性的话，同一条流水只会执行一次，就算无返回，再次发起时会直接返回结果，不会执行的。