在线支付不陌生，来聊聊如何防止电商订单重复支付及流程

hwyzw

    大家对网络支付应该都很熟悉，今天咱们就来探讨一下如何避免订单重复付款的问题。

    看看订单支付流程

    我们来看看，电商订单支付的简要流程：

    订单钱包支付流程

    从下单/计算开始：

    下单或结算环节：尽管它并非支付流程的起始阶段，然而支付所需的所有金额及相关信息均源自于此环节；在此阶段，订单的当前状态显示为未支付状态。

    用户若选择进行支付操作，客户端将启动支付服务，随之在系统内部生成一条支付记录，该记录的当前状态标识为尚未支付。

    启动支付流程：当支付服务接入第三方支付平台时，特别是在启动支付环节，系统会生成相应的支付链接，随后客户端需对这些链接进行相应的操作处理。

    使用钱包进行交易时，用户一般会通过相应的钱包应用来完成支付操作；不妨回想一下，在购物时，我们进行支付的具体步骤。不同平台对于钱包支付的处理方式存在差异。

    京东PC端支付页

    APP 端

    在我国，消费者进行购物活动大多通过应用程序进行，产品经理们会竭尽所能引导用户进入APP。那么，为何我在示例图中选择京东而非淘宝呢？原因在于，当我使用UC浏览器打开淘宝时，页面会自动跳转至其APP界面。

    我们对于APP中的钱包支付功能应当相当熟悉，通常操作步骤是打开钱包，然后进行支付。

    APP支付

    WAP 端

    手机上网页或使用WAP服务进行支付时，通常直接唤起相应的钱包应用，一旦钱包应用启动失败，系统则会自动跳转至其他界面。

    京东支付 WAP端

    PC 端

    在电脑端，一般会启动收银系统，显示一个二维码，顾客可以通过扫描钱包中的二维码进行支付，紧接着便会出现京东的微信支付扫码界面。

    支付完成后，三方支付平台将向商户发送回调信息，以告知支付的具体结果。

    同步订单信息：支付环节完成支付确认后，会将支付结果传递给订单环节，订单环节据此调整订单状态，从未支付变为待发货。客户端则通过不断查询、维持长连接，或由服务端主动发送通知，来在界面上更新订单的显示状态。

    我们再从支付流水的角度看一下支付状态的变化：

    支付状态变化

    为何要占用如此多的篇幅来阐述支付流程和交互细节？这主要是因为我坚信，避免订单重复支付的问题，不仅涉及技术层面，同样也是业务和产品设计领域的关键议题。

    为什么订单会重复支付

    未防重导致的重复支付

   

    观察可知，在PC端进行支付时，用户需通过扫描二维码来完成，而这些二维码实际上与各自的支付记录相对应。若用户连续多次点击支付按钮，若未采取防止重复操作的措施，系统将生成两笔独立的支付记录，即两个不同的二维码。一旦用户分别扫描了这两个不同的二维码，便不可避免地会导致重复支付的情况发生。

    掉单导致的重复支付

    “我明明付款了，为什么我的订单还没支付呢？”

    黑我钱是吧

    这就是所谓的“掉单”：

    顾客发现已支付款项，却发现商城订单状态显示未支付，又因迫切需求，可能再次下单，从而导致重复支付的情况发生。

    多渠道导致的重复支付

    在国内进行支付操作的速度相当迅速，这一点或许大家并不明显感受到，但若是对比过海外的支付方式，或许便能体会其中的差异，因为海外支付往往需要耗费较长时间。

    保罗挑选了一种支付手段，但发现该支付点距离他们所在的村庄颇为遥远，于是他改换了支付方式。在赶集途中，保罗顺便前往该网点，处理了这笔支付，却不知自己已经重复进行了支付操作。

    大家或许很少遇到这样的情况，我们可以在美团上再下个订单，然后打开微信进行支付。但请注意，暂时不要进行支付操作，转而回到美团页面，打开支付宝进行支付。完成支付宝支付后，再用微信继续进行支付。大家不妨猜测一下，这两笔支付是否都能顺利完成呢？

    答案是可以。

    美团多渠道支付

    如何防止订单重复支付

    加锁

    在进行3.申请支付操作或是5.支付回调处理时，均需基于订单信息进行锁定，以避免在并发情况下发生重复执行的问题。

    锁定资源，毫无疑义，这属于分布式锁的范畴，我们一般倾向于采用 Redis 来实现分布式锁。

    加锁

    缓存结果

    申请支付成功，支付回调成功，都应该缓存结果。

    再申请支付，收到成功回调的时候，都应该先去检查支付的状态。

    支付中流水取消

    若用户已进行过重复支付，那么在后续再次发起支付请求时，若该请求已被成功处理，则该笔支付请求理应被拒绝。

    然而，若这笔交易仍在进行中，我们无法确定其结果究竟是成功还是失败，显然我们不能拒绝这笔支付。因为有可能用户已经支付失败，但系统状态尚未更新，这种情况下继续操作显然是不恰当的。

    所以，我们可以取消掉正在支付中的流水，再进行支付。

    支付中流水取消

    已支付流水退款

   

    现在又遇到了新的挑战，如果在发起支付操作时，已有交易正在进行，且第三方支付平台不提供取消支付的功能，或者用户的后续支付是通过另一条路径进行的，我们迫切需要提升用户的支付成功率，这该如何解决呢？

    在用户进行支付操作且订单正处于支付状态时，我们应允许其进行多次支付尝试。一旦支付回调发生，需核实用户是否已成功完成一笔支付，并据此对后续的支付流水进行相应的退款操作。

    支付回调

    自然，进行退款是一项充满风险的行为，因为一旦款项退还，便难以再次追索，因此务必高度重视风险防范。

    主动轮询与重试防止掉单

    若因设备故障导致未能接收到反馈，亦或反馈信息未能按时抵达，便有可能出现所谓的掉单现象。

    确保订单不因外部因素流失的关键在于，我们不应被动地依赖第三方的通知，而应采取主动策略，即在用户发起支付后的3秒内，便应启动查询机制，进行周期性的检查。这一过程，即所谓的主动轮询，通常可以通过以下方式实现：

    轮询

    1) 定时任务轮询

    通过设定定时任务，对表格内处于支付状态的交易记录进行扫描，并主动检索其支付进展。实现定时任务的方法众多，包括利用线程池、调度系统以及分布式调度系统等。

    定时任务轮询的缺点有两个：

    2) 延时消息轮询

    此外，一种可选策略是运用延迟发送的信息。用户在触发支付操作后，会发送一条延迟信息。在消费完成该延迟信息之前，用户需定期查询支付流水状态。若未能获取到最终状态，则需再次发送一条延迟信息。这种方法的优点在于对数据库的负载相对较小，且轮询的间隔可灵活调整。然而，其缺点在于实施过程较为繁琐，并且需要持续维护消息队列系统。

    同步+异步防止内部掉单

    一旦支付服务接收到异步通知的反馈，或者通过主动查询得知交易流程的最终结果，便需及时告知订单服务有关支付流程的变动情况。随后，订单服务需同步调整订单的相应状态。为确保这一通知流程的顺利完成，我们应尽量采用同步与异步相结合的通信模式。

    这里还有一个问题，客户端如何同步这个状态？

    由于服务端可能已更新订单的当前状态，然而客户端显示的界面依旧显示为未支付，用户需自行手动刷新页面以获取最新状态，这种做法显然不够理想。

    服务端、客户端的状态同步，无非就拉和推:

    客户端支付尽可能不外跳

    无论从产品层面还是技术层面来看，客户端在执行支付操作时，理应尽量避免跳出原页面；在PC端，应直接使用支付服务生成的支付码进行支付，而非进行页面跳转；至于移动端网页和APP，在应用内部展示支付页面，这一决策权则通常掌握在第三方支付平台手中。

    在UC内内嵌支付宝

    大家或许有所察觉，目前支付宝的功能已实现无需打开钱包，直接在应用内完成支付，这对商家来说影响颇深；同时，它对提升用户体验和支付成功率也起到了积极作用。鉴于我国市场的竞争激烈程度，相信其他支付服务提供商也必将效仿这一做法。

    - EOF -