在我们支付系统设计中，经常会遇到这样一个问题，防止用户重复支付。那么实际我们在设计支付系统时，如何来避免这一问题呢。

比如下单的按键在点按之后，在没有收到后端返回之前，按键的状态没有设为已禁用状态，还可以被按。

用户在收银台页面点击某个支付方式后，在支付渠道（比如网银或者微信支付宝）上完成付款，但是渠道端返回的异步通知超时，导致系统付款状态尚未更新，用户并不清楚到底订单是否支付成功，而导致再次支付。

在我们实际支付系统设计中，我们系统设计人员经常无法区分商品订单和支付订单之间的关系，经常混为一谈。所以本文谈论的是支付订单的防重复，商品订单的防重复需要另外讨论（包括用户误操作、客户端和后台时延、以及支付和商品订单状态更新不同步等问题）。

对于支付重复提交的处理，一般有两种主流的办法：

这里，我们重点讨论第二种方式，保持支付订单的幂等性来防止重复支付。

针对一笔商品订单，在支付时，产生一个唯一的支付订单号，这个支付订单号包含了客户选定的支付落地的支付方式和真正的支付渠道。

支付系统需要对这个支付订单号做交易的幂等。

如果用户执意重复下商品订单

如果出现上述4里面最坏的情况，还是会有用户误操作或者执意下了第二次单，直到收到两份商品才发现下重了。此时就得依靠运营/客服的支持了。提供用户申诉的手段，让用户提出哪些订单是重复的，并且由销售系统店家、商品提供者和买家三方共同根据用户操作的记录来协商如何处理。我们需要让技术帮助让这种人工处理的几率尽量小。因为每次处理都会耗费较大的人工成本，和一些运营费用（比如赔款、小礼品等等）。

在实际设计中，无论多么好的技术，也不可能100%的拦截所有的可能性，必须依靠技术+产品设计+运营支持的综合手段才能解决这类问题。所以即便京东这一类电商等也是配合运营手段进行处理。

在实际业务场景中，可能还会有各种各样复杂的情况，我们只能以尽可能保护我们系统自己的方式，将重复下单可能性降到最小，并且即使发生，我们也不能出现短款，再结合运营手段进行差错处理。