Validade de mensagens SMS A2P: como definir expiração, tentativas e estados finais sem prejudicar o utilizador

A validade de um SMS não é a expiração do seu conteúdo

Em SMS, o período de validade descreve durante quanto tempo uma mensagem deve ser mantida para tentativa de entrega antes de expirar. É um atributo de transporte e retenção na rede; não determina, por si só, se o conteúdo continua a ser adequado para o destinatário.

Esta distinção é essencial no tráfego A2P. Um SMS pode continuar tecnicamente entregável mesmo que o código OTP já não seja aceitável, o alerta já tenha sido resolvido ou uma promoção tenha perdido a oportunidade. Manter a mensagem em fila nestes casos pode gerar confusão, pedidos de suporte e decisões de segurança incorretas.

A política operacional não deve limitar-se a perguntar se o fornecedor ou a rede ainda consegue entregar o SMS. Deve responder a uma pergunta anterior: “A ação solicitada continua a ser correta, segura e útil se o destinatário receber esta mensagem agora?”.

• Validade técnica: tempo máximo de retenção e de tentativas de entrega na plataforma, no fornecedor ou na rede.
• Expiração do conteúdo: momento a partir do qual um código, ligação ou dado incluído deixa de ser válido.
• Janela de utilidade: período durante o qual receber a comunicação ainda permite uma ação relevante para o destinatário.

Use um limite absoluto de utilidade como decisão de controlo

A plataforma emissora deve calcular uma expiração absoluta de utilidade ao criar a operação. Esse momento deve acompanhar a mensagem durante a colocação em fila, a limitação por TPS, a seleção de conectividade, o envio e as novas tentativas.

Antes de cada transição relevante, verifique se resta tempo suficiente para que a mensagem continue a fazer sentido. Se a espera interna, o limite de emissão ou uma nova tentativa já tiverem consumido essa janela, a decisão correta costuma ser não enviar. Não é aconselhável delegar esta decisão apenas no período de validade configurável de um terceiro, porque esse valor pode aplicar-se somente ao tempo de permanência na respetiva plataforma.

O controlo deve ser executado antes de admitir o trabalho numa fila de saída, antes de o emitir para um fornecedor e antes de agendar cada nova tentativa. Assim, evita-se que uma mensagem desatualizada seja enviada apenas porque ainda havia capacidade técnica para a transportar.

• Defina uma hora de expiração de utilidade para cada operação.
• Reserve orçamento de tempo para fila interna, limitação por TPS, aceitação pelo fornecedor e novas tentativas.
• Suprima antes do envio se o orçamento restante já não permitir uma entrega útil.
• Mantenha a expiração da plataforma como uma proteção adicional, não como o único controlo de negócio.

Defina políticas distintas para OTP, transacional e campanhas com consentimento

Não existe um único prazo adequado para todas as classes de tráfego. A política deve resultar da ação esperada, das consequências de uma mensagem tardia e da possibilidade de a substituir por informação atualizada. O prazo deve ser documentado como uma regra de produto e operação, não como uma suposição sobre a latência de uma rota.

Para OTP, a principal referência é a validade do segredo e o contexto de autenticação. Para comunicações transacionais, importa saber se o evento continua aberto ou se existe um estado mais recente. Para campanhas com consentimento, importa especialmente a oportunidade comercial e evitar uma repetição tardia que o destinatário não espera.

Os prazos concretos devem ser aprovados pelas equipas responsáveis pelo fluxo, segurança, privacidade ou proteção de dados, conformidade e pelos requisitos regulamentares ou contratuais locais aplicáveis. A plataforma deve implementar esses prazos de forma verificável e permitir identificar qual a regra aplicada a cada operação.

• OTP e recuperação: janela curta e alinhada com a aceitação do segredo; suprima se expirar antes do envio.
• Alertas transacionais: envie enquanto o evento continuar válido; substitua por uma atualização se o estado mudar.
• Confirmações: não reenvie uma mensagem antiga se uma confirmação posterior já representar melhor o estado atual.
• Campanhas com consentimento: não efetue novas tentativas automaticamente quando a data, horário ou oportunidade da oferta já tiver passado.

OTP: coordene transporte e segredo, mas não os confunda

Um OTP enviado por SMS deve ser de utilização única dentro do seu período de validade. O verificador deve rejeitá-lo quando expira, mesmo que o SMS seja entregue posteriormente. O facto de a mensagem chegar ao dispositivo não prolonga a validade do código nem reativa a operação de autenticação.

O NIST estabelece, para a autenticação fora de banda descrita na sua orientação, que esta deve ser concluída numa janela de dez minutos e que um segredo específico só deve ser aceite uma vez durante o seu período de validade. Esta referência não elimina a necessidade de uma política própria para a fila: o emissor deve impedir que um código que já não pode ser utilizado continue a avançar para entrega.

As tentativas falhadas também devem ser limitadas quando o segredo tiver menos de 64 bits. Emitir um novo segredo não deve reiniciar esse contador. Esta regra pertence ao verificador e não pode ser inferida a partir do estado de transporte do SMS.

O SMS pode ser utilizado como canal fora de banda, mas é aconselhável disponibilizar alternativas às pessoas que não possam utilizar PSTN. As equipas de risco também devem considerar sinais relevantes para o caso de utilização, como alterações de SIM, portabilidade ou mudança de dispositivo.

• Atribua ao OTP uma expiração verificável no verificador.
• Defina uma expiração de utilidade de envio que não permita enviar códigos já expirados ou praticamente expirados.
• Não trate um DLR como prova de que o código foi visto, introduzido ou aceite.
• Emita uma nova operação apenas após um novo pedido ou dentro de um fluxo controlado.
• Não reinicie os controlos de tentativas falhadas apenas ao gerar um novo código.

Coordene filas, TPS e novas tentativas com o tempo restante

Uma fila pode transformar uma mensagem válida no momento da criação numa mensagem inútil antes da emissão. Isto acontece quando os trabalhos se acumulam, são aplicados limites de TPS, se aguarda uma resposta upstream ou se agenda uma nova tentativa sem rever a expiração de utilidade.

O planeamento deve basear-se no tempo restante, não apenas na antiguidade ou prioridade. Uma mensagem com uma janela curta exige uma decisão antecipada: enviar se isso puder ser feito dentro da política, dar-lhe prioridade quando for legítimo e seguro, ou finalizá-la antes de consumir mais recursos. Não é correto mantê-la indefinidamente apenas porque ainda não recebeu uma resposta final.

A especificação SMS prevê novas tentativas após condições temporárias e também um modo de tentativa única. A escolha não deve ser automática para todos os casos. Uma nova tentativa pode ser razoável quando a informação continua válida e existe tempo suficiente; pode ser prejudicial quando o conteúdo depende de um estado que muda rapidamente.

• Calcule o tempo restante antes de colocar em fila e antes de cada nova tentativa.
• Evite agendar uma nova tentativa cuja execução prevista ocorra após a expiração de utilidade.
• Aplique novas tentativas apenas perante condições transitórias e com uma política explícita para cada caso de utilização.
• Considere uma única tentativa quando o risco de entrega tardia superar o benefício de insistir.
• Interrompa as novas tentativas ao receber um cancelamento da operação, uma atualização que substitua a mensagem ou uma expiração de utilidade.

Interprete os DLR como sinais de transporte, não como prova de utilização

Os estados de entrega são necessários para a operação, mas não devem ser interpretados além do seu alcance. Os nomes, a origem da confirmação e o significado exato de cada estado dependem da integração, do fornecedor, do operador e da rota. Devem ser interpretados de acordo com a documentação técnica e contratual aplicável.

Por exemplo, algumas integrações usam etiquetas como «queued», «sent», «delivered», «undelivered» ou «failed». Nessa taxonomia, «queued» pode indicar que o pedido foi aceite e aguarda envio; «sent» pode indicar aceitação por um operador upstream; e «delivered» pode refletir uma confirmação disponível na cadeia de transporte. O alcance e a fiabilidade destes sinais variam consoante a integração, o operador e a rota.

Um DLR de entregue não demonstra que uma pessoa leu, compreendeu ou utilizou o SMS. No SMS, não existe um evento de leitura equivalente que permita transformar a entrega em prova de consumo. Também não se deve assumir que um DLR de entregue garante universalmente que o conteúdo ficou visível no dispositivo ou que produziu a ação esperada.

Por isso, o sistema deve separar o estado externo de transporte do resultado de negócio. Num OTP, por exemplo, os eventos relevantes incluem, pelo menos, a entrega reportada, a tentativa de validação e a aceitação ou rejeição do segredo. Nenhum deve substituir os restantes.

• Exemplos de estados de integração: «queued» pode significar pedido aceite e pendente de envio na plataforma que reporta o estado.
• «Sent» pode indicar aceitação por um operador ou fornecedor upstream, segundo a semântica documentada da integração.
• «Delivered» pode representar uma confirmação de entrega disponível na cadeia de transporte; não equivale a leitura ou utilização.
• «Undelivered» ou «failed» podem indicar não entrega ou impossibilidade de envio; retenha o motivo disponível de acordo com a integração.
• Resultado de negócio: estado independente, como código aceite, operação concluída, alerta reconhecido ou ação não realizada.

Quando a utilidade expira, finalize a operação com uma causa explícita

Uma mensagem pendente cuja utilidade expirou não deve permanecer ambiguamente em fila nem ser classificada apenas com um estado técnico externo. A plataforma necessita de um estado interno final que explique a decisão: por exemplo, «suprimido por expiração de utilidade», juntamente com a hora e a regra que a motivou.

A ação seguinte depende do tipo de tráfego. Em OTP ou recuperação, suprima a mensagem pendente e não prolongue a vida do segredo. Para um alerta que continua relevante, gere uma atualização válida em vez de insistir no texto original. Para uma campanha com consentimento, evite reenviar automaticamente conteúdo cuja oportunidade já terminou.

Se a plataforma já entregou a mensagem a um fornecedor ou à rede, poderá não conseguir garantir um cancelamento eficaz. Por isso, a supressão antes do envio é o controlo principal. Após a cedência, registe o estado conhecido, preserve a incerteza e evite que um DLR posterior altere retroativamente a decisão de negócio.

• Cancelar: se a integração e o estado do trabalho ainda permitirem retirá-lo antes da emissão.
• Suprimir: finalizar na própria fila por utilidade expirada, sem o enviar para o salto seguinte.
• Reemitir: criar uma nova comunicação apenas se o caso de utilização ainda o justificar e com conteúdo atualizado.
• Escalar: investigar acumulações, novas tentativas invulgares, DLR incoerentes ou expirações repetidas por destino, rota ou fornecedor.

Registe os dados mínimos para auditar cada decisão

A política só é verificável se cada mensagem deixar uma cronologia suficiente para reconstruir o que foi decidido e porquê. Os callbacks de entrega são assíncronos; por isso, a ordem de chegada de um DLR não deve substituir as marcas temporais de criação, aceitação, emissão e expiração.

Utilize um identificador de correlação estável para ligar a operação de negócio a cada tentativa de transporte. Mantenha separados o identificador interno, os identificadores de fornecedor quando existirem e os identificadores de tentativa. Isto permite analisar duplicados, novas tentativas, supressões e eventos tardios sem confundir operações distintas.

Para auditoria operacional, utilize registos com controlos de integridade, rastreabilidade de alterações, retenção definida e acesso restrito. Evite armazenar mais conteúdo pessoal do que o necessário e aplique os requisitos aplicáveis de privacidade, proteção de dados, retenção, retificação e eliminação. O importante é conseguir demonstrar a política aplicada, a sequência de estados e o motivo da decisão final.

• Identificador de correlação da operação e tipo de caso de utilização.
• Identificador interno da mensagem, identificadores de fornecedor e de cada tentativa, quando existirem.
• Hora de criação, aceitação, entrada e saída da fila, emissão e receção de cada DLR.
• Expiração técnica configurada, expiração do conteúdo e expiração de utilidade.
• Estado técnico reportado, estado interno final e marca temporal de cada transição.
• Decisão de nova tentativa, cancelamento ou supressão, com o respetivo motivo e regra aplicada.
• Resultado de negócio quando aplicável, sem o deduzir de um DLR.