我使用Stripe Checkout，然后在“测试”模式下，我故意返回400 http响应或超时响应200 http响应到“测试”模式中的Stripe，然后我等待从 Stripe 重试了 9 小时，但 Stripe 没有向我的 webhook 发送重试。因此，我打开了 查询错过的事件页面，然后 Stripe 立即将带有 事件类型“setup_intent.created”的重试发送到我的 webhook。
重试逻辑说：
在测试模式下，Stripe 在几个小时内重试 3 次。此时间后可以在仪表板中手动重试 Webhook，您还可以查询错过的事件以协调任何时间段内的数据。
内置重试 说：
Stripe Webhook 具有针对 3xx、4xx 或 5xx 响应状态代码的内置重试方法。如果 Stripe 没有快速收到事件的 2xx 响应状态代码，我们会将该事件标记为失败并停止尝试将其发送到您的端点。几天后，我们会通过电子邮件向您发送有关配置错误的端点的信息，如果您没有解决该问题，我们会很快自动将其禁用。
我在“测试”模式下使用Stripe Checkout提出的问题：
通常要从Stripe获得3次重试，是否需要等待几个小时以上（2、3小时或更长时间）？
是的，在测试模式下，初始事件传递失败后会在短时间内自动重试。 Stripe 将重新尝试交付测试模式事件最多 3 次。
要立即从 Stripe 重试，我是否需要打开错过事件页面的查询？
您无法通过 API 手动触发事件重试，这只能通过仪表板完成。
重试时的事件Stripe 重试的事件类型是否始终为“setup_intent.created”？
type
field 将始终与原始事件传递尝试相同。如果这是一个
setup_intent.created事件，那么
type字段将反映这一点。
如果Stripe没有收到2xx响应状态码或者没有很快收到2xx响应状态码，Stripe是否会发送3次重试？我们希望立即收到
200
回复。建议您在运行 Webhook 可能需要处理的任何自定义逻辑之前返回
200响应，否则您将面临事件未传送的风险（即使已处理）。无论 Stripe 是否未快速收到 2xx 响应状态代码，打开错过事件页面的查询是否会发送重试？
通过 API 查询事件不会
重新尝试事件传递。这个想法是，在事件传递失败后，您可以通过从 API 查询这些对象来协调任何丢失的事件。
重试3次，是否需要等待Stripe Checkout超过9小时
下使用- ？ 不。从我一周的实验来看，至少在
“测试”模式
，我发现 Stripe 不会向我的 webhook 发送任何重试 大部分时间 即使我有意返回 400 http 响应 或响应超时 200 http 响应 到 Stripe。 从
Stripe重试的事件类型是否始终是“测试”模式“setup_intent.created”
，在- ？ 根据我一周的实验，至少使用
Stripe Checkout
，是是。我为 4 个事件类型“ payment_intent.created”、“ payment_intent.succeeded”、“charge.succeeded”和“checkout.session.completed”一一返回了 400 http 响应，然后等待 的重试条纹。最后，Stripe 为所有 4 种事件类型发送了 “setup_intent.created”。 实际上，我向Stripe支持询问了
“1”和“3”问题花费了超过3或4个小时，但他们甚至不太了解Stripe，这意味着可怕的支持吃饭时间。所以，你最好自己解决有关 Stripe 的任何问题，因为你比他们更了解 Stripe。或者只是使用其他支付服务。