支付系统设计中,如何防止重复支付?
金融民工小曾移动支付网2018/8/9 17:15:40

在我们支付系统设计中,经常会遇到这样一个问题,防止用户重复支付。用户明明只想购买一次,却因为系统问题,导致重复支付,带来额外的物流成本和扯皮退货的运营成本,对商家的信誉和系统的体验很不好。

那么实际我们在设计支付系统时,如何来避免这一问题呢。

为什么会出现重复支付

1.客户误操作点了两次

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

2.支付渠道端返回超时

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

如何防止重复支付提交

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

对于支付重复提交的处理,一般有两种主流的办法:一种是京东收银台的,京东允许客户对一笔商品订单做多次支付,而对于第二笔以上的支付,走退款流程;另外一种是对订单幂等要求比较高的银行收银台,往往是要求商品订单状态和支付订单状态强一致性。

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

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

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

1.如果不存在该支付订单号,则记库,并标记状态为支付中,然后调用渠道进行支付落地。

2.收到渠道异步通知或者通过查询得到渠道支付状态时,更新该笔支付订单状态

3.如果客户再次发起支付,不给客户产生新的支付订单号,先用该笔支付订单号调用支付系统,支付系统会判断订单号幂等性,如果已支付,则报错告诉客户已支付成功,请勿重复支付;如果支付失败,则新产生流水调用渠道进行支付落地;如果支付状态未知,则告诉客户,交易状态未知,请发起查询或者关单。

4.针对状态未知这种情况,如果支持冲正和关单则最好,如果不行,只能让客户发起查询。在这种情况下,如果客户等不及,才流转到最坏的可能,客户重新下一单商品订单,这单根据最终渠道对账情况,给客户做退款。这种情况下需提示客户确认未发起前一笔支付,再新创建,否则,前一笔需要等第二个工作日状态确认后进行退款处理。

如果出现上述最坏情况怎么办

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

结论

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

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

本文为作者授权发布,不代表移动支付网立场,转载请注明作者及来源,未按照规范转载者,移动支付网保留追究相应责任的权利。

展开全文
相关阅读
资讯查询取消