IOSOR

IOSOR Guias

Undelivered vs rejected vs expired: dicionário de estados para produto e billing

Deem de discutir por capturas: alinhem produto, suporte e billing pré-pago em undelivered, rejected e expired — e nas ações que cada estado realmente autoriza.

Quando a entregabilidade cai, produto culpa o pipe, suporte cola capturas e finance pergunta por que a carteira pré-paga se moveu. Grande parte do calor é uma falha de vocabulário. Undelivered, rejected e expired não são sinónimos — tratá-los como um único balde “failed” inventa retries errados, reembolsos errados e severidade de incidente errada.

A IOSOR quer que equipas B2B operem messaging como white-label pré-pago: financiar uma vez, ler eventos de estado duráveis e manter linguagem de erro brand-safe. Este dicionário é o contrato operativo entre UX de produto, ops e o ledger.

Porque palavras de estado causam mais incidentes do que outages

Classe Exemplos O produto deve…
Intermediate queued, submitted, sent Mostrar progresso; não celebrar sucesso no handset
Terminal success delivered Desbloquear o próximo UX; parar reenvio automático
Terminal fail undelivered, rejected, expired (se terminal) Escolher uma ação licenciada; nunca retry infinito

O dicionário de estados: definições que produto e billing podem acordar

Undelivered geralmente significa que o job entrou no path live de messaging mas um sinal downstream diz que o handset não obteve sucesso. Drivers típicos: handset off, inbox cheio, congestão temporária do corredor, subscritor inalcançável.

Ações licenciadas:

Undelivered vs rejected: classes de falha diferentes, fixes diferentes

Rejected é falha de política ou admissão: filtro de conteúdo, identidade do remetente, gate de compliance, destino malformado, fundos insuficientes, ou catalog-not-live para essa capability. O job nunca ganhou uma oportunidade justa de entrega ao handset.

Ações licenciadas:

Expired: TTL, filas e janelas de timing OTP

Expired significa que a janela de validade fechou antes de um sucesso terminal. Comum em OTP (TTL), jobs em fila past SLA, ou janelas de validade de rede. O produto deve separar user expired (utilizador parado) de network expired (o pipe não entregou a tempo).

Ações licenciadas:

Sinais de alerta

  • Só existe “failed”
  • Capturas como único sistema de estado
  • Tempestades de auto-retry em rejected
  • Movimentos de carteira sem rasto de estado
  • Texto de marca estrangeira em razões de falha do lado do cliente

Comece com a IOSOR

Mapeie os seus retornos de status na consola do IOSOR para que a sua integração de faturação separe limpidamente as rejeições precoces de eventos não entregues a jusante e de expirações na fila. Audite os seus webhooks ativos para garantir que os códigos de estado DLR terminais passam classes de erro explícitas para o seu registo interno em vez de um estado de falha genérico.

Conclusão IOSOR

Este guia demonstrou que a ambiguidade de status é um problema de design de produto e contabilidade, e não uma simples falha de rede. Distinguir entre rejeições da operadora, estados não entregues a jusante e expirações de TTL esclarece a responsabilidade financeira e impede que as equipas de suporte procurem bugs fantasma no código da aplicação.

Este guia foi útil?

Guias relacionados