IOSOR Guías
Orden de eventos frente a registro en libro mayor
Los eventos DLR y MO fuera de orden no deben romper las reglas de débito prepago; la secuencia de llegada no es la ley del dinero.
Las redes entregan devoluciones de llamada fuera de orden. Un DLR tardío, un MO temprano o un cambio de estado antes de la liquidación no deben inventar un segundo débito ni reescribir una fila liquidada. Esta página es el contrato de orden de contabilización: las reglas del libro mayor sobreviven al reordenamiento — no es una introducción al ID de correlación ni un ensayo de facturación de MO frente a MT.
El orden de llegada no es la ley del libro mayor
La llegada por HTTP es un accidente de transporte. El dinero se contabiliza bajo retención → liquidación → actualización de resultados, no bajo el último callback que aterrizó. La revisión flexible de USD 1,000/month trata el reordenamiento como un incidente financiero cuando el producto muestra éxito mientras el libro mayor se mueve dos veces. USD 20 prueba que un DLR tardío forzado nunca abre un débito paralelo.
Qué aspecto tiene el fuera de orden
| Patrón de llegada | Contabilización segura | Reacción insegura |
|---|---|---|
| DLR antes de liquidar | Pendiente; liquidar una vez bajo retención | Débito solo por DLR |
| Fallido y luego entregado | Actualizar resultado in situ | Segundo cargo por cambio |
| MO antes de correlacionar MT | Archivar en bandeja; unir al liquidar MT | Cobrar MO como saliente |
| Estado tras reembolso | Sin dinero nuevo; anotar | Reliquidar intención liberada |
| Dos terminales, una intención | Una fila de dinero | Dos filas de débito |
Reglas de contabilización que sobreviven al reordenamiento
Genere claves de retención e idempotencia antes de los efectos secundarios (Contrato de webhook antes del primer envío). Liquide una vez por cada intención facturable; los eventos posteriores solo actualizan el resultado. Nunca abra un débito paralelo por un DLR temprano o tardío ni por un MO. Rechace o estacione fuera de la ventana firmada — sin éxito inventado. Exporte uniones por intención, no por marca de tiempo de llegada.
El retraso es normal; el dinero doble no
Las redes móviles fallan. Las colas se retrasan durante las horas de silencio y se vacían de golpe. Cuando los eventos llegan con horas de retraso, el libro mayor no debe recalcular los saldos activos con datos obsoletos. Valide siempre la ventana temporal antes de tocar el saldo.
Lista de verificación del comprador para el orden de eventos
Exija que su proveedor demuestre que un DLR tardío no genera un segundo cargo. Compruebe que la conciliación agrupa por ID de intención y no por hora de llegada del servidor web. Verifique que las claves de idempotencia bloqueen los reintentos incluso cuando los estados lleguen invertidos.
Comience con IOSOR
Asiente el débito prepaid en la clave de negocio, no en el orden en que llegó el webhook. Un DLR tarde y un accepted temprano pueden aterrizar en cualquier secuencia; el registro igual escribe una fila. Una repetición dentro de la ventana de firma no debe crear un segundo débito. Fuerce un estado tarde y uno temprano en un envío pagado y pruebe un solo asiento.
Relacionados: Un webhook duplicado no debe crear un segundo débito · Puerta de firma y ventana de reintento.
Conclusión IOSOR
El orden de llegada no es ley del registro. La clave de asiento posee el dinero; el orden de cola no.
Haga: asiente una vez en la clave de idempotencia; el DLR tarde es estado, no débito nuevo.
No haga: debitar otra vez porque el DLR llegó primero, ni dejar una segunda fila por un webhook repetido.
¿Fue útil esta guía?
Guías relacionadas
- Monitoreo de métricas de salud de endpoints de Webhook
Aprenda a rastrear la latencia de respuesta del receptor y los códigos de estado en la plataforma IOSOR para gestionar proactivamente la salud de los webhooks.
- Configuración de alertas de Webhook para umbrales de saldo prepago
Aprenda a configurar webhooks de umbral de saldo automatizados en IOSOR para monitorear cuentas prepagas, evitar interrupciones y gestionar el aprovisionamiento JIT.
- Procesamiento de eventos de webhook de aprovisionamiento Just-in-Time
Domine el ciclo de vida en tiempo real de los canales entrantes usando webhooks de aprovisionamiento JIT de IOSOR. Automatice la asignación de números y actualizaciones de libro mayor para su CPaaS de marca blanca.