stripe 官方不支持在 webhook 重新启用后自动重发历史事件；其重试机制仅针对单次失败请求（如超时或非 200 响应），且实际重试行为受限、不可靠，无法用于批量补收停机期间的事件。
stripe 官方不支持在 webhook 重新启用后自动重发历史事件；其重试机制仅针对单次失败请求（如超时或非 200 响应），且实际重试行为受限、不可靠，无法用于批量补收停机期间的事件。
在基于 Stripe 构建支付系统时，Webhook 是接收关键业务事件（如 payment_intent.succeeded、checkout.session.completed）的核心通道。你使用 stripe listen --forward-to 启动本地监听服务（如 nohup ./stripe listen --forward-to https://example.com/stripe/webhook &），看似便捷，但该命令仅适用于开发调试——它不具备生产级可靠性：一旦进程崩溃、网络中断或服务器重启，监听即中断，且 Stripe 绝不会在你恢复 webhook 后“回填”此前错过的事件。
⚠️ 关键事实澄清（基于实测与 Stripe 文档验证）：
- Stripe 的重试机制是逐请求触发的：仅当某次事件推送返回 HTTP 状态码 ≥400 或响应超时（默认 5 秒）时，Stripe 才会对该单一事件发起最多 3 次指数退避重试（间隔约 10s → 30s → 1min）；
- 不存在“批量重放”或“历史事件同步”功能：Webhook 状态从 disabled 切回 enabled 不会触发任何事件补发；
- 实测表明：即使主动返回 400 或延迟响应，Stripe 对部分事件（如 checkout.session.completed）的重试成功率极低，甚至完全不重试——你观察到的 setup_intent.created 被重试，属于偶然匹配了 Stripe 内部重试策略的边缘情况，并非通用行为。
✅ 正确的生产级解决方案：主动拉取（Polling）+ 幂等处理
Stripe 提供了可靠的 API 接口 Events List，允许你按时间范围、类型、状态查询所有已发生事件。结合 webhook 的幂等性设计，可实现零丢失的事件补收：
# 示例：获取过去 24 小时内所有未处理的成功支付事件 curl "https://api.stripe.com/v1/events?limit=100&created[gte]=1717027200&created[lte]=1717113600&type=payment_intent.succeeded" \ -H "Authorization: Bearer sk_test_..." \ -H "Stripe-Version: 2024-06-20"
# Python 示例：安全补收 + 幂等入库
import stripe
from datetime import datetime, timedelta
stripe.api_key = "sk_test_..."
def fetch_and_process_events(since_ts: int, until_ts: int):
events = stripe.Event.list(
limit=100,
created={"gte": since_ts, "lte": until_ts},
types=["payment_intent.succeeded", "charge.succeeded", "checkout.session.completed"]
)
for event in events.auto_paging_iter():
# 关键：用 event.id 作为幂等键，避免重复处理
if not EventLog.objects.filter(stripe_event_id=event.id).exists():
handle_webhook_event(event) # 你的业务处理逻辑
EventLog.objects.create(stripe_event_id=event.id, processed_at=datetime.now())
? 实施要点：
- 时间窗口精准控制：记录每次成功处理事件的 event.created 时间戳，下次补收起始点设为该时间 + 1 秒，避免漏掉或重复；
- 幂等性是生命线：务必以 event.id 为唯一键持久化处理状态，Stripe 事件本身具备全局唯一性；
- 避免依赖 stripe listen 生产部署：改用反向代理（如 Nginx）+ 稳定 Web 框架（Django/Express/FastAPI）托管 /stripe/webhook 端点，并配置健康检查与自动恢复；
- 监控告警必须到位：对 webhook 端点 5xx 错误率、平均响应延迟、Stripe 重试次数（通过 Dashboard 或 Logs）设置阈值告警。
总结：不要等待 Stripe “自动补发”，而要主动掌控事件流。将 webhook 视为实时通知通道，将 Events API 作为权威数据源和兜底手段——这才是高可用支付系统的标准实践。
