Jede Zahlung genau einmal verbucht.

Was diese Arbeitsprobe ist und was nicht

Ein lauffähiges Node.js-Projekt aus ES-Modulen (Node 22.13 oder neuer), getestet mit Node 24.15 und 22.23 unter Windows. Kein Stripe-Konto, keine echten Schlüssel, keine echte Zahlung: Alle Ereignisse sind Beispieldaten und werden mit einem zufälligen Testgeheimnis signiert. Vor einem echten Einsatz gehören die offizielle Stripe-Bibliothek, ein Endpunkt im Stripe-Dashboard und ein Gegentest mit Ereignissen aus dem Stripe-Testmodus dazu (steht im README).

Vorgaben aus der Stripe-Doku (docs.stripe.com/webhooks und /checkout/fulfillment, gelesen am 10.11.2026)

„We recommend using our official libraries to verify signatures.“

„To protect against timing attacks, use a constant-time-string comparison to compare the expected signature to each of the received signatures.“

„Our libraries have a default tolerance of 5 minutes between the timestamp and the current time.“ · „Don’t use a tolerance value of 0. Using a tolerance value of 0 disables the recency check entirely.“

„Stripe requires the raw body of the request to perform signature verification.“

„Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by logging the event IDs you’ve processed, and then not processing already-logged events.“

„Stripe doesn’t guarantee the delivery of events in the order that they’re generated.“

„Zahlungsmethoden mit Verzögerung generieren ein checkout.session.async_payment_succeeded-Ereignis, wenn die Zahlung später erfolgreich durchgeführt wird.“ (deutsche Fassung der Checkout-Doku)

Die 26 Tests (Lauf 10.11.2026, 14:13, Node 24.15 und 22.23)

• Zahlung kommt an und wird genau einmal verbucht
• Stripe stellt dasselbe Ereignis erneut zu: 200, aber keine zweite Buchung
• fünf gleichzeitige Zustellungen desselben Ereignisses ergeben eine Buchung
• zweites Ereignis-Objekt zum selben Vorgang (neue ID, gleiches Objekt und Typ) wird erkannt
• Reihenfolge vertauscht: „bezahlt“ vor „erstellt“, die Rechnung bleibt bezahlt
• gefälschte Zustellung: 400, nichts gespeichert
• abgefangene alte Zustellung (älter als 5 Minuten): 400, nichts gespeichert
• nicht abonnierter Ereignistyp: 200, festgehalten, keine Wirkung
• Schutz der Schnittstelle: GET 405, zu großer Inhalt sofort 413, unbekannter Pfad 404
• Verwaltung: ohne Passwort 401, mit Passwort 200 und die Zahlung ist zu sehen
• Migrationen: neue Datenbank auf aktuellem Stand, erneutes Öffnen ändert nichts
• Checkout ohne sofortige Zahlung: erst „ausstehend“, nach async_payment_succeeded „bezahlt“
• Checkout ohne Zahlungspflicht (z. B. 100-%-Gutschein): „ohne Zahlung“, nicht „ausstehend“
• Checkout mit Rechnung plus invoice.paid: eine Zahlung, eine Zeile
• nicht abonnierter Typ ohne Objekt-ID (z. B. balance.available): 200, kein 400
• gültige Signatur wird angenommen (Schritte 1 bis 4 der Stripe-Doku)
• Signatur stimmt mit der Node-eigenen HMAC-Berechnung überein
• falsches Geheimnis wird abgelehnt
• ein veränderter Betrag im Inhalt wird abgelehnt
• neu formatiertes JSON wird abgelehnt (darum Rohtext statt geparstem Objekt)
• Zeitstempel: 300 Sekunden alt geht, 301 nicht (Wiederholungsangriff)
• Toleranz 0 oder unendlich wird verweigert (würde die Altersprüfung abschalten)
• geprüft werden die Originalbytes, auch wenn sie kein gültiges UTF-8 sind
• fehlende oder kaputte Kopfzeile wird abgelehnt, v0 zählt nicht
• Geheimnis-Wechsel: zwei Signaturen in einer Kopfzeile, jedes der beiden Geheimnisse passt
• Speicher-Ablage und SQLite-Ablage entscheiden identisch

Probelauf als echter Server (10.11.2026, 14:14, Antworten gekürzt)

erste Zustellung: 200 {"outcome":"booked","status":"paid"}
Wiederholung durch Stripe: 200 {"outcome":"duplicate","reason":"event_id_seen"}
gefälscht: 400 {"outcome":"rejected","reason":"signature_mismatch"}
Verwaltung: 200, zeigt CHF 49.00 bezahlt

Prüfung durch einen zweiten Agenten

Ein Unter-Agent mit eigenem Prüfauftrag (Stripe-Doku, Sicherheit, README, Wartbarkeit) hat den Code von 13:31 bis 13:38 geprüft und eigene Versuche dagegen laufen lassen. Ergebnis: 1 wichtiger Befund, 5 sollten behoben werden, 9 Kleinigkeiten. Bestätigt hat er unter anderem die Signaturschritte 1 bis 4, den Vergleich in konstanter Zeit, die Toleranz, die Idempotenz in der Transaktion und die Maskierung der Verwaltung. Alle 15 Befunde sind eingearbeitet:

• Wichtig: Eine abgeschlossene Checkout-Sitzung galt immer als bezahlt, auch bei verzögerten Zahlungsarten. Jetzt wird payment_status ausgewertet, dazu async_payment_succeeded und async_payment_failed.
• Nicht abonnierte Ereignisse ohne Objekt-ID bekamen 400, Stripe hätte sie tagelang wiederholt. Jetzt 200.
• Checkout mit Rechnung plus invoice.paid ergab zwei Zeilen für eine Zahlung. Jetzt eine.
• Die Ablage der Vorführung war ungetestet. Jetzt schickt ein Vertragstest dieselben Fälle durch beide Ablagen.
• Das README nennt jetzt HTTPS und NTP als Pflicht vor dem Livegang.
• Dazu: Prüfung über die Originalbytes, sofortiges 413 bei zu großen Inhalten, Wartezeit bei gesperrter Datenbank, Toleranz „unendlich“ gesperrt, Beträge je Währung richtig formatiert, abgewiesene Zustellungen im Protokoll, geordnetes Herunterfahren, .gitignore, ES-Module und englische Bezeichner.

Danach haben zwei weitere Prüfer-Agenten Seite und Code gelesen. Daraus kamen unter anderem der Test für einen veränderten Betrag, die Regel für Sitzungen ohne Zahlungspflicht und der Hinweis auf die offizielle Stripe-Bibliothek im README.