qué hacer si el webhook envía charge.refunded antes que charge.succeeded?

[Charles_G]

Estaba revisando el webhook de nuestro sistema de pagos y me topé con que a veces el evento de "charge.refunded" llega antes que el de "charge.succeeded", lo que me ha causado inconsistencias en nuestra base de datos. No sé si esto es un problema de idempotencia en su API o si simplemente estoy manejando mal el orden de los eventos. ¿Alguien más ha tenido una experiencia similar con esta plataforma?

[Timothy79]

Lo que describes parece un problema de asincronía más que de una falla de idempotencia aislada. En muchas plataformas de pagos, los webhooks no garantizan un orden estricto: refund puede llegar antes que el éxito simplemente por la cola de eventos. La solución típica es aplicar idempotencia en el procesador de mensajes y, antes de actualizar el estado, consultar el estado real del cargo desde la API o la base de datos. Así evitas reflejar un estado intermedio por un evento prematuro.

[ThomasG]

Es frustrante ver que el webhook de refund llega primero y te desalineas con la base de datos. La palabra clave idempotencia se vuelve casi un salvavidas, porque te permite volver a procesar sin duplicar cargos. Pero sí, habría que diseñar el flujo para reconciliar estados y no confiar en el orden de llegada.

[RyanMW]

Esto suena a que esperan que todo llegue en una secuencia perfecta, lo cual no es realista. La idempotencia debe estar en el centro, pero si el emisor no garantiza al menos una entrega, te encuentras con escenarios raros. ¿No sería mejor escuchar a la plataforma y normalizar el estado siempre consultando el cargo?

[PaulM]

Tal vez conviene replantearlo como: tomar charge.succeeded como estado definitivo y tratar charge.refunded como un evento que podría ajustar ese estado pero no decidirlo. Eso empuja a robustecer la lógica de reconciliación y evitar actualizaciones paralelas que dejen la DB a medias. También abre la puerta a conceptos como estado eventual sin explicarlo todo.

[Tyler_T]

En mi experiencia, no es solo la API sino también la carga de lectura; si el webhook llega fuera de orden, conviene un bus de mensajes con idempotentes. La idea de idempotencia aparece, pero hay que documentar el contrato de eventos para evitar sorpresas.

[OliviaT]

Yo escribiría un pequeño sistema de logs que guarde cada intento con un id único y un timestamp, y luego un worker que reintente con backoff. Si ves patrones de refund-before-succeeded, ajustas la reconciliación. No esperes que el mundo coopere perfecto.