IOSOR

IOSOR Guide

Undelivered vs rejected vs expired: dizionario di stati per prodotto e billing

Smettete di litigare sulle screenshot: allineate prodotto, supporto e billing prepago su undelivered, rejected ed expired — e sulle azioni che ogni stato autorizza davvero.

Quando cala la deliverability, il prodotto incolpa il pipe, il supporto incolla screenshot e la finance chiede perché si è mosso il wallet prepago. Gran parte del calore è un fallimento di vocabolario. Undelivered, rejected ed expired non sono sinonimi — trattarli come un unico bucket “failed” inventa retry sbagliati, rimborsi sbagliati e severità incidente sbagliata.

IOSOR vuole che i team B2B operino il messaging come white-label prepago: finanziare una volta, leggere eventi di stato durevoli e mantenere linguaggio di errore brand-safe. Questo dizionario è il contratto operativo tra UX di prodotto, ops e ledger.

Perché le parole di stato causano più incidenti degli outage

Classe Esempi Il prodotto deve…
Intermediate queued, submitted, sent Mostrare progresso; non celebrare successo handset
Terminal success delivered Sbloccare il prossimo UX; fermare il reinvio automatico
Terminal fail undelivered, rejected, expired (se terminal) Scegliere un’azione autorizzata; mai retry infinito

Il dizionario di stati: definizioni che prodotto e billing possono condividere

Undelivered di solito significa che il job è entrato nel path messaging live ma un segnale downstream dice che l’handset non ha ottenuto successo. Driver tipici: handset spento, inbox piena, congestione temporanea del corridoio, subscriber irraggiungibile.

Azioni autorizzate:

Undelivered vs rejected: classi di failure diverse, fix diversi

Rejected è un fallimento di policy o ammissione: filtro contenuti, identità mittente, gate di compliance, destinazione malformata, fondi insufficienti, o catalog-not-live per quella capability. Il job non ha mai guadagnato una chance equa di consegna all’handset.

Azioni autorizzate:

Expired: TTL, code e finestre di timing OTP

Expired significa che la finestra di validità si è chiusa prima di un successo terminale. Comune in OTP (TTL), job in coda past SLA, o finestre di validità di rete. Il prodotto deve separare user expired (utente bloccato) da network expired (il pipe non ha consegnato in tempo).

Azioni autorizzate:

Red flag

  • Esiste solo “failed”
  • Screenshot come unico sistema di stato
  • Tempeste di auto-retry su rejected
  • Movimenti wallet senza traccia di stato
  • Testo di brand estraneo nelle ragioni di fail lato client

Inizia con IOSOR

Mappa i callback di stato nella console IOSOR affinché la tua integrazione di fatturazione separi nettamente i rifiuti anticipati dagli eventi non recapitati a valle e dalle scadenze di coda. Verifica i webhook attivi per assicurarti che i codici di stato DLR terminali passino classi di errore esplicite al tuo registro interno anziché uno stato di errore generico.

Sintesi IOSOR

Questa guida ha dimostrato che l ambiguità dello stato rappresenta un problema di progettazione di prodotto e contabilità piuttosto di un semplice guasto di rete. Distinguere tra rifiuti dell operatore, stati non recapitati a valle e scadenze TTL chiarisce la responsabilità finanziaria ed evita che i team di supporto inseguano bug fantasma nel codice dell applicazione.

Questa guida ti è stata utile?

Guide correlate