开发人员如何防止扫码支付出现重复支付的情况?

作者:vkvi 来源:ITPOW(原创) 日期:2017-1-20

1、顾客出示支付码

2、商家扫码,但网络一直不畅,商家要求重扫

3、正好此时顾客手机的支付码自动刷新了

4、商家重新扫

5、网络通畅了,商家扫的两次码都提交了到服务器端了,产生了两次消费

开发人员如何避免这种情况呢?

设想一、顾客的支付码每次刷新时就向服务器废除前一次支付码。

但某些支付工具支持离线生成支付码,这显然与服务器无关,所以解决不了本文的问题。

设想二、那就每次支付时生成一个批次号,以后刷新支付码时,批次号不变,除非重新打开,商家不管提交了多少个扫码,只要批次号相同,就只有一个有效。

如果第 3 步中,顾客关闭了支付界面,又重新打开,就是两个不同的批次号了,所以这个虽然是必要的,但是仍然解决不了本文的问题。

设想三、商家上一个扫码既没有提交、也没有作废时,不允许继续扫码。

有点眉目了,但是还不够安全,就像我们网页不能仅通过 JS 来判断用户输入的合法性一样,继续看设想四。

设想四、商家每次扫码需向服务器请求,服务器先给商家一个凭据,商家有了这个凭据后,扫码才有效,每次只有一个凭据有效,每个凭据只能使用一次。

看似不经意,实际上很有作用,如上例中,第 2 步有点变化,先是请求了凭据,扫码后,才出现网络不通的情况。后来网络通了,那么只存在两个情况:

  • 第一个凭据失效,第一次扫码失效,重新请求凭据,第二次扫码成功。
  • 第一个凭据有效,第一次扫码有效,订单完成,无法继续扫。
    • 这里如果商家反编译程序强制继续扫,那么结合设想二,批次号相同,导致第二次扫码失败。
      • 如果非常不幸,用户是重新打开的支付码界面,批次号不同,同时商家第二次也做了一个假订单,的确会出现两次支付,因为这跟买两次东西的场景一模一样,计算机无法区分是不是恶意,只有消费者凭消费记录找商家理论了。

总结

两点很重要:商家先向服务器请求凭据,再扫码;支付码有个批次号。

相关文章