Como você garantiria que um webhook de pagamento nunca cobre nem provisione um cliente duas vezes?

Trate a entrega como pelo menos uma vez e torne o handler idempotente. Verifique a assinatura primeiro, depois guarde o id do evento do provedor atrás de uma restrição de unicidade e retorne 200 na hora se você já viu aquilo. Faça a mudança de estado e a inserção do id dentro de uma transação só, para uma queda não aplicar aquilo pela metade. Mantenha o handler rápido enfileirando o trabalho lento, e deixe o provedor tentar de novo quando você genuinamente falhar.

A premissa de onde eu parto é que o provedor vai entregar o mesmo evento mais de uma vez, fora de ordem, e às vezes horas depois, porque as três coisas acontecem. Então o handler verifica a assinatura e o timestamp primeiro, depois insere o id do evento do provedor em uma tabela processed_events com um índice único. Se aquela inserção conflita, a gente já tratou, e eu retorno 200 direto em vez de fazer o trabalho de novo. O detalhe importante é que a inserção e o efeito de verdade, conceder a assinatura ou registrar o pagamento, acontecem na mesma transação, para um processo morrendo no meio não deixar um sem o outro. Qualquer coisa lenta, como mandar um e-mail de recibo, vai para uma fila com a própria chave de idempotência. Eu também guardo o timestamp do evento e ignoro um evento mais antigo que o estado que eu já tenho, que é o que te salva quando um cancelamento chega antes do upgrade que o precedeu. Em falhas eu retorno um 500 de propósito para o provedor tentar de novo, e eu alerto se um evento cair na fila de mensagens mortas.