IOSOR

IOSOR Wiedza

Undelivered vs rejected vs expired: słownik statusów dla produktu i billing

Przestańcie kłócić się o screeny: wyrównajcie produkt, support i prepaid billing wokół undelivered, rejected i expired — oraz działań, które każdy status naprawdę zezwala.

Gdy spada dostarczalność, produkt obwinia pipe, support wkleja screeny, a finance pyta, czemu ruszył się prepaid wallet. Duża część żaru to porażka słownika. Undelivered, rejected i expired nie są synonimami — wrzucanie ich do jednego wiadra „failed” wymyśla złe retry, złe refundy i złą severity incydentu.

IOSOR chce, by zespoły B2B prowadziły messaging jako white-label prepaid: doładuj raz, czytaj trwałe eventy statusu, trzymaj brand-safe język błędów. Ten słownik to kontrakt operacyjny między UX produktu, ops i ledgerem.

Dlaczego słowa statusu powodują więcej incydentów niż awarie

Klasa Przykłady Produkt powinien…
Intermediate queued, submitted, sent Pokazać postęp; nie celebrować sukcesu na handsecie
Terminal success delivered Odblokować kolejny UX; zatrzymać auto-resend
Terminal fail undelivered, rejected, expired (jeśli terminal) Wybrać licencjonowaną akcję; nigdy infinite retry

Jeśli UI zwija wszystko w czerwony X, o 02:00 nikt nie działa poprawnie.

Słownik statusów: definicje, na które produkt i billing mogą się zgodzić

Undelivered zwykle oznacza, że job wszedł w live messaging path, ale sygnał downstream mówi, że handset nie dostał sukcesu. Typowe sterowniki: handset wyłączony, pełna skrzynka, tymczasowy congestion korytarza, nieosiągalny abonent.

Licencjonowane akcje:

  1. Bounded auto-retry tylko jeśli polityka i evidence korytarza to wspierają
  2. Widoczne dla użytkownika „spróbuj później” bez implikowania fraud
  3. Wallet według opublikowanych reguł debit/refund — nie wymyślać cichych refundów w wątku czatu

Nie traktujcie każdego undelivered jako „platforma leży”. Kroić po korytarzu zanim pagerujecie świat.

Undelivered vs rejected: różne klasy awarii, różne poprawki

Rejected to fail polityki lub admission: filtr treści, tożsamość nadawcy, compliance gate, malformed destination, niewystarczające środki, albo catalog-not-live dla tej capability. Job nigdy nie zasłużył na uczciwą szansę dostawy na handset.

Licencjonowane akcje:

  • Naprawić bramkę (szablon, rejestracja, saldo, uczciwość katalogu)
  • Pokazać operatorom usable, brand-safe reason code
  • Nigdy nie retryować identycznego payloadu licząc na inny wszechświat

Burze rejected to najpierw problemy compliance i katalogu — nie „więcej throughput”.

Expired: TTL, kolejki i okna timing OTP

Expired oznacza, że okno ważności zamknęło się przed terminal success. Częste w OTP (TTL), jobach w kolejce past SLA lub oknach ważności sieci. Produkt musi oddzielić user expired (użytkownik utknął) od network expired (pipe nie dostarczył na czas).

Licencjonowane akcje:

  • Oferować kontrolowany resend z cooldown
  • Unieważnić poprzedni kod w flow Verify
  • Jasno atrybuować spend, gdy nowa próba znów debitartuje

Expired OTP z auto-resend bez cooldown to wzmacniacz fraud i spend.

Czerwone flagi

  • Istnieje tylko „failed”
  • Screeny jako jedyny system statusu
  • Burze auto-retry na rejected
  • Ruchy wallet bez śladu statusu
  • Obcy brand text w client-facing fail reasons

Zacznij z IOSOR

Przypisz wywołania zwrotne statusu w konsoli IOSOR, aby integracja rozliczeniowa wyraźnie oddzielała wczesne odrzucenia od późniejszych zdarzeń niedoręczenia i wygaśnięć kolejki. Przejrzyj aktywne webhooki, aby kody statusów końcowych DLR przekazywały jednoznaczne klasy błędów do wewnętrznej księgi zamiast ogólnego stanu awarii.

Podsumowanie IOSOR

Ten przewodnik pokazał, że niejednoznaczność statusów to problem projektowania produktu i księgowości, a nie zwykła awaria sieci.

Czy ten przewodnik był pomocny?

Powiązane przewodniki