¿Cómo te asegurarías de que un webhook de pagos nunca cobre ni provisione dos veces a un cliente?

Trata la entrega como al menos una vez y haz el manejador idempotente. Verifica primero la firma, luego guarda el id de evento del proveedor detrás de una restricción de unicidad y devuelve 200 de inmediato si ya lo has visto. Haz el cambio de estado y la inserción del id dentro de una misma transacción para que una caída no lo aplique a medias. Mantén el manejador rápido encolando el trabajo lento, y deja que el proveedor reintente cuando falles de verdad.

La suposición de la que parto es que el proveedor entregará el mismo evento más de una vez, fuera de orden y a veces con horas de retraso, porque las tres cosas pasan. Así que el manejador verifica primero la firma y la marca de tiempo, y luego inserta el id de evento del proveedor en una tabla processed_events con un índice único. Si esa inserción entra en conflicto, ya lo hemos gestionado, y devuelvo 200 directamente en vez de repetir el trabajo. El detalle importante es que la inserción y el efecto real, conceder la suscripción o registrar el pago, ocurren en la misma transacción, así que un proceso que muera a medias no puede dejar uno sin el otro. Todo lo lento, como enviar un correo de recibo, va a una cola con su propia clave de idempotencia. También guardo la marca de tiempo del evento e ignoro cualquier evento más antiguo que el estado que ya tengo, que es lo que te salva cuando una cancelación llega antes que la mejora que la precedía. Ante fallos devuelvo un 500 a propósito para que el proveedor reintente, y aviso si un evento acaba en la cola de mensajes muertos.