概述
支付系统涉及到资金交易，对数据安全性和一致性有较高要求。
本文简单介绍下几个常见对问题，和一些思考。（作者也是刚刚学习，有理解不对的地方敬请斧正）
防抵赖
支付系统中有一些操作/接口是必须对调用方进行身份强校验的。
- 支付结果回调
- 退款、撤销订单（订单回滚）
支付结果回调不作校验的话，如果回调是别人伪装的，就可能导致商户没收到钱，却通知他发货给下单人。
订单回滚操作不作校验的话，可能导致错误地把商户的钱退换给用户。
以上两种情况都会给商户带来损失。
支付回滚
防抵赖通常的措施，是通过密钥对支付关键数据进行签名，请求接收方校验签名。
对于支付系统而言，订单回滚通常需要使用非对称私钥。即支付系统的使用方使用私钥进行加密，然后支付系统通过公钥匙解密。
image.png能通过公有解密出来的信息，就是来自对应私钥的拥有者。从而做到防抵赖。
支付成功回调
支付成功回调相比支付回滚对支付系统对要求会低一些。（因为支付系统可以要求使用方收到回调后，需要进行订单查询确认，将一些责任转移到应用/商户）
image.png不过整体上，尤其对于不是很强势的小支付平台而言，非对称加密是比较常用的方式。
image.png重复支付问题
订单发生重复支付，也回增加系统使用方对负担。
重复支付问题有两个解决思路，
- 在支付时，一旦支付人发起支付，在限定时间内其他人不得对同一个订单发起支付，同时支付人必须尽快在限定时间内完成支付，否则支付票据失效，订单解锁。
- 确认无法杜绝重复支付时，可以做退款逻辑。（不过这块要尤为谨慎）
数据一致性问题
数据一致性主要是要避免因为网络问题或者系统对一些其它故障，要能够保证最终系统对整个链路中订单对状态是一致的。
- 数据回调丢失。（尽快回调通常回多次发起，但是还是有可能出现全部丢失的场景）
- 退款请求没有应答。（系统下游收到退款请求，且执行了实际动作，但是应答丢失了）
image.png在退款时，支付系统或应用，一旦想下游发起请求时，不过有没有收到应答，订单的状态都必须更改为退款中。后续在通过应答，或者订单的延时查询将订单的状态修正为确定状态（退款成功或失败）。
