… 根据几年前的个人经验，我对Stripe的web-hook方法总体上感到很恼火。支付流程信息是如此重要的商业问题，以至于“试着打电话给他们，如果失败了……我们已经尽力了”在原则上就是错误的。显然的做法是有一个事件列表，你可以作为客户进行长轮询，或者如果你的框架不支持异步，就每隔几秒轮询一次。这也很容易安全地实现：你的HTTPS库已经在TLS握手期间对Stripe进行了身份验证，而这已经足够了。[1] 最好的情况是让Stripe通过相互TLS进行身份验证，但我知道这与典型的Web服务器配置相去甚远。[2] Stripe的方法让我想起了DPoP https://news.ycombinator.com/item?id=31266575，这绝不能被当作一种称赞。
源讨论深入Cloudflare / Stripe / OWASP的兔子洞：一个深入6只兔子的故事原帖 127 条评论 · 导入时统计把你的经验，加入这段讨论。
> 显而易见的方法是维护一个事件列表，你作为客户进行长轮询，或者每隔几秒轮询一次 这对于支付集成开发者来说也更容易测试，相比测试网络钩子时需要的各种麻烦和运行不可靠的代理来说。 对于关键的应用路径使用网络钩子似乎从各方面来看都是个糟糕的主意
完整原文我想对您的一些观点发表一下我的看法，我并不认同： > 直接查看文档，他们建议你做的事情似乎是他们能想到的最糟糕的主意： https://stripe.com/docs/webhooks/signatures – 你需要自定义逻辑[2]来验证他们的MAC（他们错误地称之为“签名”）是否有效，并且你需要为每个端点配置不同的密钥 使用他们的官方SDK确实有帮助，但只需一行代码就可以添加签名验证。另外，我不确定你为什么想要创建很多端点来监听这些网络钩子。我只创建了一个，Stripe SDK帮助我确定事件类型、反序列化等。 > 支付流程信息是如此重要的商业问题，"我们试着联系他们，如果失败了...我们已经尝试过了"这种方式本身在原则上就是错误的 这不是我...…
完整原文在一般流程中，你不应该轮询支付提供商。你有没有意识到如果每个人这样做会带来多少请求？支付流程本质上是事件驱动的。支付提供商将状态推回到发起系统。如果失败，就由消费者来检测问题并确保系统与提供商保持同步。一些支付提供商至少会推送数据长达24小时。这是一个明显的 设计缺陷...
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。