Playbook3 Abschnitte · 2 Min. LesezeitVon Dezső Mező · Veröffentlicht 3. Oktober 2026.mdStripeWebhooksPaymentsIdempotency
Zahlungs-Webhooks sind der eine Ort, wo 'im Test hat es funktioniert' aktiv irreführt: Test-Events kommen einmal und geordnet, Produktion liefert regelmäßig Duplikate, Umstellungen und Verzögerungen. Die folgenden Muster sind der Unterschied zwischen einem Checkout, der gelegentlich doppelt liefert, und einem, bei dem 'dasselbe Event zweimal' ein Nicht-Ereignis ist.
01Die Signatur vor allem anderen verifizieren
Stripe signiert jede Zustellung; gegen das Endpoint-Secret prüfen, bevor man sie als vertrauenswürdig parst oder protokolliert. Ein unverifizierter Webhook ist ein öffentlicher POST-Endpunkt, der behauptet, Geld sei geflossen — genau das ist er ohne den Check.
02Event-ID speichern, einmal verarbeiten
Die Event-ID ist dein Idempotency-Key: vor der Verarbeitung einfügen und den Unique-Constraint die zweite Zustellung zum No-Op machen lassen. Gleiches gilt für die ausgelöste Erfüllung — erstellte Bestellung, eingereihte Mail, gewährte Berechtigung brauchen jeweils einen eigenen 'schon erledigt'-Eintrag.
03Zustand lesen, nicht den Event-Payload
Das Event sagt, etwas hat sich geändert; der Objekt-Fetch sagt, was jetzt ist. 'checkout.session.completed' über das Lesen der aktuellen Session zu behandeln — statt dem Payload zu trauen — ist immun gegen Umordnung, weil späte Events immer noch die neueste Wahrheit holen.
Was bleibt
- Signatur verifizieren — der Webhook ist ein öffentlicher Endpunkt.
- Event-ID ist der Idempotency-Key; dedupliziere, bevor du handelst.
- Aktuellen Zustand holen; der Payload ist bei Ankunft alt.
- Duplikate und Umordnung sind normal, keine Edge Cases.
Mehr aus dem Lab
Alle Beiträge ansehen
Was Custom Software wirklich kostet
Custom oder von der Stange — der ehrliche Test
Die ersten neunzig Tage eines Retainers, wie er wirklich läuft
Warum Kunden eine Fortschrittsseite statt Status-Mails bekommen
Sollen wir das an Ihrem System ansehen?Gespräch beginnen
