IOSOR

IOSOR Wissen

DLR-Retry bei Failed unter Prepaid: wann erneut versuchen und wann aufhören zu zahlen

Failed, rejected und expired sind nicht dasselbe Wort. Jeder Prepaid-Retry ist ein Debit. Teilen Sie das Statuswörterbuch vor der Kappe, sonst verbrennt das Wallet in einer Sackgasse.

Das Ticket sagt «fehlgeschlagen» und jemand hämmert Retry, bis das Prepaid-Wallet leer ist. Fehlgeschlagen ist kein Status. undelivered, rejected und expired verlangen andere Handlungen. Unter Prepaid ist jeder automatische Retry eine Debit-Zeile, kein kostenloser Gefallen. Einigen Sie das Wörterbuch vor der Schleife, sonst jagt Produkt Conversion, während Finance den zweiten und dritten Versuch an eine tote Nummer zahlt.

IOSOR ist white-label prepaid: dasselbe DLR-Vokabular in Dashboard, Webhook und Export. Ein Korridor live erlaubt begrenzten Retry; in setup öffnet sich nicht «beim nächsten Mal». Siehe unzugestellt, abgelehnt, abgelaufen und DLR, Latenz und Failover. Nahe USD 1,000+ monatlich gehen Retry-Debits nach Status-Eimer in eine engere kommerzielle Lesart.

Statuswörterbuch vor der Retry-Logik

Bevor Sie Retry-Code schreiben, drucken Sie Terminal-Status in eine Tabelle, auf die Produkt, Ops und Finance zeigen können. Retry ohne Wörterbuch ist eine Schleife, die Geld verbrennt. Bei sinkender Zustellung: Handbuch bei sinkender SMS-Zustellung.

Status Auto-Retry? Wer zeichnet
Delivered Nein Niemand
Undelivered / failed Mit Kappe Ops
Rejected Nein (Payload ändern) Produkt
Expired Nein (TTL justieren) Produkt

Failed gegen rejected gegen expired

Failed / undelivered heißt: die Plattform hat den Job übergeben, das Terminal hat nicht bestätigt. Ist der Korridor gesund, kann ein gekappter Retry eine Conversion retten. Rejected ist eine Netz- oder Policy-Ablehnung: dieselbe Nummer, derselbe Body werden fast immer erneut abgelehnt und erneut debited. Expired ist Zeit: TTL kürzer als Korridor-Latenz, oder eine Queue vor dem Send. Expired wie Failed zu behandeln und Retries zu hämmern erzeugt nur mehr Expired-Zeilen. Ein OTP außerhalb des Fensters konvertiert nicht mehr — das Wallet zahlt trotzdem.

Retry-Kappen und Wallet-Wirkung

Setzen Sie eine Kappe automatischer Versuche pro Nachricht und trennen Sie User-Resend von System-Failover. Jeder Versuch muss zu einer Correlation-ID im Ledger passen. «Bis zugestellt» ohne Kappe leert Prepaid auf einem toten Korridor. Finance muss Destination, Status, Versuchsnr. und Debit exportieren. Nahe USD 1,000+ wird eine herrenlose Schleife vom Ticket zum kommerziellen Thema. Sagt die Policy Stop, stoppt das Wallet, auch wenn Produkt noch einmal will.

Produkt- gegen Finance-Eigentum

Produkt besitzt die Policy: welche Status Retry erlauben, TTL, Resend-Cooldown. Finance besitzt Sichtbarkeit: debitet jeder Versuch, passt der Export zum Webhook. Ops besitzt den Korridor-Schnitt, damit ein Weltmittel keine kaputte Route versteckt. Ohne dieselbe Tabelle kann Prepaid nicht «nochmal» gegen «aufhören zu zahlen» entscheiden. Lassen Sie Support keine mündlichen Erstattungen versprechen, während das Ledger jeden Versuch belastet.

Rote Flaggen

  • Nur sent und failed, aber automatischer Retry
  • Drei identische Schläge auf ein rejected-Payload
  • Expired als Netzstörung behandelt
  • System-Failover und User-Resend in derselben Debit-Zeile
  • «Bis zugestellt» ohne Versuchskappe
  • Retry versprochen, Katalog noch in setup
  • Finance-Export ohne Versuchsnr.

Starten mit IOSOR

Füllen Sie das Wörterbuch: failed gegen rejected gegen expired. Setzen Sie eine Decke auf Auto-Retry, damit jedes fehlgeschlagene DLR kein neues Prepaid-Debit öffnet. Der Nutzer-Resend ist ein anderer Knopf als der Systemversuch. Beweisen Sie die Decke auf zwei Live-Korridoren bei geringem Volumen.

IOSOR Fazit

Retry bei failed DLR ist eine Ausgabendecke, keine Endlosschleife.

War dieser Leitfaden hilfreich?

Verwandte Leitfäden