Stripe-Zahlung erfolgreich, Bestellung bleibt offen: der Webhook, den niemand eingerichtet hat

Stripe-Zahlung erfolgreich, aber die Bestellung kam nie an

Dieser Kunde hat bezahlt, aber der Shop hat es nie erfahren.

Das Geld ist angekommen, die Bestellung ist immer noch offen, und niemand hat eine Fehlermeldung oder irgendetwas auch nur entfernt Ähnliches bekommen. Also weiß eigentlich niemand, dass etwas nicht stimmt.

Hi, ich bin Kevin, ich leite Wavect, und wir haben allein dieses Jahr über 50 vibe-codierte Produkte geprüft.

Und die Bugs, die wirklich am meisten wehgetan haben, waren die, bei denen es nicht um den Code selbst ging, sondern um die Ränder, wo Dein Code mit dem Code von jemand anderem zusammenspielt.

Warum kommt mein Stripe-Webhook nicht an? Er wurde nie registriert

In vielen Fällen war zum Beispiel einfach ein Webhook nicht richtig konfiguriert, wenn Du zum Beispiel irgendeinen Zahlungsablauf oder so etwas hast, und das Zahlungsevent kommt einfach nicht an oder ist nicht angekommen.

Und bei vielen dieser Anwendungen, die wir geprüft haben, besonders bei den Fintech-Apps, gab es Webhooks: Du bezahlst zum Beispiel für ein Produkt oder eine Dienstleistung, und Deine Anwendung leitet Dich dann normalerweise zu einem externen Zahlungsanbieter weiter. Und sobald die Zahlung abgeschlossen ist, schickt dieser Zahlungsanbieter einen Webhook, also im Grunde die Benachrichtigung an Dein eigenes Backend, an Deinen eigenen Server, dass die Zahlung abgeschlossen ist oder nicht abgeschlossen wurde oder irgendein Zustand dazwischen. Und Deine Anwendung reagiert dann normalerweise darauf.

Aber oft vergessen diese Vibe-Coder einfach, dass sie auch außerhalb ihrer eigenen Anwendung, ihrer eigenen Infrastruktur etwas konfigurieren müssen, zum Beispiel im Dashboard von Stripe oder PayPal oder wem auch immer, damit die Dir diese Benachrichtigung auch wirklich an Deine eigene Webanwendung schicken.

Auch wenn also lokal alles zu funktionieren scheint, Du hast Deine Tests, vielleicht sogar End-to-End-Tests und das ganze Zeug, kann es in Produktion, wenn Du echte Nutzer hast, trotzdem passieren, dass sie nicht ankommt.

Und dann hast Du im Grunde einen ernsthaften Bug, denn es gibt keine schlimmere Erfahrung auf der Welt, als wenn Du etwas kaufst und glaubst, Du bekommst es nicht. Das ist echt scheiße, weißt Du.

Und was man auch nicht vergessen darf: Wenn Du testest, testest Du normalerweise den Happy Path, oder da liegt im Grunde Deine Hauptaufmerksamkeit.

Was passiert, wenn Stripe denselben Webhook zweimal schickt?

Und der nächste Punkt ist: Wenn eine dieser Zahlungen, zum Beispiel, oder diese Benachrichtigungen nicht erfolgreich zugestellt werden, zum Beispiel von Stripe oder einem anderen Zahlungsanbieter, dann versuchen die es normalerweise immer wieder. Du hast also vielleicht alles richtig konfiguriert, aber dann bekommst Du eine Benachrichtigung, und aus irgendeinem Grund gibt Dein Server einen Fehlercode zurück oder etwas hat nicht so funktioniert, wie es sollte, und Stripe schickt noch eine Benachrichtigung, und noch eine, und noch eine.

Und wenn Dein Backend oder Dein Algorithmus nicht idempotent ist, dann verbuchst Du das im Grunde als mehrere Zahlungen, obwohl es eigentlich nur eine Zahlung ist. Und das ist, aus offensichtlichen Gründen, ein Problem.

Und es wird sogar noch schlimmer: Diese Benachrichtigungen kommen vielleicht nicht in der richtigen Reihenfolge oder in der Reihenfolge, die Du angenommen hast, sie kommen vielleicht zu spät, sie kommen vielleicht, wie gesagt, mehrfach.

Wie verhindere ich gefälschte Webhooks? Signatur prüfen

Und um kurz bei diesem Beispiel zu bleiben: Stripe schickt diese Benachrichtigung an Dein Backend. Wenn man darüber nachdenkt, heißt das, dass der Endpunkt, an den Stripe diese Benachrichtigung schickt, zumindest irgendwie öffentlich sein muss, denn wie sonst könnte ein externer Dienst im Internet Deine Anwendung aufrufen und Dir diese Benachrichtigung schicken?

Damit keine unbefugten oder gefälschten Zahlungsanbieter oder ein böswilliger Nutzer Dir solche gefälschten Benachrichtigungen schicken können, um so zu tun, als hätten sie bezahlt, was genauso schlimm ist, nur andersherum. Und dafür gibt es verschiedene Mechanismen, um das zu verhindern, von IP-Whitelisting bis zu Webhook-Signaturen und so weiter.

Aber das sind Dinge, die die KI manchmal macht, weil KI sehr gut darin ist, Best Practices anzuwenden. Aber oft musst Du diese Dinge auch ausdrücklich ansprechen, weil Dir Dein Urteilsvermögen sagt: Hey, das muss ich machen, sonst bin ich am Arsch oder komplett erledigt.

Anfrage mit Timeout: Ist die Zahlung durchgegangen?

Und es gibt auch oft, sagen wir, mehrdeutige oder verwirrende Fehler, die Du in Deiner Anwendung bekommst. Zum Beispiel ein Timeout, ein großartiges Beispiel. Wenn Du etwa eine Anfrage an einen externen Dienst oder ein externes Backend schickst, das kann alles Mögliche sein, und Du bekommst einen Timeout, dann hast Du nur die Information: Okay, die Anfrage ist in einen Timeout gelaufen, ich habe keine Antwort bekommen, zumindest nicht rechtzeitig.

Das heißt, theoretisch wurde Deine Aktion, also das, was Du eigentlich machen wolltest, vielleicht erfolgreich ausgeführt, vielleicht ist sie fehlgeschlagen, oder sie wird irgendwann später ausgeführt, wie auch immer. Und das sind Dinge, bestimmte Randfälle, mit denen Du umgehen musst, und es gibt viel mehr davon, als man sich normalerweise vorstellt.

Stille Fehler und abgelaufene API-Schlüssel: So bemerkst Du sie

Und das Schlimmste überhaupt, wenn Du Anwendungen baust, sind stille Fehler. Dinge, die Dich nicht anschreien. Denn wenn Dein Server abstürzt, merkst Du das, zumindest wenn Du Nutzer hast oder Deine Anwendung selbst nutzt. Aber wenn etwas einfach still fehlschlägt, merkst Du es vielleicht überhaupt nicht.

Aber oft zeigt es sich auf eine andere Weise, zum Beispiel darin, dass Nutzer Deinen Dienst einfach nicht mehr verwenden. Sie registrieren sich nicht. Sie kommen nicht zurück. Sie kaufen nicht mehr in Deinem Onlineshop, weil vielleicht die Zahlung fehlschlägt und sie einfach aufgeben, wie auch immer.

Und das sind stille Fehler, die Unternehmen ruinieren können, die riesige Auswirkungen haben können, je nachdem, in welchem Zusammenhang der Bug steht.

Wenn Du also mit Secrets arbeitest, willst Du natürlich, dass diese Passwörter, API-Schlüssel, was auch immer, besonders als Vibe-Coder, oder ganz allgemein ist es einfach Best Practice, irgendwann ablaufen, oft oder meistens. Denn wenn sie geleakt werden, wenn sie in die falschen Hände geraten, wenn sie irgendwie ins Internet gelangen, können sie natürlich benutzt werden, und das ist ein Problem. Wenn sie aber ablaufen, funktioniert auch Deine Anwendung nicht mehr, also musst Du auch das warten. Das sind also auch mögliche kryptische Fehler, die Du bekommst, so nach dem Motto: Warum funktioniert etwas nicht mehr? Es hat wochen-, monate-, jahrelang funktioniert. Das ist Wartung.

5 Fragen, bevor Du eine Integration als fertig bezeichnest

Ich denke da gern an, sagen wir, vier oder fünf zentrale Dinge, an die Du immer denken solltest, wenn Du ein Feature oder Produkt als fertig bezeichnest. Das erste wäre: Was könnte hier eigentlich schiefgehen? Wenn ich für etwas bezahle, was könnte schiefgehen? Nun, es könnte sein, dass die Zahlung nicht durchgeht oder dass sie zweimal durchgeht.

Und das nächste ist: Wenn eine dieser schlechten Situationen tatsächlich eintritt, wie bemerken wir das? Haben wir irgendein Monitoring? Bekommen wir eine Benachrichtigung? Bekommen wir auf irgendeine Weise Feedback von Nutzern, was übrigens generell immer eine gute Sache ist?

Und das nächste ist: Wie stellen wir den Zustand wieder her, wenn tatsächlich etwas schiefgeht? Wenn Daten beschädigt sind, wenn wir Daten verloren haben oder wenn wir einfach nicht sicher sind, was der wahre Zustand der Anwendung ist. Hat die Person bezahlt?

Was stimmt? Und das sind alles Dinge, die in der echten Welt echte Probleme sind.

Das Nächste ist: Vielleicht hast Du all diese Dinge, aber wer wird alarmiert? Wer ist dafür verantwortlich? Wer reagiert rechtzeitig, behebt es, kümmert sich darum und macht was?

Und das Letzte ist: Wie testen wir das alles eigentlich?

Und das ist auch etwas, das Vibe-Coder oft falsch machen, besonders die, die zu uns gekommen sind. Oft wussten wir gar nicht, dass sie das Ding schon mit dem Kunden gelauncht hatten. Und wenn sie etwas gefixt haben, haben sie es sofort in Produktion gepusht und nicht einmal getestet. Und dann war einfach alles kaputt.

Also zusammengefasst: Eine API anzubinden ist nur der erste Schritt, die echte Arbeit steckt oft im langweiligen Teil, also in allem, was danach kommt, in der Wartung, im Testen, im Monitoring, in allem, was sicherstellt, dass das Ding unter echtem Druck wirklich funktioniert.