WEBHOOKS QUI ARRIVENT VRAIMENT : HMAC, RETRIES ET IDEMPOTENCE

Les trois choses que toute intégration webhook de paiement rate. Voici le contrat que Baynoy livre et pourquoi.

Developers·2026-04-01·6 min de lecture
Webhooks qui arrivent vraiment : HMAC, retries et idempotence

Chaque webhook de paiement a besoin de trois garanties : authenticité (la requête vient vraiment de nous), livraison at-least-once (pas d'événements perdus silencieusement), et idempotence (les redéliveries ne double-écrivent pas en DB).

Authenticité : chaque webhook Baynoy livre un header X-Baynoy-Signature — sha256(timestamp + '.' + body) avec le secret de votre endpoint. Rejeter si le timestamp est plus vieux que 5 minutes (défense replay) ou si la signature ne matche pas en comparaison constant-time. Nous suivons le format exact de Stripe, donc le middleware de vérification Stripe existant tient tel quel.

At-least-once : nous réessayons avec backoff exponentiel à 1m, 5m, 30m, 2h, 12h, 24h — plafonné à six tentatives. Chaque tentative écrit une ligne dans baynoy_webhook_deliveries avec le statut de réponse. Le bouton replay-from-UI dans le dashboard frappe le même pipeline de delivery ; pas de chemin spécial.

Idempotence : chaque événement porte un event.id (UUIDv7 — triable, monotone croissant). Persistez-le à la première réception et rejetez les doublons au niveau DB avec un unique constraint. Nous redélivrerons. Le constraint est votre filet de sécurité.

Trois lignes de middleware et vous avez un handler webhook qui survit à une panne de 6 heures sans perdre une seule notification de paiement.

Soyez prévenu à la sortie — inscrivez-vous ci-dessous.