IOSOR Wiedza

Queued a Sent: Jedna ścieżka wiadomości w IOSOR

Dowiedz się, jak finanse i produkt dzielą zunifikowany automat stanów dla etapów cyklu życia SMS i OTP, balansując blokady prepaid i statusy DLR w IOSOR.

Queued a Sent: Jedna ścieżka wiadomości w IOSOR.

Jednolity automat stanów dla 'Queued' i 'Sent'

Gdy żądanie API dociera do platformy w celu przesłania ładunku SMS lub OTP do miejsca docelowego E.164, zespoły produktu i finansów muszą odwoływać się do dokładnie tego samego stanu cyklu życia. W tradycyjnych konfiguracjach white-label produkt traktuje 'queued' jako stan inżynieryjny, podczas gdy finanse czekają na zestawienia na koniec miesiąca. IOSOR eliminuje ten brak spójności, obsługując pojedynczy, deterministyczny automat stanów.

Rezerwa finansowa w kolejce a ostateczne rozliczenie

Po wejściu w stan queued silnik wykonuje natychmiastową weryfikację salda. Aby zachować wypłacalność platformy, konta muszą utrzymywać dolny próg prepaid na poziomie USD 20, zanim ruch wychodzący trafi do rurociągu przetwarzania. Podczas przebywania w kolejce przewidywany koszt segmentu wychodzącego SMS zostaje zablokowany. Jeśli wiadomość przejdzie ze stanu queued do sent, blokada ta przekształca się w ostateczne obciążenie salda.

Wyzwalacze przejścia: od przyjęcia API do przekazania

Granica między queued a sent jest rygorystyczna. Queued oznacza, że ładunek został zweryfikowany, stawka została obliczona i przydzielono go do kolejki wysyłkowej z zarezerwowanymi środkami. Sent wskazuje, że bramka brzegowa przesłała jednostkę PDU do interfejsu sieciowego i otrzymała pośrednie potwierdzenie. W tej milisekundzie system aktualizuje stan z queued na sent i wysyła asynchroniczne zdarzenie webhooka.

Uzgadnianie audytów księgi głównej z raportami doręczenia

Audyty finansowe często ścierają się z dziennikami inżynieryjnymi, gdy występują opóźnienia DLR. W IOSOR stan sent jest punktem księgowym ostatecznego zatwierdzenia obciążenia. Statusy DLR, takie jak DELIVERED lub UNDELIVERED, aktualizują wskaźniki operacyjne bez zmiany początkowej księgi transakcji. Jeśli odebrane zostanie przychodzące polecenie STOP, kolejne próby dla tego adresu E.164 są odrzucane na granicy API ze statusem Verify OK, zanim dojdzie do blokad finansowych.

Podręcznik operacyjny i powiązana architektura

Aby utrzymać spójność między inżynierią a operacjami finansowymi, zapoznaj się z poniższymi przewodnikami dotyczącymi obsługi kolejek, idempotentności webhooków oraz mechaniki portfela:

Zacznij z IOSOR

Otwórz konsolę IOSOR i przejdź do konfiguracji maszyny stanów cyklu życia, aby dostosować webhooki wychowujące do pojedynczego potoku kolejka-wysłane. Skonfiguruj integrację księgową tak, aby uznawała stan wysłania za autorytatywny punkt ostatecznego zatwierdzenia obciążenia, zamiast czekać na dalsze raporty doręczenia od operatora. Zweryfikuj konfigurację, uruchomiając testową wysyłkę i audytując identyfikator zunifikowanego stanu transakcji w webhookach technicznych oraz dziennikach finansowych.

Podsumowanie IOSOR

Ten przewodnik udowodnił, że zjednoczenie telemetrii produktu i rozliczeń wokół pojedynczej maszyny stanów usuwa tarcie operacyjne między zespołem technicznym a finansowym. Rezerwowanie środków w momencie wejścia do kolejki i zatwierdzanie ostatecznych obciążeń, gdy brama wyemituje zdarzenie wysłania, tworzy deterministyczny model księgowy, na który nie wpływają opóźnione lub brakujące potwierdzenia doręczenia.

Czy ten przewodnik był pomocny?

Powiązane przewodniki