如何处理Stripe Webhook请求延迟引发的时序差异问题？

以下是几个可靠的解决思路，完全避开盲等的setTimeout：

1. 基于会话ID的智能轮询 + 后端兜底查Stripe API #

用户从Checkout返回前端后，前端获取当前的Checkout会话ID（可从URL的session_id参数提取，或跳转前存在本地存储），然后向后端发起轮询请求。后端处理逻辑：

• 先查询数据库，确认是否已有对应账户；
• 若没有，直接调用Stripe的checkout.sessions.retrieve或subscriptions.list接口，验证该会话对应的订阅是否已创建；
• 如果Stripe侧确认订阅已存在，立即在数据库创建账户并返回数据；
• 如果订阅还未生成，返回“处理中”状态，前端间隔1-2秒后重试，直到拿到数据或触发超时提示。

这种方式不是盲等，而是基于实际的Stripe状态判断，比固定延时靠谱得多。

2. 长连接主动推送（WebSocket/SSE） #

前端加载完成后，立即通过WebSocket或SSE和后端建立长连接，并带上当前用户的标识（比如Checkout会话ID）。当后端的Webhook接收到customer.subscription.created事件、完成数据库账户创建后，直接通过长连接向前端推送“账户已就绪”的通知，前端收到通知后再调用接口获取账户数据。

这种方式是最及时的，完全不需要前端主动轮询，适合对实时性要求高的场景。

3. 前端跳转时携带订阅ID（可选优化） #

如果使用Stripe Checkout的success_url，可以配置Stripe在跳转时返回subscription_id参数（需要在Checkout会话创建时开启expand参数，展开subscription字段）。前端拿到subscription_id后，直接传给后端接口，后端可以用这个ID直接去Stripe查订阅详情，同时同步数据库，避免依赖Webhook的时序问题。

内容的提问来源于stack exchange，提问作者Alejandro Guajardo