Polityka retry DLR przy failed w prepaid: kiedy ponawiać, a kiedy przestać wydawać

Zgłoszenie mówi «nie doszło» i ktoś wali retry, aż prepaidowy portfel jest pusty. Niepowodzenie to nie status. undelivered, rejected i expired wymagają innych czynów. W prepaid każde automatyczne retry to wiersz debetu, nie darmowa uprzejmość. Uzgodnijcie słownik przed pętlą, albo produkt goni konwersję, a finanse płacą drugą i trzecią próbę na martwy numer.

IOSOR to white-label prepaid: ten sam słownik DLR w panelu, webhooku i eksporcie. Korytarz live dopuszcza retry z limitem; in setup nie otwiera się «za następnym razem». Zobacz niedostarczone, odrzucone, wygasłe i DLR, opóźnienie i failover. Przy ok. USD 1,000+ miesięcznie debety retry wg kubełka statusu wchodzą w ciaśniejszy odczyt handlowy.

Słownik statusów przed logiką retry

Zanim napiszecie kod retry, wydrukujcie statusy końcowe w tabeli, na którą produkt, ops i finanse mogą wskazać. Retry bez słownika to pętla paląca pieniądze. Przy spadku dostarczalności: playbook niskiej dostarczalności SMS.

Failed kontra rejected kontra expired

Failed / undelivered znaczy: platforma oddała zadanie, terminal nie potwierdził. Jeśli korytarz jest zdrowy, retry z limitem może uratować konwersję. Rejected to odmowa sieci lub polityki: ten sam numer, ta sama treść prawie zawsze wraca jako odmowa i kolejny debet. Expired to czas: TTL krótszy niż latencja korytarza albo kolejka przed wysyłką. Traktowanie expired jak failed i walenie retry tylko mnoży wiersze expired. OTP poza oknem już nie konwertuje — portfel i tak płaci.

Limity retry i wpływ na portfel

Ustawcie limit automatycznych prób na wiadomość i oddzielcie resend użytkownika od failover systemu. Każda próba musi zgadzać się z correlation ID w ledgerze. «Aż dotrze» bez limitu opróżnia prepaid na martwym korytarzu. Finanse muszą eksportować destynację, status, nr próby i debet. Przy USD 1,000+ pętla bez właściciela przestaje być zgłoszeniem i staje się tematem handlowym. Gdy polityka mówi stop, portfel staje, nawet jeśli produkt chce jeszcze raz.

Własność produktu kontra finanse

Produkt posiada politykę: które statusy pozwalają na retry, TTL, cooldown resend. Finanse posiadają widoczność: czy każda próba debitowuje, czy eksport zgadza się z webhookiem. Ops posiada cięcie korytarza, by średnia światowa nie ukryła zepsutej trasy. Bez tej samej tabeli prepaid nie rozstrzygnie «ponów» kontra «przestań wydawać». Niech support nie obiecuje zwrotu słowem, podczas gdy ledger obciąża każdą próbę.

Czerwone flagi

• Tylko sent i failed, a jest auto-retry
• Trzy identyczne ciosy w payload rejected
• Expired traktowane jak awaria sieci
• Failover systemu i resend użytkownika w tym samym wierszu debetu
• «Aż dotrze» bez limitu prób
• Retry obiecane przy katalogu in setup
• Eksport finansów bez nr próby

Start z IOSOR

Wypełnijcie słownik: failed versus rejected versus expired. Nałóżcie sufit na automatyczny retry, by każdy nieudany DLR nie otwierał nowego obciążenia prepaid. Przycisk ponownego wysłania użytkownika jest osobny od próby systemu. Udowodnijcie sufit na dwóch korytarzach live przy niskim wolumenie.

Podsumowanie IOSOR

Retry nieudanego DLR to sufit wydatku, nie nieskończona pętla.

Róbcie: klasyfikujcie status końcowy, sufitujcie próby, eksportujcie ponowne wysłanie użytkownika osobno od próby systemu. Nie róbcie: powtarzać rejected lub expired jakby to był przejściowy failed.