Política de reintento DLR fallido bajo prepaid: cuándo reintentar y cuándo dejar de gastar

El ticket dice «falló» y alguien pulsa reintentar hasta vaciar la cartera prepaid. Falló no es un estado. undelivered, rejected y expired exigen actos distintos. Bajo prepaid cada reintento automático es una línea de débito, no un favor gratis. Acuerden el diccionario antes del bucle, o producto persigue conversión mientras finanzas paga el segundo y tercer intento a un número muerto.

IOSOR es prepaid white-label: el mismo vocabulario DLR en panel, webhook y exportación. Un corredor live admite reintento acotado; in setup no se abre «a la siguiente». Véase no entregado, rechazado y caducado y DLR, latencia y failover. Cerca de USD 1,000+ mensuales, los débitos de reintento por cubo de estado entran en lectura comercial más estrecha.

Diccionario de estados antes de la lógica de reintento

Antes de escribir código de reintento, impriman los estados terminales en una tabla que producto, ops y finanzas puedan señalar. Reintentar sin diccionario es un bucle que quema dinero. Para la bajada de entregabilidad, manual de baja entregabilidad SMS.

Failed frente a rejected frente a expired

Failed / undelivered significa que la plataforma entregó el trabajo y el terminal no confirmó. Si el corredor está sano, un reintento con tope puede salvar una conversión. Rejected es una negativa de red o de política: el mismo número y el mismo cuerpo casi siempre vuelven a rechazarse, y vuelven a debitarse. Expired es tiempo: TTL más corto que la latencia del corredor, o una cola antes del envío. Tratar expired como failed y martillar reintentos solo crea más filas expired. Un OTP que llega fuera de ventana ya no convierte, pero la cartera igual paga.

Topes de reintento e impacto en la cartera

Pongan un tope de intentos automáticos por mensaje y separen el resend del usuario del failover del sistema. Cada intento debe cuadrar con un correlation ID en el ledger. «Hasta que entregue» sin tope vacía prepaid en un corredor muerto. Finanzas debe exportar destino, estado, número de intento y débito. Cerca de USD 1,000+, un bucle sin dueño deja de ser un ticket y se vuelve tema comercial. Cuando la política dice parar, la cartera para aunque producto quiera otra vez.

Dueño de producto frente a finanzas

Producto posee la política: qué estados permiten reintento, TTL, cooldown de resend. Finanzas posee la visibilidad: si cada intento debita y si la exportación cuadra con el webhook. Ops posee el corte por corredor para que un promedio mundial no esconda una ruta rota. Sin la misma tabla, prepaid no puede decidir «reintentar» frente a «dejar de gastar». No dejen que soporte prometa reembolsos de palabra mientras el ledger cobra cada intento.

Señales de alarma

• Solo existen sent y failed, pero hay reintento automático
• Tres golpes idénticos a un payload rejected
• Expired tratado como avería de red
• Failover de sistema y resend de usuario en la misma línea de débito
• «Hasta entregar» sin tope de intentos
• Reintento prometido con el catálogo in setup
• Exportación de finanzas sin número de intento

Empezar con IOSOR

Llenen el diccionario: failed frente a rejected frente a expired. Pongan techo al reintento automático para que cada DLR fallido no abra un débito prepaid nuevo. El botón de reenvío del usuario es distinto del intento del sistema. Prueben el techo en dos corredores live a bajo volumen.

Conclusión IOSOR

El reintento de DLR fallido es un techo de gasto, no un bucle infinito.