stripe 官方不支持 webhook 重新启用后的批量事件补发；其重试机制仅针对单次 http 失败（如超时或非 200 响应），且实际重试行为受限、不可靠，开发者需自行实现事件拉取与幂等处理。
stripe 官方不支持 webhook 重新启用后的批量事件补发；其重试机制仅针对单次 http 失败（如超时或非 200 响应），且实际重试行为受限、不可靠，开发者需自行实现事件拉取与幂等处理。
当 Stripe Webhook 因服务中断（如进程崩溃、网络故障）从 Enabled 变为 Disabled 后，即使你通过 stripe listen --forward-to ... 重新启动监听，Stripe 不会自动回推此前未送达的事件。这是关键前提——Stripe 的重试设计并非“断点续传”，而是面向单次请求失败的瞬时补偿：仅对某次事件投递返回非 200 响应（如 400、500）或响应超时（默认 30 秒）时，按指数退避策略重试最多 3 次（间隔约 10s → 30s → 1min），且仅限该单个事件。
⚠️ 实测验证表明：
- 在 Test 模式下，即使主动返回 400 Bad Request 或人为延迟响应，Stripe 对常见业务事件（如 payment_intent.succeeded、checkout.session.completed）的重试成功率极低；
- 偶尔触发的重试可能错配事件类型（例如请求 payment_intent.created 失败后，却收到 setup_intent.created），无法保证原始事件的准确补发；
- Stripe 官方支持团队对此行为缺乏明确文档与稳定保障，不应将其作为生产环境的可靠性依赖。
✅ 正确解决方案：主动拉取（Polling） + 幂等消费（Idempotent Processing）
-
记录最后成功处理的事件时间戳或 ID
在 Webhook 处理逻辑中，持久化存储最新成功处理的 event.created 时间（Unix timestamp）或 event.id：# 示例：Django 视图中更新最后处理时间 from django.core.cache import cache def stripe_webhook(request): payload = request.body sig_header = request.META['HTTP_STRIPE_SIGNATURE'] event = None try: event = stripe.Webhook.construct_event( payload, sig_header, settings.STRIPE_WEBHOOK_SECRET ) except ValueError as e: return HttpResponse(status=400) except stripe.error.SignatureVerificationError as e: return HttpResponse(status=400) # 处理事件逻辑... process_event(event) # 更新最后成功处理时间（使用缓存或数据库） cache.set('stripe_last_processed_at', event.created, timeout=None) return HttpResponse(status=200) -
服务恢复后，调用 Events API 拉取遗漏事件
使用 Event.list() 接口，按时间范围查询未处理事件（推荐 created[gte] + limit=100 分页）：# 获取最近 24 小时内未处理的事件（需替换 YOUR_API_KEY 和 last_ts） curl "https://api.stripe.com/v1/events?created[gte]=1717027200&limit=100" \ -H "Authorization: Bearer sk_test_..." \ -G
# Python 示例：补全逻辑 last_ts = cache.get('stripe_last_processed_at', 0) now_ts = int(time.time()) events = stripe.Event.list( created={'gte': last_ts, 'lt': now_ts}, types=[ 'payment_intent.succeeded', 'charge.succeeded', 'checkout.session.completed', 'invoice.payment_succeeded' ], limit=100 ) for event in events.auto_paging_iter(): if event.id != last_processed_id: # 避免重复处理自身 process_event(event) -
强制幂等性：每个事件必须可重复安全执行
- 使用 event.id 作为唯一键写入数据库（带 ON CONFLICT DO NOTHING 或 INSERT IGNORE）；
- 所有业务操作（如创建订单、更新库存）前先校验该事件是否已处理；
- 避免依赖本地状态判断“是否首次到达”。
? 补充建议：
- 生产环境务必启用 Stripe 的 Webhook Signing 并严格校验签名，防止伪造事件；
- 将 stripe listen 仅用于开发调试；生产环境应部署高可用 Webhook 端点（如负载均衡 + 健康检查 + 自动重启）；
- 考虑引入消息队列（如 RabbitMQ / SQS）解耦接收与处理，提升容错能力；
- 定期审计 Webhook 日志与事件处理成功率（可通过 Stripe Dashboard 的 “Events” 标签页或 Event.list API）。
归根结底，Stripe 的 Webhook 是“尽力投递”而非“确保送达”。将可靠性责任交还给应用层——通过主动拉取 + 幂等设计，才能真正掌控事件流的完整性与一致性。
