# Perché i messaggi OTP non vengono recapitati e come risolvere i problemi di consegna > I codici OTP non funzionano per una serie limitata di motivi: rifiuto dell'ID del mittente, percorsi non ufficiali, limitazione della velocità, filtri dei contenuti, codifica, congestione. Una guida alla diagnosi e alla risoluzione dei problemi per i tecnici sul campo. - URL canonico: https://www.broadnet.me/it/blog/why-otp-messages-fail-delivery-troubleshooting - Lingua: it - Ultimo aggiornamento: 2026-10-20 - Editore: BroadNet (https://www.broadnet.me) - Pubblicato il: 2026-05-20 - Autore: BroadNet Engineering Quando un codice monouso non viene inviato, l'utente rimane bloccato nella schermata di login o di pagamento, a un passo dall'abbandonare la procedura. La parte frustrante per il team di sviluppo è che spesso il messaggio viene inviato correttamente: l'API restituisce 202, l'invio SMPP viene accettato, la piattaforma mostra un messaggio in coda. L'errore si verifica da qualche parte a valle, su un collegamento che il team applicativo non può vedere direttamente. Questo articolo analizza l'elenco finito dei motivi per cui i codici monouso non vengono inviati in produzione, come distinguerli dalle ricevute che invece vengono inviate e la procedura di risoluzione per ciascuno di essi. ## La superficie di rottura è più piccola di quanto sembri Il traffico OTP fallisce per uno dei sette motivi seguenti, all'incirca in quest'ordine di frequenza: rifiuto dell'ID mittente da parte dell'operatore di destinazione, un passaggio in una rotta non ufficiale che causa la perdita o il ritardo del messaggio, limitazione della velocità presso l'SMSC o il firewall, filtri di contenuto che si attivano a causa di un modello, mancata corrispondenza di codifica tra il contenuto UCS-2 e un modello GSM-7, congestione della rete presso l'operatore di destinazione e il telefono stesso irraggiungibile (spento, fuori copertura, portabilità con routing obsoleto). Tutto il resto — MSISDN corrotto, credenziali scadute, eventi di instradamento non disponibile — rappresenta una piccola minoranza. Diagnosticare prima i casi più comuni. ## Leggi le ricevute di consegna, non la risposta all'invio. L'errore più grande che i team commettono è quello di considerare un invio riuscito (202 da HTTP, ESME_ROK su submit_sm) come prova dell'avvenuta consegna del messaggio. Non lo è. L'invio significa che la piattaforma ha accettato il messaggio; la consegna significa che il dispositivo mobile lo ha ricevuto. Ogni sistema OTP deve essere collegato alla [ricevuta di consegna](https://www.broadnet.me/answers/what-is-dlr) (DLR), che arriva successivamente come webhook o PDU deliver_sm e contiene uno dei seguenti codici di stato: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. Il primo segnale per qualsiasi indagine OTP è la distribuzione dello stato DLR per percorso, ID mittente, operatore di destinazione e intervallo di tempo, non la percentuale di successo dell'invio. ## Diagnosticare individuando il punto in cui si è verificato il guasto. Un'indagine OTP accurata suddivide il problema in quattro segmenti e procede a ritroso dal segnale più a valle. Segmento 1: errore all'invio: la piattaforma ha rifiutato la chiamata prima ancora che partisse, quasi sempre a causa di un ID mittente non valido, una categoria di modello non registrata, un paese non supportato o un campo obbligatorio mancante. Segmento 2: accettato all'invio ma mai consegnato all'SMSC di destinazione: di solito un problema di qualità del percorso o un blocco del firewall. Segmento 3: consegnato all'SMSC e restituito un DLR negativo: contenuto filtrato, ID mittente nella blacklist dell'operatore, destinatario bloccato. Segmento 4: DLR positivo ma l'utente segnala l'assenza di messaggi: telefono spento, portabilità a un altro operatore con routing obsoleto, filtro antispam a livello di sistema operativo o notifica soppressa. La soluzione varia in ogni segmento; confonderli porta i team fuori strada. ## Le sette cause più comuni e come affrontarle ### 1. Rifiuto dell'ID mittente Molti mercati regolamentati — Emirati Arabi Uniti (sotto TDRA), Arabia Saudita (sotto CST), Egitto (sotto NTRA), India (sotto DLT di TRAI) — richiedono che ogni ID mittente alfanumerico sia preregistrato presso un'entità legale verificata. Il traffico inviato con un ID non registrato viene rifiutato al confine dell'operatore e produce un DLR negativo con messaggio non consegnato, ma la risposta di invio è 202. La soluzione è la registrazione e la diagnosi consiste nel correlare UNDELIV/REJECTD con l'ID mittente e il paese di destinazione: se ogni errore condivide un ID mittente in un paese, il problema è la registrazione. Consultare la [guida alla registrazione dell'ID mittente per i mercati del GCC](https://www.broadnet.me/blog/sender-id-registration-guide-gcc-markets) per la documentazione specifica. ### 2. Salti di percorso grigi Le rotte internazionali economiche spesso prevedono uno o più hop di re-iniezione attraverso aggregatori partner o terminazioni SIM-farm. Ogni hop aggiunge latenza, aumenta la probabilità di interruzione silenziosa e accresce la possibilità che il firewall dell'operatore di destinazione classifichi il traffico come A2P non autorizzato e lo blocchi. La caratteristica distintiva è un'elevata percentuale di messaggi non recapitati (UNDELIV), un'elevata varianza della latenza e una percentuale di consegna che cala drasticamente quando l'operatore di destinazione implementa o aggiorna un firewall SMS. La soluzione consiste nello spostare l'OTP su una rotta diretta dell'operatore; il compromesso è discusso in "Rotte dirette contro rotte non ufficiali". ### 3. Limitazione della velocità a livello dell'SMSC o del firewall Ogni operatore e ogni firewall impone un limite massimo di TPS (transazioni al secondo) per ID mittente e per percorso. Superando tale limite, i messaggi vengono rifiutati immediatamente (nel migliore dei casi, l'errore è visibile) oppure accodati e consegnati in ritardo (nel peggiore dei casi, arrivano dopo la scadenza dell'OTP e quando l'utente ha già rinunciato). La diagnosi consiste nell'analizzare i picchi di invio rispetto alla latenza p95: una curva di latenza stabile sotto carico costante che presenta picchi durante i burst indica una limitazione della velocità. La soluzione consiste nel limitare la velocità a livello applicativo per attenuare i burst e negoziare un limite massimo di TPS più elevato specificamente per il traffico di classe OTP. ### 4. Filtri di contenuto I classificatori di contenuto degli operatori e dei firewall possono segnalare i modelli OTP che contengono parole chiave, URL (la maggior parte degli operatori è particolarmente aggressiva nei confronti dei link abbreviati non verificati nei contenuti transazionali), nomi del mittente insoliti o layout che ricordano schemi di phishing noti. La caratteristica distintiva è un singolo modello che improvvisamente registra tassi di rifiuto elevati, mentre tutto il resto viene instradato correttamente. La soluzione è la pulizia del modello: testo OTP breve e convenzionale, nessun link abbreviato, nessun linguaggio che trasmetta un senso di urgenza. Se il modello è regolamentato (in alcuni mercati i modelli transazionali devono essere preregistrati), assicurarsi che la versione registrata corrisponda alla versione inviata: anche le piccole variazioni vengono rilevate. ### 5. Mancata corrispondenza della codifica I modelli OTP con caratteri non ASCII (una vocale accentata, un segno di virgoletta speciale copiato da un documento di progettazione, una cifra araba) aggiornano silenziosamente il messaggio da GSM-7 a UCS-2, riducendo il budget di caratteri per segmento da 160 a 70 e causando messaggi concatenati che alcuni telefoni più vecchi riassemblano in modo errato. La diagnosi consiste nell'esaminare il modello effettivamente renderizzato byte per byte, non il modello come lo sviluppatore pensa che sia. La soluzione è una revisione del modello consapevole della codifica e un controllo in fase di compilazione che segnala eventuali caratteri non GSM-7 in un modello transazionale. ### 6. Congestione della rete I centri SMSC degli operatori di destinazione a volte subiscono rallentamenti durante eventi importanti (Eid, Black Friday, festività nazionali, interruzioni di servizio di vasta portata): le richieste vengono accettate, ma le latenze di consegna aumentano da frazioni di secondo a diversi minuti. Non esiste una soluzione definitiva da parte del mittente; la mitigazione consiste nel rilevare la condizione (un forte aumento della latenza p95 su tutte le rotte verso un singolo operatore) e passare a un canale alternativo prima della chiusura della finestra OTP. ### 7. Telefono irraggiungibile Una piccola ma persistente percentuale di errori OTP non è affatto dovuta all'infrastruttura: il telefono è spento, fuori copertura, in modalità aereo, ha il filtro antispam dell'operatore che blocca i mittenti sconosciuti oppure è stato trasferito a un nuovo operatore e le tabelle di routing non sono converge. La firma è costituita da DLR SCADUTI o SCONOSCIUTI sparsi su tutte le rotte e gli ID mittente, senza alcuna concentrazione a livello di operatore. La soluzione è la catena di fallback descritta di seguito. ## Crea la dashboard diagnostica una volta sola e usala per sempre. La maggior parte delle indagini OTP si blocca perché il team sta leggendo i log grezzi sotto pressione. I team che si riprendono rapidamente hanno una dashboard permanente con cinque widget: distribuzione dello stato DLR per operatore di destinazione (il grafico più utile in assoluto), latenza end-to-end p50/p95/p99 per rotta, tasso di consegna a livello di ID mittente, tasso di consegna a livello di modello di contenuto e una serie temporale in tempo reale dall'invio alla consegna per l'ultima ora. Create questi elementi una volta sola. Fanno la differenza tra una diagnosi di quaranta minuti e una di quattro ore. ## Modelli di risanamento che funzionano davvero ### Collegamenti diretti solo per OTP Il traffico di marketing di massa e il traffico OTP non devono condividere un percorso o un indirizzo. Il marketing è sensibile ai costi, tollerante alla latenza e può utilizzare percorsi all'ingrosso; l'OTP è critico per la latenza e la deliverability e necessita di un percorso diretto. La condivisione di questi percorsi comporta che un picco di traffico di marketing congestioni il percorso OTP e che un filtro di percorso basato su modelli di marketing comprometta la reputazione del percorso per l'OTP. ### Catena di fallback, automatica e a tempo limitato Progettare il sistema partendo dal presupposto che un singolo canale possa occasionalmente fallire e definire di conseguenza la catena di fallback: utilizzare prima il modello di autenticazione WhatsApp o RCS se l'utente è raggiungibile tramite uno dei due, poi gli SMS come fallback universale e infine l'OTP vocale come ultima risorsa. Il fallback deve essere automatico (nessun tentativo manuale da parte dell'utente), a tempo limitato (l'attesa prima del failover deve essere inferiore alla soglia di pazienza dell'utente, in genere da 8 a 15 secondi) e condizionale (non fallire in caso di DLR positivo; fallire in caso di timeout o DLR negativo). Il codice OTP stesso deve essere generato una sola volta e riutilizzato su tutti i canali, in modo che all'utente non vengano presentati due codici validi. ### Evitare duplicati a ogni tentativo Quando l'utente tocca "reinvia" o l'applicazione effettua un nuovo tentativo automatico, verifica prima di inviare di nuovo. L'API BroadNet non accetta una chiave di idempotenza, quindi la deduplicazione spetta al tuo codice: registra ogni invio prima di effettuarlo, conserva l'ID messaggio restituito dall'API e verifica lo stato di quel messaggio prima di qualsiasi reinvio (vedi [idempotenza e retry sicuri](https://www.broadnet.me/developers/idempotency)). Senza questo controllo, un primo invio lento ma andato a buon fine e un successivo reinvio automatico generano due codici OTP nella casella di posta dell'utente, quest'ultimo utilizza quello più vecchio, la verifica fallisce e il team attribuisce la colpa al servizio OTP quando il problema risiede nella logica di invio automatico. ### Ripiego vocale per la coda lunga Circa l'uno per cento degli utenti, in un dato giorno, non riceverà un SMS per nessuno dei motivi sopra elencati, e quell'uno per cento rappresenta la "coda lunga" che chiama l'assistenza. Un [OTP vocale](https://www.broadnet.me/products/myotp) – una chiamata in cui il codice viene letto ad alta voce – risolve quasi tutti questi problemi. È la differenza tra un utente infastidito che prova con un altro browser e un utente disorientato che rinuncia. > Il servizio OTP di BroadNet gestisce l'associazione diretta, la catena di fallback e l'escalation vocale tramite una singola chiamata API, restituisce un ID messaggio da verificare prima di qualsiasi reinvio ed espone la suddivisione DLR per canale e per operatore da cui dipende la guida diagnostica di cui sopra. ## Che aspetto ha il bene, in numeri Un sistema OTP ben strumentato, che invia messaggi in un mercato regolamentato del GCC su rotte dirette dell'operatore, con una catena di fallback funzionante, dovrebbe garantire: un tasso di completamento end-to-end superiore al 99% (l'utente ha verificato con successo, non solo che il messaggio è stato consegnato), una latenza p95 inferiore a cinque secondi sul canale primario e un tasso di fallback misurabile ma ridotto (1-3%) al canale secondario. Se i vostri risultati sono significativamente peggiori, il problema è quasi certamente una delle sette cause sopra elencate: diagnosticate, non fate supposizioni. ## Letture correlate - [API SMS contro SMPP: qual è la soluzione migliore per le aziende?](https://www.broadnet.me/blog/sms-api-vs-smpp-enterprise-decision-guide) - [Come le banche dovrebbero monitorare la consegna e le frodi relative agli OTP](https://www.broadnet.me/blog/bank-otp-delivery-monitoring-fraud-playbook) - [In che modo la verifica delle chiamate flash influisce sui ricavi A2P degli operatori](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact) - Glossario — [cos'è l'OTP](https://www.broadnet.me/answers/what-is-otp), [cos'è un DLR](https://www.broadnet.me/answers/what-is-dlr), [cos'è la verifica della chiamata flash](https://www.broadnet.me/answers/what-is-flash-call-verification) - Pagine prodotto — [Servizio OTP](https://www.broadnet.me/products/otp) e [OTP vocale MyOTP](https://www.broadnet.me/products/myotp) - Copertura — [Instradamento SMS A2P e OTP negli Emirati Arabi Uniti](https://www.broadnet.me/coverage/uae)