IOSOR Kunskap

DLR-retry vid misslyckande under prepaid: när du ska försöka igen och när du ska sluta spendera

Failed, rejected och expired är inte samma ord. Varje prepaid-retry är en debitering. Dela statusordlistan före taket, annars brinner plånboken i en återvändsgränd.

Ärendet säger «misslyckades» och någon hamrar retry tills prepaidplånboken är tom. Misslyckat är ingen status. undelivered, rejected och expired kräver olika handlingar. Under prepaid är varje automatisk retry en debetrad, inte en gratis artighet. Enas om ordlistan före loopen, annars jagar produkt konvertering medan finans betalar andra och tredje försöket till ett dött nummer.

IOSOR är white-label prepaid: samma DLR-vokabulär i panel, webhook och export. En korridor live tillåter begränsad retry; in setup öppnas inte «nästa gång». Se ej levererad, avvisad, utgången och DLR, latens och failover. Nära USD 1,000+ per månad går retrydebiteringar per statushink in i en tätare kommersiell läsning.

Statusordlista före retrylogik

Innan ni skriver retrykod, skriv ut terminalstatusar i en tabell som produkt, ops och finans kan peka på. Retry utan ordlista är en loop som bränner pengar. Vid sjunkande leverans: handbok vid låg SMS-leverans.

Status Auto-retry? Vem signerar
Delivered Nej Ingen
Undelivered / failed Med tak Ops
Rejected Nej (ändra payload) Produkt
Expired Nej (justera TTL) Produkt

Failed kontra rejected kontra expired

Failed / undelivered betyder att plattformen lämnade jobbet och terminalen inte bekräftade. Är korridoren frisk kan en begränsad retry rädda en konvertering. Rejected är ett nät- eller policyavslag: samma nummer, samma kropp, nästan alltid nytt avslag och ny debitering. Expired är tid: TTL kortare än korridorlatens, eller en kö före sändning. Att behandla expired som failed och hamra retries skapar bara fler expired-rader. En OTP utanför fönstret konverterar inte längre — plånboken betalar ändå.

Retrytak och plånbokseffekt

Sätt ett tak för automatiska försök per meddelande och skilj användarens omsändning från systemfailover. Varje försök ska stämma med ett correlation ID i liggaren. «Tills levererat» utan tak tömmer prepaid på en död korridor. Finans måste exportera destination, status, försöksnr och debitering. Nära USD 1,000+ blir en loop utan ägare ett kommersiellt ämne, inte ett ärende. När policyn säger stopp stannar plånboken även om produkt vill en gång till.

Produkt kontra finansägarskap

Produkt äger policyn: vilka statusar tillåter retry, TTL, cooldown för omsändning. Finans äger synligheten: debiteras varje försök, stämmer exporten med webhook. Ops äger korridorsnittet så att ett världsmedel inte gömmer en trasig rutt. Utan samma tabell kan prepaid inte välja «försök igen» mot «sluta spendera». Låt inte support lova muntlig återbetalning medan liggaren belastar varje försök.

Röda flaggor

  • Bara sent och failed, men automatisk retry
  • Tre identiska slag mot en rejected-payload
  • Expired behandlat som nätfel
  • Systemfailover och användaromsändning på samma debetrad
  • «Tills levererat» utan försökstak
  • Retry utlovat medan katalogen är in setup
  • Finansexport utan försöksnr

Börja med IOSOR

Fyll ordboken: failed versus rejected versus expired. Sätt tak på automatisk retry så att varje misslyckad DLR inte öppnar en ny prepaid-debitering. Användarens skicka-igen-knapp är skild från systemförsöket. Bevisa taket på två live-korridorer vid låg volym.

IOSOR sammanfattning

Retry vid misslyckad DLR är ett utgiftstak, inte en evig slinga.

Gör: klassificera slutstatus, tak försök, exportera användarens omsändning skild från systemförsöket. Gör inte: retria rejected eller expired som om de vore tillfälliga failed.

Var den här guiden till hjälp?

Relaterade guider