Stripe 付款成功，订单却仍是待处理：没人配置的那个 webhook

Stripe 付款成功，订单却始终没到

这位顾客付了钱，但商店从来不知道。

钱到账了，订单还是待处理，也没有任何人收到报错，或者哪怕一点类似的提示。所以其实没有人知道出了问题。

大家好，我是 Kevin，我负责 Wavect。光是今年，我们就审查了 50 多个 vibe coding 做出来的产品。

真正最伤的那些 bug，问题并不在代码本身，而在边缘地带，也就是你的代码和别人的代码交互的地方。

为什么我的 Stripe webhook 收不到？它从来没被注册过

很多情况下，比如说，就是一个 webhook 没有配置好。比如你有某种支付流程之类的东西，而支付事件就是不来，或者没有到达。

我们审查过的很多应用，尤其是金融科技类的，比如说都有 webhook：你为某个产品或服务付款，你的应用通常会把你跳转到一个外部支付服务商。付款完成后，这个支付服务商会发送一个 webhook，基本上就是发给你自己的后端、你自己服务器的通知，告诉它付款已完成、没有完成，或者介于两者之间的任何状态。然后你的应用通常会据此做出反应。

但很多时候，这些 vibe coder 就是忘了，他们还得在自己的应用、自己的基础设施之外配置东西，比如在 Stripe 或 PayPal 之类的控制台上，确保对方真的会把通知发到你自己的 Web 应用。

所以，即使本地一切看起来都正常，你有测试，甚至可能有端到端测试之类的，但到了生产环境，真的有真实用户的时候，通知还是可能收不到。

这样你基本上就有了一个严重的 bug，因为世界上没有比买了东西却以为自己拿不到更糟的体验了。那真的挺操蛋的，你懂的。

还有一点别忘了：你测试的时候，通常测的是正常流程，或者说你的主要注意力基本都在那上面。

Stripe 把同一个 webhook 发了两次会怎样？

接下来的问题是，如果这些付款，或者说这些通知，比如 Stripe 或其他支付服务商的通知，没能成功送达，它们通常会不断重试。所以也许你一切都配置对了，但你收到一条通知，不管出于什么原因，你的服务器返回了错误码，或者某些东西没按预期工作，于是 Stripe 再发一条通知，再一条，再一条。

如果你的后端或者你的算法不是幂等的，那你基本上就会把它记成多笔付款，尽管实际上只有一笔。原因很明显，这是个问题。

更糟的是，这些通知可能不是按正确的顺序到达，或者不是按你假设的顺序，它们可能迟到，也可能像刚才说的那样到达好几次。

怎么防止伪造的 webhook？验证签名

再沿着这个例子说一下：Stripe 把通知发到你的后端。仔细想想，这意味着 Stripe 发送通知的那个端点至少在某种程度上必须是公开的，否则互联网上的外部服务怎么能调用你的应用、把通知发给你呢？

要确保未经授权的或伪造的支付服务商，或者恶意用户，不能给你发这些假通知，假装他们已经付过款，这同样糟糕，只是方向反过来。为此你有不同的机制来防范，从 IP 白名单到 webhook 签名等等。

这些事情 AI 有时会做，因为 AI 很擅长应用最佳实践。但很多时候你也得明确指出来，因为你的判断告诉你：嘿，我必须这么做，不然我就他妈完蛋了，或者彻底玩完了。

请求超时：付款到底成功了没有？

另外，你的应用里也经常会出现，怎么说呢，含糊或令人困惑的错误。比如超时，这是个很好的例子。比如你向某个外部服务或外部后端发送请求，它可以是任何东西，然后你遇到超时，你只知道：好吧，请求超时了，我没收到响应，至少没有及时收到。

这意味着，理论上你的操作，也就是你真正想做的事，可能已经成功执行了，可能失败了，也可能会在之后某个时间点执行，随便哪种。这些就是你必须处理的边缘情况，而且比你通常想象的要多得多。

静默错误和过期的 API 密钥：如何发现它们

而在构建应用时，最糟糕的就是静默错误。那些不会冲你大喊的东西。因为服务器崩溃时你会注意到，至少在你有用户或者自己也在用这个应用的时候。但如果某个东西只是悄无声息地失败，你可能根本不会注意到。

不过它往往会以另一种方式表现出来，比如用户就是不再使用你的服务了。他们不注册。他们不回来。他们不在你的电商店铺买东西，因为也许付款失败了，他们干脆放弃了，诸如此类。

这些静默错误可能会毁掉一家企业，根据 bug 所处的场景，可能产生巨大的影响。

所以，当你处理密钥这类机密时，你显然希望这些密码、API 密钥之类的东西，尤其是作为 vibe coder，或者一般来说这本来就是最佳实践，在某个时候过期，经常或者大多数时候都是这样。因为一旦它们泄露，落到坏人手里，以某种方式泄露到互联网上，它们显然就能被利用，这是个问题。可它们一过期，你的应用也会停止工作，所以这一点你也得维护。这些也可能是你会遇到的晦涩错误，比如：为什么某个东西突然不能用了？它已经正常运行了好几周、好几个月、好几年。这就是维护。

宣布集成完成之前要问的 5 个问题

所以我喜欢这样想，比如说，当你宣布一个功能或产品完成时，有四五件关键的事情你应该始终考虑。第一件是：这里到底可能出什么问题？我付款的时候，可能出什么问题？嗯，可能付款没成功，也可能扣了两次。

下一件是：当这些糟糕的情况真的发生时，我们怎么发现？我们有没有某种监控？我们会收到通知吗？我们能以某种方式得到用户反馈吗？这一般来说也总是一件很好的事。

再下一件是：当真的出了问题，我们怎么恢复？当数据损坏了，当我们丢了数据，或者当我们根本不确定应用的真实状态是什么。这个人到底付款了吗？

什么才是对的？这些都是现实世界中真实存在的问题。

接下来是：也许这些你都有了，但谁会收到告警？谁对此负责？谁会及时响应、修复、处理，具体做什么？

最后一件是：我们到底怎么测试这一切？

这也是 vibe coder 经常做错的地方，尤其是来找我们的那些人。我们经常都不知道，他们已经和客户一起把这东西上线了。而他们修了什么东西之后，会立刻推到生产环境，连测试都不测。然后东西就直接坏了。

总结一下，接入一个 API 只是第一步，真正的工作往往在那些枯燥的部分，也就是之后的一切：维护、测试、监控，所有确保这个东西在真实压力下真正能用的工作。