Validez de mensajes SMS A2P: cómo definir expiración, reintentos y estados finales sin perjudicar al usuario

La validez de un SMS no es la caducidad de su contenido

En SMS, el periodo de validez describe cuánto tiempo debe conservarse un mensaje para intentar su entrega antes de que expire. Es un atributo de transporte y retención en la red; no determina por sí mismo si el contenido sigue siendo apropiado para el destinatario.

Esta distinción es esencial en tráfico A2P. Un SMS puede continuar siendo técnicamente entregable aunque el código OTP ya no sea aceptable, la alerta ya haya sido resuelta o una promoción haya perdido su oportunidad. Mantener el mensaje en cola en esos casos puede generar confusión, solicitudes de soporte y decisiones de seguridad equivocadas.

La política operativa no debe limitarse a preguntar si el proveedor o la red todavía puede entregar el SMS. Debe responder una pregunta anterior: “¿La acción solicitada sigue siendo correcta, segura y útil si el destinatario recibe este mensaje ahora?”.

• Validez técnica: tiempo máximo de conservación e intentos de entrega en la plataforma, proveedor o red.
• Expiración del contenido: momento a partir del cual un código, enlace o dato incluido deja de ser válido.
• Ventana de utilidad: plazo durante el cual recibir la comunicación todavía permite una acción pertinente para el destinatario.

Use un límite absoluto de utilidad como decisión de control

La plataforma emisora debe calcular un vencimiento absoluto de utilidad al crear la operación. Ese instante debe acompañar al mensaje durante el encolado, la regulación por TPS, la selección de conectividad, el envío y los reintentos.

Antes de cada transición relevante, compruebe si queda tiempo suficiente para que el mensaje conserve sentido. Si la espera interna, el límite de emisión o un nuevo intento ya han consumido esa ventana, la decisión correcta suele ser no enviar. No conviene delegar esta decisión únicamente en el periodo de validez configurable de un tercero, porque ese valor puede aplicarse solo al tiempo de permanencia dentro de su propia plataforma.

El control debe ejecutarse antes de admitir el trabajo en una cola de salida, antes de emitirlo a un proveedor y antes de programar cada reintento. Así se evita que un mensaje obsoleto salga simplemente porque aún quedaba capacidad técnica para transportarlo.

• Defina una hora de vencimiento de utilidad para cada operación.
• Reserve presupuesto temporal para cola interna, regulación por TPS, aceptación del proveedor y reintentos.
• Suprima antes del envío si el presupuesto restante ya no permite una entrega útil.
• Mantenga la expiración de plataforma como una protección adicional, no como el único control de negocio.

Defina políticas distintas para OTP, transaccional y campañas consentidas

No existe un único plazo adecuado para toda clase de tráfico. La política debe derivarse de la acción esperada, de las consecuencias de un mensaje tardío y de la posibilidad de sustituirlo por información actualizada. El plazo debe documentarse como una regla de producto y operación, no como una suposición sobre la latencia de una ruta.

Para OTP, la referencia principal es la vigencia del secreto y el contexto de autenticación. Para comunicaciones transaccionales, importa si el evento sigue abierto o si existe un estado más reciente. Para campañas consentidas, importa especialmente la oportunidad comercial y evitar una repetición tardía que el destinatario no espera.

Los plazos concretos deben ser aprobados por los equipos responsables del flujo, seguridad, privacidad o protección de datos, cumplimiento y los requisitos regulatorios o contractuales locales aplicables. La plataforma debe implementar esos plazos de forma verificable y permitir identificar qué regla se aplicó a cada operación.

• OTP y recuperación: ventana breve y alineada con la aceptación del secreto; suprimir si vence antes del envío.
• Alertas transaccionales: enviar mientras el evento siga vigente; sustituir por una actualización si el estado cambió.
• Confirmaciones: no reenviar un mensaje antiguo si una confirmación posterior ya representa mejor el estado actual.
• Campañas consentidas: no reintentar automáticamente cuando la fecha, franja u oportunidad de la oferta ya ha pasado.

OTP: coordine transporte y secreto, pero no los confunda

Un OTP enviado por SMS debe ser de un solo uso dentro de su vigencia. El verificador debe rechazarlo cuando vence, incluso si el SMS se entrega después. Que el mensaje alcance el dispositivo no amplía la validez del código ni reactiva la operación de autenticación.

NIST establece, para la autenticación fuera de banda descrita en su guía, que debe completarse dentro de una ventana de diez minutos y que un secreto concreto solo debe aceptarse una vez durante su periodo de validez. Esa referencia no elimina la necesidad de una política propia para la cola: el emisor debe impedir que un código que ya no puede servir continúe avanzando hacia la entrega.

También deben limitarse los intentos fallidos cuando el secreto tenga menos de 64 bits. Emitir un secreto nuevo no debe reiniciar ese contador. Esta regla pertenece al verificador y no puede inferirse a partir del estado de transporte del SMS.

SMS puede utilizarse como canal fuera de banda, pero conviene ofrecer alternativas a las personas que no puedan usar PSTN. Los equipos de riesgo también deben considerar señales relevantes para el caso de uso, como cambios de SIM, portabilidad o cambio de dispositivo.

• Asigne al OTP una caducidad verificable en el verificador.
• Fije una expiración de utilidad de envío que no permita despachar códigos ya vencidos o prácticamente vencidos.
• No trate un DLR como evidencia de que el código fue visto, introducido o aceptado.
• Emita una nueva operación solo tras una nueva solicitud o dentro de un flujo controlado.
• No reinicie los controles de intentos fallidos simplemente al generar un nuevo código.

Coordine colas, TPS y reintentos con el tiempo que queda

Una cola puede convertir un mensaje válido al crearse en un mensaje inútil antes de emitirse. Esto sucede cuando se acumulan trabajos, se aplican límites de TPS, se espera una respuesta ascendente o se programa un reintento sin revisar el vencimiento de utilidad.

La planificación debe basarse en tiempo restante, no solo en antigüedad o prioridad. Un mensaje con una ventana corta necesita una decisión temprana: enviar si puede hacerlo dentro de la política, priorizarlo cuando sea legítimo y seguro, o finalizarlo antes de consumir más recursos. No es correcto mantenerlo indefinidamente por el mero hecho de que aún no haya recibido una respuesta final.

La especificación SMS contempla reintentos tras condiciones temporales y también un modo de un solo intento. La elección no debe ser automática para todos los casos. Reintentar puede ser razonable cuando la información sigue vigente y existe tiempo suficiente; puede ser perjudicial cuando el contenido depende de un estado que cambia rápidamente.

• Calcule el tiempo restante antes de encolar y antes de cada reintento.
• Evite programar un reintento cuya ejecución prevista caiga después del vencimiento de utilidad.
• Aplique reintentos solo ante condiciones transitorias y con una política explícita por caso de uso.
• Considere un solo intento cuando el riesgo de entrega tardía supera el beneficio de insistir.
• Detenga los reintentos al recibir una cancelación de la operación, una actualización que sustituya el mensaje o una expiración de utilidad.

Interprete los DLR como señales de transporte, no como prueba de uso

Los estados de entrega son necesarios para operar, pero no deben interpretarse más allá de su alcance. Los nombres, la fuente de la confirmación y el significado exacto de cada estado dependen de la integración, el proveedor, el operador y la ruta. Deben interpretarse conforme a la documentación técnica y contractual aplicable.

Por ejemplo, algunas integraciones usan etiquetas como «queued», «sent», «delivered», «undelivered» o «failed». En esa taxonomía, «queued» puede indicar que la solicitud fue aceptada y espera envío; «sent» puede indicar aceptación por un operador ascendente; y «delivered» puede reflejar una confirmación disponible en la cadena de transporte. El alcance y la fiabilidad de esas señales varían según la integración, el operador y la ruta.

Un DLR de entregado no demuestra que una persona haya leído, comprendido o utilizado el SMS. En SMS no existe un evento de lectura equivalente que permita convertir la entrega en prueba de consumo. Tampoco debe asumirse que un DLR entregado garantiza universalmente que el contenido fuera visible en el dispositivo o que produjera la acción esperada.

Por ello, el sistema debe separar el estado externo de transporte del resultado de negocio. En un OTP, por ejemplo, los eventos relevantes son al menos la entrega reportada, el intento de validación y la aceptación o rechazo del secreto. Ninguno debe sustituir a los demás.

• Ejemplos de estados de integración: «queued» puede significar solicitud aceptada y pendiente de envío en la plataforma que informa el estado.
• «Sent» puede indicar aceptación por un operador o proveedor ascendente, según la semántica documentada de la integración.
• «Delivered» puede representar una confirmación de entrega disponible desde la cadena de transporte; no equivale a lectura o uso.
• «Undelivered» o «failed» pueden señalar no entrega o imposibilidad de envío; conserve el motivo disponible según la integración.
• Resultado de negocio: estado independiente, como código aceptado, operación completada, alerta reconocida o acción no realizada.

Cuando vence la utilidad, finalice la operación con una causa explícita

Un mensaje pendiente cuya utilidad ha vencido no debe quedar ambiguamente en cola ni clasificarse solo con un estado técnico externo. La plataforma necesita un estado interno final que explique la decisión: por ejemplo, «suprimido por expiración de utilidad», junto con la hora y la regla que la motivó.

La acción posterior depende del tipo de tráfico. En OTP o recuperación, suprima el mensaje pendiente y no prolongue la vida del secreto. Para una alerta que sigue siendo relevante, genere una actualización vigente en lugar de insistir con el texto original. Para una campaña consentida, evite reenviar de manera automática contenido cuya oportunidad ya terminó.

Si la plataforma ya ha cedido el mensaje a un proveedor o a la red, quizá no pueda garantizar una cancelación efectiva. Por eso, la supresión antes del envío es el control principal. Después de la cesión, registre el estado conocido, preserve la incertidumbre y evite que un DLR posterior cambie retroactivamente la decisión de negocio.

• Cancelar: si la integración y el estado del trabajo todavía permiten retirarlo antes de la emisión.
• Suprimir: finalizar en la cola propia por utilidad vencida, sin enviarlo al siguiente salto.
• Reemitir: crear una nueva comunicación solo si el caso de uso aún lo justifica y con contenido actualizado.
• Escalar: investigar acumulaciones, reintentos inusuales, DLR incoherentes o expiraciones repetidas por destino, ruta o proveedor.

Registre los datos mínimos para auditar cada decisión

La política solo es verificable si cada mensaje deja una cronología suficiente para reconstruir qué se decidió y por qué. Los callbacks de entrega son asíncronos; por tanto, el orden de llegada de un DLR no debe sustituir a las marcas de tiempo de creación, aceptación, emisión y vencimiento.

Use un identificador de correlación estable para vincular la operación de negocio con cada intento de transporte. Mantenga separados el identificador interno, los identificadores de proveedor cuando existan y los identificadores de intento. Esto permite analizar duplicados, reintentos, supresiones y eventos tardíos sin confundir operaciones distintas.

Para auditoría operativa, use registros con controles de integridad, trazabilidad de cambios, retención definida y acceso restringido. Evite almacenar más contenido personal del necesario y aplique los requisitos de privacidad, protección de datos, retención, corrección y supresión que correspondan. Lo importante es poder demostrar la política aplicada, la secuencia de estados y el motivo de la decisión final.

• Identificador de correlación de la operación y tipo de caso de uso.
• Identificador interno del mensaje, identificadores de proveedor y de cada intento cuando existan.
• Hora de creación, aceptación, entrada y salida de cola, emisión y recepción de cada DLR.
• Vencimiento técnico configurado, expiración del contenido y vencimiento de utilidad.
• Estado técnico informado, estado interno final y marca temporal de cada transición.
• Decisión de reintento, cancelación o supresión, con su motivo y la regla aplicada.
• Resultado de negocio cuando corresponda, sin deducirlo de un DLR.