IOSOR

IOSOR Guías

Un webhook duplicado no debe crear un segundo débito

Ruta de fallo: los reintentos y repeticiones se mantienen idempotentes en el dinero prepago y la bandeja de entrada: un ID de evento, una fila de débito, una línea de bandeja.

La entrega de al menos una vez volverá a intentarlo. Un webhook duplicado que publica un segundo débito o una segunda línea en la bandeja es un incidente de dinero y operaciones, no un acuse inofensivo. Esta página es la ruta de fallo: los reintentos y repeticiones se mantienen idempotentes en el dinero prepago y en la bandeja, sin ser el ensayo de idempotencia de envío de la API ni el manual de reintento de SMS entrantes.

Relacionado: Puerta de firma y ventana de reintento, Contrato de webhook antes del primer envío, filas de débito y estado de entrega en el mismo libro.

IOSOR es prepago de marca blanca.

La idempotencia es una ruta de fallo, no un eslogan

Camino feliz: un evento firmado, una aceptación, un débito. La ruta de fallo erosiona la confianza: tiempo de espera, 5xx, repetición del proveedor, reenvío del operador. Almacene la clave de idempotencia del Contrato de webhook antes del primer envío antes de los efectos secundarios: libro mayor, bandeja de entrada, CRM.

Qué cuenta como duplicado

Señal Tratar como duplicado cuando Resultado seguro
ID de evento El mismo ID ya aceptado en la ventana Acuse; sin segundo débito
ID de mensaje El mismo mensaje ya vinculado al libro Reutilizar fila; sin cargo nuevo
Clave de bandeja El mismo MO/MT ya archivado Sin segunda línea en la bandeja
Fuera de ventana Reintento obsoleto tras rechazo de puerta Rechazo; sin escritura de dinero o estado
Tipo desconocido Fuera de la

El dinero no debe moverse dos veces

Un segundo débito para el mismo ID de evento es un error, incluso si el producto «sigue mostrando entregado». Finanzas filtra por ID de evento o de mensaje y ve una fila prepaga para esa ventana UTC. Los efectos secundarios parciales tras el acuse —el CRM primero, el libro mayor después— fabrican una doble verdad. Si el procesamiento falla tras la persistencia, reintente el proceso con la misma clave; no vuelva a aceptar el cuerpo HTTP como un nuevo cargo.

La bandeja tampoco debe duplicarse

La idempotencia no concierne únicamente al dinero. Un evento de entrega o entrada repetido que abre un segundo hilo en la bandeja entrena al soporte a perseguir fantasmas y puede desencadenar bucles de respuesta automática. Almacene la clave de bandeja con el mismo ID de evento utilizado para el débito. El producto y finanzas comparten el rechazo y la duplicación.

Lista de verificación del comprador para webhooks seguros contra duplicados

Exija que su proveedor confirme el almacenamiento de la clave de idempotencia previa al efecto secundario. Verifique que las fallas de red no generen un segundo débito en la misma ventana UTC. Exija que los reintentos devuelvan el mismo acuse almacenado sin tocar el saldo. Pruebe con USD 20 antes de escalar a volúmenes mayores.

Comience con IOSOR

Fuerce una reinyección firmada dentro de la ventana en un corredor que ya facturó. Exporte el event id junto al id del ledger y pruebe una sola fila de débito y una sola fila de bandeja. Si aparece un segundo débito, pare ese consumidor y reembolse la fila extra: no la netee contra tráfico posterior. Esta puerta es dinero de replay, no una comprobación E.164 ni un trabajo de copy de envío.

Conclusión IOSOR

Un replay no es un envío nuevo. Un event id escribe un débito.

Haga: deje firma y ventana de replay encendidas y pruebe un débito tras un POST dentro de la ventana. No haga: debitar cada POST, ni tratar un reintento de red como segunda factura.

¿Fue útil esta guía?

Guías relacionadas