Policy di retry DLR fallito sotto prepaid: quando riprovare e quando smettere di spendere

Il ticket dice «è fallito» e qualcuno martella retry finché il wallet prepaid è vuoto. Fallito non è uno stato. undelivered, rejected ed expired chiedono atti distinti. Sotto prepaid ogni retry automatico è una riga di addebito, non un favore gratis. Accordate il dizionario prima del loop, o il prodotto insegue la conversione mentre finance paga il secondo e il terzo tentativo verso un numero morto.

IOSOR è prepaid white-label: lo stesso vocabolario DLR in cruscotto, webhook ed export. Un corridoio live ammette retry con tetto; in setup non si apre «al colpo dopo». Vedere non consegnato, rifiutato, scaduto e DLR, latenza e failover. Verso USD 1,000+ al mese, gli addebiti di retry per secchio di stato entrano in una lettura commerciale più stretta.

Dizionario di stato prima della logica di retry

Prima di scrivere codice di retry, stampate gli stati terminali in una tabella che prodotto, ops e finance possano indicare. Retry senza dizionario è un loop che brucia soldi. Per la consegnabilità in calo, playbook per bassa deliverability SMS.

Failed contro rejected contro expired

Failed / undelivered significa che la piattaforma ha consegnato il lavoro e il terminale non ha confermato. Se il corridoio è sano, un retry con tetto può salvare una conversione. Rejected è un rifiuto di rete o di policy: stesso numero, stesso body, quasi sempre un nuovo rifiuto e un nuovo addebito. Expired è tempo: TTL più corto della latenza del corridoio, o una coda prima dell’invio. Trattare expired come failed e martellare retry crea solo più righe expired. Un OTP fuori finestra non converte più, il wallet paga lo stesso.

Tetti di retry e impatto sul wallet

Mettete un tetto di tentativi automatici per messaggio e separate il resend utente dal failover di sistema. Ogni tentativo deve quadrare con un correlation ID nel ledger. «Fino a consegnato» senza tetto svuota il prepaid su un corridoio morto. Finance deve esportare destinazione, stato, n° tentativo e addebito. Verso USD 1,000+, un loop senza proprietario smette di essere un ticket e diventa tema commerciale. Quando la policy dice stop, il wallet si ferma anche se il prodotto vuole un altro colpo.

Proprietà prodotto contro finance

Il prodotto possiede la policy: quali stati ammettono retry, TTL, cooldown di resend. Finance possiede la visibilità: ogni tentativo addebita, l’export quadra con il webhook. Ops possiede il taglio per corridoio perché una media mondiale non nasconda una rotta rotta. Senza la stessa tabella il prepaid non decide «riprovare» contro «smettere di spendere». Non lasciate che il supporto prometta rimborsi a voce mentre il ledger addebita ogni tentativo.

Bandiere rosse

• Solo sent e failed, ma c’è retry automatico
• Tre colpi identici su un payload rejected
• Expired trattato come guasto di rete
• Failover di sistema e resend utente sulla stessa riga di addebito
• «Fino a consegnato» senza tetto di tentativi
• Retry promesso con catalogo in setup
• Export finance senza n° tentativo

Iniziare con IOSOR

Riempite il dizionario: failed contro rejected contro expired. Mettete un tetto al retry automatico così ogni DLR fallito non apre un nuovo addebito prepaid. Il pulsante reinvio dell’utente è distinto dal tentativo di sistema. Provate il tetto su due corridoi live a basso volume.

Sintesi IOSOR

Il retry di un DLR fallito è un tetto di spesa, non un ciclo infinito.