Zum Inhalt springen
← Alle Beiträge

14. August 2026

Dein Zahlungs-Webhook glaubt jedem

Der Testkauf läuft, Pro ist freigeschaltet. Nur: Die Adresse, die deinen Kunden freischaltet, ist öffentlich. Ein kurzer Test zeigt, ob sie jedem glaubt.

Datenstand 2025 Studien, Zahlen und Beobachtungen in diesem Beitrag stammen aus diesem Zeitraum, nicht von heutigen Agenten wie Claude Code mit Opus 5.5.

Der Testkauf ist durch. Im Dashboard steht die Zahlung, der Nutzer ist freigeschaltet, alles läuft. Für dieses Gefühl hast du zwei Tage gearbeitet.

Es funktioniert auch für alle anderen. Und zwar ohne Zahlung.

Die Adresse muss öffentlich sein

Ein Webhook ist eine Adresse in deinem System, die dein Zahlungsanbieter aufruft, wenn etwas passiert: Kauf erfolgreich, Abo verlängert, Geld erstattet. Diese Adresse muss von außen erreichbar sein, sonst kommt die Nachricht nie an. Es gibt keine Anmeldung davor, kein Passwort, keinen Nutzer.

Sie ist also nicht nur für deinen Zahlungsanbieter erreichbar, sondern für jeden, der die Adresse kennt.

Was am Ende live geht

Ein Agent wie Claude Code baut die Prüfung mit, ob die Nachricht wirklich vom Zahlungsanbieter kommt. Trotzdem kann live eine Version ohne wirksame Prüfung laufen. Heute liegt das eher an Konfiguration und Umgebung: ein fehlendes oder falsches Secret, Test-Einstellungen im Live-System, ein Deploy, den niemand geprüft hat. Dann nimmt der Code jede Nachricht an, die sich als “Kauf erfolgreich” ausgibt, und schaltet den genannten Nutzer frei.

Der Testkauf läuft damit trotzdem durch. Er fällt nicht auf, weil im Test niemand die Adresse aufruft, der es nicht darf.

Der Test dauert 30 Sekunden

Wer die Adresse kennt, kann dem System eine selbst geschriebene Nachricht schicken: “Kauf erfolgreich für diese E-Mail-Adresse”. Danach schaust du, ob der Nutzer freigeschaltet ist. Wenn ja, ist der Fall klar: kein Kauf, keine Zahlung, kein Konto, trotzdem Pro.

Den Test kann der Agent für dich schreiben und ausführen. Lass ihn das gegen die Live-Adresse tun und zeig dir die Antwort. Die richtige Antwort ist eine Ablehnung.

Das ist kein Angriff und kein Trick. Es ist genau der Aufruf, den dein Zahlungsanbieter macht, nur ohne den Teil, der beweist, dass er von ihm kommt.

Warum die Prüfung trotzdem fehlt

Die Prüfung braucht ein Geheimnis, das nur in deinem Konto beim Zahlungsanbieter steht. Das Secret holen und die Verdrahtung im Zahlungs-Dashboard einrichten musst du selbst. Der Agent schreibt den Code, anschließen musst du ihn. Wird dabei das falsche Secret eingetragen oder Test und Live verwechselt, schlägt die Prüfung fehl. In der Eile nimmt man sie dann heraus, oder man lässt sie auf “übergehen” stehen.

Danach läuft alles. “Läuft wieder” hält man für “ist richtig”.

Das ist die Sorte Lücke, die keine Fehlermeldung erzeugt. Nichts ist rot, nichts stürzt ab. Du merkst es an dem Tag, an dem dir jemand erzählt, dass er dein Produkt gratis nutzt.

Was stattdessen dahingehört

Der Zahlungsanbieter unterschreibt jede Nachricht digital. Dein System prüft diese Unterschrift, bevor es irgendetwas glaubt. Passt sie nicht, wird die Nachricht abgelehnt. Wie das technisch geht, steht in der Doku von Stripe.

Drei Stolperstellen, die dabei auftreten:

Die Prüfung schlägt fehl, obwohl alles stimmt. Meist hat das System die Nachricht vorher umgebaut, dann passt die Unterschrift nicht mehr. Es sieht aus wie ein kaputter Webhook. Die naheliegende Reaktion ist, die Prüfung auszuschalten. Damit bist du wieder am Anfang.

Test und Produktion haben verschiedene Geheimnisse. Wer eins kopiert und überall einsetzt, wundert sich später über Ausfälle im Live-Betrieb.

Dieselbe Nachricht kommt mehrfach. Zahlungsanbieter wiederholen die Zustellung, wenn deine Antwort ausbleibt. Schreibt dein System bei jeder Nachricht Guthaben gut, bekommt der Kunde es dreimal. Jede Nachricht hat eine Nummer, und eine bekannte Nummer wird ignoriert.

Die Ebene darüber

Auch mit geprüfter Unterschrift bleibt eine Frage: Wer entscheidet, dass jemand bezahlt hat? Solange das die App selbst tut, weil der Kauf-Dialog “erfolgreich” gemeldet hat, verschiebst du die Entscheidung nur. Das ist das Thema im nächsten Post: Deine App schaltet sich selbst frei.

Wo das gesammelt liegt

Unterschrift, Wiederholungen, Berechtigung vom Server: Das sind Stellen, an denen es klemmt, und keine davon meldet sich von selbst. Dazu kommt der Rest, der erst im echten Betrieb auftaucht. Warum der Testkauf grün ist und der echte rot. Was bei einer Rückerstattung passiert. Wo Testphase und Verlängerung auseinanderlaufen.

Der Payment-Guide hat genau diese Stellen.

Diese Woche reicht eine Frage an dein System: Prüft es, von wem die Zahlungsnachricht kommt?

Michael Schreier
Michael Schreier

Diplom-Informatiker · 25 Jahre Entwicklung · LinkedIn

paymentsicherheitwebhooksvibe-coding
praxis-guides
$ guide --open "Payment & Web-Checkout Best Practice"
[i] Bezahlung steht einmal richtig: Web-Checkout und In-App-Payment sauber getrennt, Store-Gebühren umgangen wo die Regeln es zulassen, keine Neuimplementierung ein Jahr später.

PDF plus Beispiele · 239 € inkl. MwSt. (200,84 € netto) · framework-unabhängig

Payment & Web-Checkout Best Practice
Michael Schreier

Fragen zum Thema?

Schreib mir — ich freue mich auf den Austausch.