Invoice Ninja中Mollie支付重复记录问题的分析与解决方案

问题背景

在使用Invoice Ninja（版本v5.10.29）的自托管环境中，当用户通过Mollie支付提供商使用iDeal方式支付发票时，系统会错误地创建两个相同的支付记录。这两个支付记录具有完全相同的金额、发票编号、日期、类型和交易参考号，但状态不同：一个标记为"completed"（已完成），另一个标记为"not applied"（未应用）。

技术分析

问题根源

经过深入分析，这个问题源于Mollie支付网关的两种通知机制同时触发的竞态条件：

1. 交易状态轮询：Invoice Ninja会主动查询Mollie的交易状态
2. Webhook回调：Mollie在支付完成后主动向Invoice Ninja发送支付结果通知

当这两种机制几乎同时到达系统时，虽然系统有检查交易引用的逻辑，但由于时间上的精确重叠，导致系统无法正确识别这是同一个交易，从而创建了重复的支付记录。

数据表现

从系统日志中可以观察到：

• 两个支付活动记录在同一分钟内创建
• 分别来自不同的IP地址（一个IPv4和一个IPv6）
• 活动类型ID显示为10（支付创建）和54（支付更新）
• 虽然引用了相同的发票ID，但生成了两个不同的支付ID

解决方案

Invoice Ninja开发团队在v5.10.30版本中实施了以下修复措施：

1. 延长Webhook延迟：通过增加Webhook处理的延迟时间，确保不会与交易状态查询同时处理
2. 增强竞态条件防护：优化了交易引用检查逻辑，防止在极短时间内处理相同交易

实施建议

对于遇到此问题的用户，建议：

1. 升级到v5.10.30或更高版本
2. 检查现有重复支付记录，手动标记或删除重复项
3. 监控支付处理日志，确认问题是否已解决

技术启示

这个问题展示了在支付系统集成中常见的竞态条件挑战。开发者在设计支付处理流程时需要考虑：

• 异步通知机制与主动查询的协调
• 分布式系统中的时间同步问题
• 事务处理的幂等性设计
• 网络延迟和重试机制的影响

通过这个案例，我们可以更好地理解现代支付系统中处理重复交易的技术挑战和解决方案。