Undelivered vs rejected vs expired: diccionario de estados para producto y billing

Cuando cae la entregabilidad, producto culpa al pipe, soporte pega capturas y finanzas pregunta por qué se movió el monedero prepago. Gran parte del calor es un fallo de vocabulario. Undelivered, rejected y expired no son sinónimos — tratarlos como un solo cubo “failed” inventa reintentos erróneos, reembolsos erróneos y severidad de incidente errónea.

IOSOR quiere que los equipos B2B operen messaging como white-label prepago: fondear una vez, leer eventos de estado duraderos y mantener lenguaje de error seguro para la marca. Este diccionario es el contrato operativo entre UX de producto, ops y el ledger.

Por qué las palabras de estado causan más incidentes que los outages

El diccionario de estados: definiciones que producto y billing pueden acordar

Undelivered suele significar que el job entró en el path live de messaging pero una señal downstream dice que el handset no obtuvo éxito. Drivers típicos: handset apagado, bandeja llena, congestión temporal del corredor, suscriptor inalcanzable.

Acciones licenciadas:

Undelivered vs rejected: clases de fallo distintas, fixes distintos

Rejected es un fallo de política o admisión: filtro de contenido, identidad del remitente, puerta de cumplimiento, destino malformado, fondos insuficientes, o catálogo-not-live para esa capacidad. El job nunca ganó una oportunidad justa de entrega al handset.

Acciones licenciadas:

Expired: TTL, colas y ventanas de timing OTP

Expired significa que la ventana de validez se cerró antes de un éxito terminal. Común en OTP (TTL), jobs encola past SLA, o ventanas de validez de red. El producto debe separar user expired (usuario estancado) de network expired (el pipe no entregó a tiempo).

Acciones licenciadas:

Implicaciones de billing: qué se cobra, acredita o disputa

Comience con IOSOR

Mapea tus retornos de estado en la consola IOSOR para que tu integración de facturación separe con precisión los rechazos tempranos de los eventos no entregados en destino y las caducidades de cola. Audita tus webhooks activos para garantizar que los códigos de entrega terminal transmitan clases de error explícitas a tu libro contable en lugar de un estado genérico de fallo.

• Detección de degradación en la entrega de OTP antes de que caigan las convers…
• causa raíz de la latencia SMS
• Cuando el terminal fuerza UCS-2, la factura debe reflejar la verdad

Conclusión IOSOR

Esta guía demostró que la ambigüedad en los estados constituye un problema de diseño de producto y contabilidad más que un simple fallo de red. Distinguir entre rechazos del operador, estados de no entrega en destino y caducidades de tiempo de vida aclara la responsabilidad financiera y evita que los equipos de soporte busquen errores fantasmales en el código de la aplicación.