本文详细探讨了支付过程中如何处理重复支付、支付回调的幂等性、接口安全以及补偿机制的重要性，包括前端和后端的解决方案，以及加密签名和验签的作用，旨在提升支付系统的稳定性和用户体验。
目录
2、支付回调幂等的问题（具体怎么做的，为什么用它，解决了什么问题）
3、回调接口安全问题（具体怎么做的，为什么用它，解决了什么问题）
4、回调收不到补偿机制（具体怎么做的，为什么用它，解决了什么问题）
时序图
1、在支付的过程中会出现重复支付的问题
怎么解决：
前端：
在前端页面，当用户点击支付按钮时，你可以使用JavaScript或其他前端技术禁用支付按钮，防止用户重复点击。（但请注意，前端校验并不完全可靠，因为用户可以绕过前端直接发送请求到后端。因此，后端校验是必须的。）
后端业务逻辑处理：
（1）使用唯一标识，每次支付请求都生成一个唯一标识，并将该标识保存到数据库中。在处理请求的时候，先排查该表示是否已经存在，如果存在说明是重复请求，直接拒绝
（2）状态管理，给支付请求定义一个状态，例如：待支付、已支付、支付失败等。当请求呗处理的时候，更新该请求的状态对于已支付和支付失败的状态不再处理新的支付请求
2、支付回调幂等的问题（具体怎么做的，为什么用它，解决了什么问题）
为什么要使用幂等（为什么用它）：
幂等性确保即使相同的操作被执行多次，其结果仍然与只执行一次相同，从而避免了数据不一致、重复处理或其他潜在的副作用。
支付模块幂等性实现不当或未实现，可能带来以下影响：
（1）订单状态不一致：如果支付回调没有被设计为幂等，那么当同一个支付通知被多次发送时，系统可能会多次更新订单状态，导致订单状态从“未支付”错误地变为“已支付”多次，或者出现其他不一致的状态。
（2）资金风险（在代码中金额方面是重中之重）：重复的支付处理可能导致资金的重复入账，或者多次执行退款操作，造成资金损失。
（3）业务逻辑重复执行：如果支付成功后的业务逻辑（如发货、赠送积分等）没有被设计为幂等的，那么这些逻辑可能会被重复执行，会造成成本和用户体验的问题
（4）系统性能下降：大量的重复支付回调请求会占用系统资源，导致性能下降，大概率会引起性能的故障
（5）用户体验问题：用户可能会收到重复的支付成功的消息，或者因为订单状态不一致而遇到订单查询和售后的问题，影响用户体验
使用幂等性主要是为了解决以下问题（解决了什么问题）：
（1）网络不稳定导致的重复请求：在网络环境中，请求可能会因为网卡、超时等原因被重复发送。幂等性确保即使收到多次请求，系统也能正确处理。
（2）重试机制：许多系统为了实现高可用性和容错性，会引入重试机制。幂等性确保在重试过程中不会引发不必要的问题。
（3）并发请求：在并发环境下，多个请求可能同时到达并尝试执行相同的操作。幂等性确保这些请求不会导致数据不一致或其他问题。
（4）用户体验和稳定性：通过确保操作的幂等性，可以提高系统的稳定性和用户体验，减少因重复操作或不一致状态导致的用户投诉和问题。
幂等常见的实现策略（具体怎么做）：
（1）缓存：使用redis来存储和处理请求。在将请求放入缓存之前，检查是否有相同的请求存在。如果存在，则不放入或忽略（redis的好处：查询效率快应为redis存储是在本地）
（2）根据交易流水号查状态：记录每个交易流水号的状态，并在处理时检查状态。例如，对于支付请求，可以记录支付状态（如“未支付”、“已支付”等）。当收到支付请求时，先检查状态，如果已经是“已支付”，则不再处理。
3、回调接口安全问题（具体怎么做的，为什么用它，解决了什么问题）
加密签名：
生成签名（具体怎么做）：
（1）发送方将需要传输的数据（如请求参数）按照一定规则（如字典序）进行排序和拼接。
（2）使用预共享的密钥（如API密钥）和加密算法（如HMAC-SHA256）对数据进行签名，生成一个签名值。
（3）将签名值附加到请求数据中，一起发送给接收方。
为什么使用加密签名：
（1）数据完整性：签名能够确保数据在传输过程中没有被篡改。如果数据被修改，签名值将不匹配，从而可以发现数据的完整性受到破坏。
（2）身份验证：通过签名，接收方可以验证发送方的身份。因为只有知道预共享密钥的发送方才能生成正确的签名。
验签：
验证签名（具体怎么做）：
（1）接收方收到请求后，提取出签名值和请求数据。
（2）使用相同的预共享密钥和算法，对请求数据进行签名计算。
（3）将计算出的签名值与接收到的签名值进行比较。
（4）如果两者一致，则签名验证通过，表示数据完整且发送方身份可信；否则，验证失败，拒绝处理请求。
为什么使用验签：
（1）防止黑客攻击：通过验签，可以确保数据在传输过程中没有被黑客篡改或伪造
（2）增强安全性：及时请求数据被拦截，没有共享秘钥也无法生成有效的签名来伪造请求
验证签名解决的问题：
（1）数据篡改：保证数据的完整性
（2）身份伪造：确认发送方的身份，防止伪造请求
（3）黑客攻击：即使黑客尝试拦截和修改请求，没有有效的签名就会被识别阻止
4、回调收不到补偿机制（具体怎么做的，为什么用它，解决了什么问题）
具体怎么做：
（1）定时查询交易流水表：
①设置一个定时任务，每隔一段时间扫描交易流水
②筛选出那些状态为“处理中”切超过一定时间阈值的记录
（2）根据单号查询支付宝状态：
①对于筛选出的每一条记录，提取其对应的交易单号
②使用这些交易单号去调用支付宝的API或其他查询接口，获取交易在支付宝端的实际状态
（3）修改交易流水信息和订单状态：
①根据支付宝返回的状态信息，更新交易流水表中的状态字段
②如果支付宝状态表示交易已成功，则更新订单状态为已支付或其他相应状态
③如果支付宝状态表示交易失败或超时，则进行相应的处理，如退款、通知用户等
为什么使用补偿机制：
（1）网络不稳定：在实际应用中，由于网络延迟、抖动或中断，回调通知可能会丢失或延迟到达
（2）回调处理失败：即使回调通知被接收，但由于系统内部错误或逻辑异常，也可能导致回调处理失败
（3）第三方服务问题：第三方支付平台自身也可能存在服务不稳定或故障的情况，导致回调通知无法正常发送
解决了什么问题：
（1）数据一致问题：补偿机制确保了即使回调通知未能成功接收或处理，交易状态也能与支付宝端保持一致，避免了数据不一致的问题
（2）用户体验：对于用户而言，即使遇到网络问题或系统故障，他们也能通过查询订单状态或收到相应通知来了解交易的实际结果，提升了用户体验
（3）业务连续性：对于商家而言，补偿机制确保了业务的连续性，即使在部分环节出现问题时，也能通过主动查询和同步来确保交易的最终状态正确无误
188
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
