IOSOR Ghiduri
Politica de retry DLR eșuat sub prepaid: când să reîncerci și când să oprești cheltuiala
Failed, rejected și expired nu sunt același cuvânt. Fiecare retry prepaid este un debit. Împărtășiți dicționarul de stări înainte de plafon, altfel portofelul arde într-o fundătură.
Tichetul zice «a eșuat» și cineva lovește retry până portofelul prepaid e gol. Eșecul nu e o stare. undelivered, rejected și expired cer fapte diferite. Sub prepaid fiecare retry automat e o linie de debit, nu o politețe gratuită. Acordați dicționarul înainte de buclă, altfel produsul aleargă conversia iar finanțele plătesc a doua și a treia încercare către un număr mort.
IOSOR este prepaid white-label: același vocabular DLR în panou, webhook și export. Un coridor live admite retry cu plafon; in setup nu se deschide «data viitoare». Vezi nedistribuit, respins, expirat și DLR, latență și failover. Aproape de USD 1,000+ lunar, debitele de retry pe găleată de stare intră într-o lectură comercială mai strânsă.
Dicționar de stări înainte de logica de retry
Înainte de a scrie cod de retry, imprimați stările terminale într-un tabel pe care produs, ops și finanțe îl pot arăta. Retry fără dicționar e o buclă care arde bani. La livrabilitate în scădere: playbook pentru livrare SMS scăzută.
| Stare | Retry automat? | Cine semnează |
|---|---|---|
| Delivered | Nu | Nimeni |
| Undelivered / failed | Cu plafon | Ops |
| Rejected | Nu (schimbați payload) | Produs |
| Expired | Nu (ajustați TTL) | Produs |
Failed versus rejected versus expired
Failed / undelivered înseamnă că platforma a predat treaba și terminalul nu a confirmat. Dacă coridorul e sănătos, un retry cu plafon poate salva o conversie. Rejected e un refuz de rețea sau de politică: același număr, același corp, aproape mereu un nou refuz și un nou debit. Expired e timp: TTL mai scurt decât latența coridorului, sau o coadă înainte de trimitere. A trata expired ca failed și a lovi retry creează doar mai multe rânduri expired. Un OTP în afara ferestrei nu mai convertește — portofelul plătește oricum.
Plafoane de retry și impactul portofelului
Puneți un plafon de încercări automate pe mesaj și despărțiți resendul utilizatorului de failoverul de sistem. Fiecare încercare trebuie să coincidă cu un correlation ID în ledger. «Până livrat» fără plafon golește prepaidul pe un coridor mort. Finanțele trebuie să exporte destinație, stare, nr. încercare și debit. Aproape de USD 1,000+, o buclă fără proprietar încetează să fie tichet și devine temă comercială. Când politica zice stop, portofelul se oprește chiar dacă produsul vrea încă o dată.
Proprietatea produs versus finanțe
Produsul deține politica: ce stări permit retry, TTL, cooldown de resend. Finanțele dețin vizibilitatea: debitează fiecare încercare, se potrivește exportul cu webhookul. Ops deține tăietura de coridor ca o medie mondială să nu ascundă o rută ruptă. Fără același tabel, prepaidul nu decide «reîncearcă» versus «oprește cheltuiala». Nu lăsați suportul să promită ramburs verbal în timp ce ledgerul taxează fiecare încercare.
Steaguri roșii
- Doar sent și failed, dar retry automat
- Trei lovituri identice pe un payload rejected
- Expired tratat ca avarie de rețea
- Failover de sistem și resend utilizator pe aceeași linie de debit
- «Până livrat» fără plafon de încercări
- Retry promis cu catalogul in setup
- Export financiar fără nr. încercare
Începeți cu IOSOR
Completați dicționarul: failed versus rejected versus expired. Puneți plafon pe retry-ul automat ca fiecare DLR eșuat să nu deschidă un debit prepaid nou. Butonul de retrimitere al utilizatorului e separat de tentativa sistemului. Dovediți plafonul pe două coridoare live la volum mic.
Rezumat IOSOR
Retry-ul unui DLR eșuat este un plafon de cheltuială, nu o buclă infinită.
Faceți: clasificați starea terminală, plafonați tentativele, exportați retrimiterea utilizatorului separat de tentativa sistemului. Nu faceți: reîncercați rejected sau expired ca pe un failed trecător.
A fost util acest ghid?
Ghiduri conexe
- Compararea metricilor de livrare între rutele cu cod scurt și numere gratuite
Analizați metricile de livrare SMS între codurile scurte și numerele gratuite pentru clienții CPaaS white-label, detaliind filtrarea și urmărirea DLR.
- Stabilirea metricilor de bază pentru livrabilitate în timpul pilotării noilor rute
Rulați suite riguroase de testare, analizați performanța operatorilor și stabiliți metrici de bază înainte de a scala traficul white-label.
- Auditarea ratelor de livrare și curățarea cozilor după întreținerea rețelei
Ghid tehnic pas cu pas pentru administratorii de platformă în vederea verificării stării rutelor și golirii în siguranță a cozilor DLR întârziate după fereastra de întreținere.