支付系统常见问题与解决方案

概述

支付系统涉及到资金交易，对数据安全性和一致性有较高要求。

本文简单介绍下几个常见对问题，和一些思考。（作者也是刚刚学习，有理解不对的地方敬请斧正）

防抵赖

支付系统中有一些操作/接口是必须对调用方进行身份强校验的。

• 支付结果回调
• 退款、撤销订单（订单回滚）

支付结果回调不作校验的话，如果回调是别人伪装的，就可能导致商户没收到钱，却通知他发货给下单人。

订单回滚操作不作校验的话，可能导致错误地把商户的钱退换给用户。

以上两种情况都会给商户带来损失。

支付回滚

防抵赖通常的措施，是通过密钥对支付关键数据进行签名，请求接收方校验签名。

对于支付系统而言，订单回滚通常需要使用非对称私钥。即支付系统的使用方使用私钥进行加密，然后支付系统通过公钥匙解密。

image.png

能通过公有解密出来的信息，就是来自对应私钥的拥有者。从而做到防抵赖。

支付成功回调

支付成功回调相比支付回滚对支付系统对要求会低一些。（因为支付系统可以要求使用方收到回调后，需要进行订单查询确认，将一些责任转移到应用/商户）

image.png

不过整体上，尤其对于不是很强势的小支付平台而言，非对称加密是比较常用的方式。

image.png

重复支付问题

订单发生重复支付，也回增加系统使用方对负担。

重复支付问题有两个解决思路，

• 1. 在支付时，一旦支付人发起支付，在限定时间内其他人不得对同一个订单发起支付，同时支付人必须尽快在限定时间内完成支付，否则支付票据失效，订单解锁。
• 1. 确认无法杜绝重复支付时，可以做退款逻辑。（不过这块要尤为谨慎）

数据一致性问题

数据一致性主要是要避免因为网络问题或者系统对一些其它故障，要能够保证最终系统对整个链路中订单对状态是一致的。

• 数据回调丢失。（尽快回调通常回多次发起，但是还是有可能出现全部丢失的场景）
• 退款请求没有应答。（系统下游收到退款请求，且执行了实际动作，但是应答丢失了）

image.png

在退款时，支付系统或应用，一旦想下游发起请求时，不过有没有收到应答，订单的状态都必须更改为退款中。后续在通过应答，或者订单的延时查询将订单的状态修正为确定状态（退款成功或失败）。