IOSOR

IOSOR Kunnskap

DLR-retry ved feil under prepaid: når du skal prøve igjen, og når du skal slutte å bruke

Failed, rejected og expired er ikke samme ord. Hver prepaid-retry er en debitering. Del statusordboken før taket, ellers brenner lommeboken i en blindvei.

Saken sier «feilet», og noen hamrer retry til prepaidlommeboken er tom. Feil er ikke en status. undelivered, rejected og expired krever ulike handlinger. Under prepaid er hver automatisk retry en debitlinje, ikke en gratis høflighet. Enig om ordboken før løkken, ellers jager produkt konvertering mens finance betaler andre og tredje forsøk til et dødt nummer.

IOSOR er white-label prepaid: samme DLR-ordforråd i panel, webhook og eksport. En korridor live tillater begrenset retry; in setup åpner ikke «neste gang». Se ikke levert, avvist, utløpt og DLR, latens og failover-rute. Nær USD 1,000+ i måneden går retrydebiteringer per statusbøtte inn i en tettere kommersiell lesing.

Statusordbok før retrylogikk

Før dere skriver retrykode, print terminalstatuser i en tabell som produkt, ops og finance kan peke på. Retry uten ordbok er en løkke som brenner penger. Ved synkende levering: håndbok ved lav SMS-levering.

Status Auto-retry? Hvem signerer
Delivered Nei Ingen
Undelivered / failed Med tak Ops
Rejected Nei (endre payload) Produkt
Expired Nei (juster TTL) Produkt

Failed versus rejected versus expired

Failed / undelivered betyr at plattformen leverte jobben og terminalen ikke bekreftet. Er korridoren sunn, kan en begrenset retry redde en konvertering. Rejected er et nett- eller policyavslag: samme nummer, samme kropp, nesten alltid nytt avslag og ny debitering. Expired er tid: TTL kortere enn korridorlatens, eller en kø før send. Å behandle expired som failed og hamre retries skaper bare flere expired-rader. En OTP utenfor vinduet konverterer ikke lenger — lommeboken betaler likevel.

Retrytak og lommebokvirkning

Sett et tak for automatiske forsøk per melding og skill brukerens videresending fra systemfailover. Hvert forsøk skal passe et correlation ID i ledgeren. «Til levert» uten tak tømmer prepaid på en død korridor. Finance må eksportere destinasjon, status, forsøksnr. og debitering. Nær USD 1,000+ blir en løkke uten eier et kommersielt tema, ikke en sak. Når politikken sier stopp, stopper lommeboken selv om produkt vil én gang til.

Produkt versus finance-eierskap

Produkt eier politikken: hvilke statuser tillater retry, TTL, cooldown for videresending. Finance eier synligheten: debiteres hvert forsøk, stemmer eksporten med webhook. Ops eier korridorsnittet, så et verdenssnitt ikke skjuler en ødelagt rute. Uten samme tabell kan prepaid ikke velge «prøv igjen» mot «slutt å bruke». La ikke support love muntlig refusjon mens ledgeren belaster hvert forsøk.

Røde flagg

  • Bare sent og failed, men automatisk retry
  • Tre identiske slag mot et rejected-payload
  • Expired behandlet som nettfeil
  • Systemfailover og brukervideresending på samme debitlinje
  • «Til levert» uten forsøkstak
  • Retry lovet mens katalogen er in setup
  • Financeeksport uten forsøksnr.

Start med IOSOR

Fyll ordboken: failed versus rejected versus expired. Sett tak på automatisk retry så hvert mislykket DLR ikke åpner et nytt prepaid-trekk. Brukerens send-på-nytt-knapp er atskilt fra systemforsøket. Bevis taket på to live-korridorer ved lavt volum.

IOSOR takeaway

Retry ved mislykket DLR er et forbrukstak, ikke en evig sløyfe.

Gjør: klassifiser sluttstatus, tak forsøk, eksporter brukerens sending på nytt atskilt fra systemforsøket. Ikke: retrie rejected eller expired som om de var forbigående failed.

Var denne guiden nyttig?

Relaterte veiledninger