封面送给我狗哥~
Hello，大家好，我是楼下小黑哥~
今天的文章我们接着上次的话题，继续聊聊支付系统异常解决办法。
在上篇文章中「支付掉单异常解决方案」，我们主要提到的是支付过程中掉单的场景，用户明明付款成功，银行卡都扣款了，但是订单却还显示待付款。
而在今天的文章中，我们将聊到重复付款的异常，即同一笔订单，扣了用户两笔钱。
另外我们还将会提到另外一种异常，用户扣款成功，但是订单却支付失败的场景。
以上两种异常对于被扣款的用户来讲，使用体验极差，自己多付了钱，订单却还不成功。所以如果不及时处理这两类异常，那就真的等着被投诉吧。
欢迎关注我的公众号：程序通事，获得日常干货推送。如果您对我的专题内容感兴趣，也可以关注我的博客：studyidea.cn
重复付款异常 异常场景重复付款异常一般常见于网银支付，微信支付，支付宝等这类需要跳转到一个支付网关页（网银支付），或者跳转到钱包 APP(支付宝、微信)，从而异步完成扣款的支付场景。
这种支付场景下，只能通过接受异步通知才能知道支付结果，我们一般将其称为异步支付。
PS：有了异步支付，那么同步支付是什么？
其实同步支付指的就是调用支付接口之后，就可以立刻返回支付结果的，比如银行卡类快捷/代扣等支付就是同步支付。
当然也有一些奇葩的银行卡支付渠道，同步支付结果为受理成功，只能接受异步通知或者查询返回支付结果。
由于银行卡支付需要返回明确支付结果，对于这类渠道只能内部设计将异步转为同步,感兴趣可以看下之前历史文章：
架构设计|异步请求如何同步处理？
后台支付流程如下：
图片来自之前的文章:银行卡支付原理
主要原因其实跟上次内部掉单异常一样，跟业务表设计有关。
上次我们提到，支付系统主要表结构如下：
在这个表结构下，只要支付订单未成功，商户就可以重复使用其内部同一订单号调用支付接口。
假设这样一个场景，用户在收银台支付时选择招行进行网银支付，当他点击支付之后，商户系统将会调用支付公司的网银接口。
这时支付系统内部将会创建一笔支付单以及关联的渠道订单，并且调用招行系统的接口。
然后用户的浏览器页面将会打开一个新页面，然后跳转到招行网站。
这时如果此时用户再次在收银台点击支付，将会再次调用支付系统接口。这时候由于支付单已存在，所以仅仅会再创建一条渠道订单记录，并且调用招行系统的接口。这时用户的浏览器将会再次打开一个招行的网站。
如果用户在两个招行网银页都完成支付，这时就发生了重复付款。
上面这种场景看起来有点傻,但是真实用户操作真的会发生。除了这种，博客园上的小伙伴还提到这么下面这种情况：
重复付款异常的主要的解决办法有两种，分为事前与事后。
事前主要的目是尽可能防止用户重复付款，主要解决办法为优化付款页面，尽可能做好提示。
第一种优化方式，付款页面直接跳转到第三方/银行的网银页面，不要打开新的页面去跳转。
这种方式可以防止用户误打开两个网银付款的页面，从而导致重复付款。
但是这里会有一个问题，银行网银页面付款成功之后，用户如何知道其在商户侧订单状态也成功了？
其实很简单，现在网银支付接口，一般都会有一个参数 return_url:同步跳转地址 。