WEBHOOK CHE ARRIVANO DAVVERO: HMAC, RETRY E IDEMPOTENZA

Le tre cose che ogni integrazione webhook pagamenti sbaglia. Ecco il contratto che Baynoy spedisce e perché.

Developers·2026-04-01·6 min di lettura
Webhook che arrivano davvero: HMAC, retry e idempotenza

Ogni webhook pagamenti ha bisogno di tre garanzie: autenticità (la richiesta è davvero da noi), consegna at-least-once (nessun evento perso silenziosamente) e idempotenza (re-delivery non raddoppia gli addebiti nel tuo DB).

Autenticità: ogni webhook Baynoy spedisce un header X-Baynoy-Signature — sha256(timestamp + '.' + body) con il secret del tuo endpoint. Rifiuta se il timestamp è più vecchio di 5 minuti (difesa replay) o la firma non corrisponde in constant-time compare. Seguiamo il formato esatto di Stripe, quindi il middleware di verifica Stripe esistente entra invariato.

At-least-once: rieseguiamo con backoff esponenziale a 1m, 5m, 30m, 2h, 12h, 24h — limitato a sei tentativi. Ogni tentativo scrive una riga in baynoy_webhook_deliveries con lo status di risposta. Il bottone replay-from-UI nella dashboard colpisce lo stesso pipeline di delivery; nessun path speciale.

Idempotenza: ogni evento porta un event.id (UUIDv7 — ordinabile, monotonicamente crescente). Persistilo al primo ricevimento e rifiuta i duplicati a livello DB con un unique constraint. Riconsegneremo. Il constraint è la tua rete di sicurezza.

Tre righe di middleware e hai un webhook handler che sopravvive a un outage di 6 ore senza perdere una sola notifica di pagamento.

Vuoi ricevere l'articolo? Iscriviti qui sotto.