在我的 Spring Boot 应用程序中，我正在监听来自 Stripe 的 webhook 事件，特别是“invoice. payment_failed”和“invoice. payment_succeeded”。我已经实现了以下逻辑来管理本地数据库中的订阅详细信息：
对于“invoice. payment_failed”事件，我从 Stripe 检索订阅详细信息，检查它是否存在于我的本地数据库中，如果存在，我用最新的 Stripe 订阅详细信息更新它。如果没有，我会将订阅保存在本地数据库中。
同样，对于“invoice. payment_succeeded”事件，我遵循相同的逻辑在本地数据库中检查和更新或保存订阅。
当 Stripe 在单次订阅付款期间连续发送两个 Webhook 事件时，就会出现挑战。每个事件都被视为一个新请求，Spring Boot 在请求池中处理它们。有时，两个请求同时执行，如果在我的数据库中找不到订阅，则可能会导致重复条目。
那么如何解决这个问题呢？请指导我
尝试在 stripe webhook 期间引导并解决此类场景。
对于这种类型的场景，我有一种方法
但这不是大级别的最佳实践，因此提供一些最佳实践来解决此类场景。
如何解决此类场景请指导我
我可能是错的，但我认为你所指的重复场景与这个怪癖有关：
为什么要stripe先发送invoice. payment_failed webhook
invoice. payment_failed 事件可以从需要操作的付款中触发，这些操作可能会自动完成并在稍后立即生成invoice. payment_succeeded。
此怪癖应该仅发生在订阅的第一张发票上，即当客户处于会话状态并且可以在需要操作问题后立即进行身份验证时。
回到您的数据库问题，我要做的是有条件地忽略发票. payment_failed 事件：
-如果invoice.billing_reason == subscription_create则忽略。
毕竟，如果发票付款在订阅开始时失败，我认为存储订阅没有多大意义。
-如果invoice.charge为空则忽略。
这指的是上面概述的怪癖，尽管它也适用于由于客户没有默认付款方式来收费而失败的发票付款。
-改为监听 payment_intent-level 和 charge-level 事件，因为它们没有上述怪癖。但它们不会包含订阅，您需要检索并扩展资源才能获取它。
https://stripe.com/docs/api/expanding_objects