WEBHOOKS, DIE WIRKLICH ANKOMMEN: HMAC, RETRIES UND IDEMPOTENZ

Die drei Dinge, die jede Zahlungs-Webhook-Integration falsch macht. Hier ist der Vertrag, den Baynoy ausliefert.

Developers·2026-04-01·6 Min. Lesezeit
Webhooks, die wirklich ankommen: HMAC, Retries und Idempotenz

Jeder Zahlungs-Webhook braucht drei Garantien: Authentizität (die Anfrage kam wirklich von uns), at-least-once Zustellung (keine Events leise verloren), und Idempotenz (Re-Deliveries führen nicht zu doppelten DB-Einträgen).

Authentizität: jeder Baynoy-Webhook liefert einen X-Baynoy-Signature-Header — sha256(timestamp + '.' + body) mit dem Secret Ihres Endpoints. Ablehnen wenn der Timestamp älter als 5 Minuten ist (Replay-Schutz) oder die Signatur nicht constant-time vergleicht. Wir folgen dem genauen Format von Stripe, sodass bestehende Stripe-Verifizierungs-Middleware unverändert reinpasst.

At-least-once: wir retry mit exponentiellem Backoff bei 1m, 5m, 30m, 2h, 12h, 24h — gedeckelt bei sechs Versuchen. Jeder Versuch schreibt eine Zeile in baynoy_webhook_deliveries mit dem Response-Status. Der Replay-from-UI-Button im Dashboard trifft dieselbe Delivery-Pipeline; kein Sonderpfad.

Idempotenz: jedes Event trägt eine event.id (UUIDv7 — sortierbar, monoton steigend). Beim ersten Empfang persistieren und Duplikate auf DB-Ebene mit Unique-Constraint ablehnen. Wir liefern erneut aus. Das Constraint ist Ihr Sicherheitsnetz.

Drei Zeilen Middleware und Sie haben einen Webhook-Handler, der einen 6-Stunden-Ausfall ohne eine einzige verlorene Zahlungsbenachrichtigung übersteht.

Möchten Sie informiert werden, sobald der Artikel erscheint? Melden Sie sich unten an.