IOSOR

IOSOR Wiedza

Wysyłka końcowa nadal obciąża jedną księgę prepaid

Embedded Send nadal obciąża portfel prepaid ISV. Nie twórz drugiej księgi, której produkt nie finansuje — blokady, ponowienia i idempotencja pozostają rzetelne.

Wysyłanie wiadomości w modelu embedded wydaje się bezpłatne dla użytkownika końcowego: klika przycisk Wyślij w interfejsie SaaS i widzi zielone potwierdzenie. Pod spodem każda udana wysyłka nadal obciąża jedną księgę prepaid należącą do ISV. Nie pojawia się żaden drugi portfel tylko dlatego, że produkt wbudował API. Jeśli ISV nie sfinansuje blokady środków, wysyłka musi zakończyć się uczciwym błędem produktu — a nie fałszywym stanem doręczenia.

Fikcyjna księgowość to główny tryb awarii: licznik kredytów w aplikacji nieposiadający pokrycia w portfelu IOSOR, zwroty w SaaS podczas gdy księga prepaid płonie, lub ponowienia bez idempotencji podwójnie obciążające jeden kod OTP. Embed ukrywa konsolę; ISV pozostaje podmiotem finansującym.

Linia dokumentacji architektury: wysyłka użytkownika końcowego ≡ obciążenie prepaid ISV. Każdy przegląd projektu zaczyna się od tej zasady.

Jedna księga, nawet gdy interfejs pokazuje kredyty produktowe

Pakiety wiadomości sprzedawane najemcom stanowią komercyjną warstwę ISV. Muszą one odpowiadać blokadom i obciążeniom prepaid na pojedynczym portfelu IOSOR finansowanym przez ISV. Saldo najemcy, które nigdy nie uzgadnia się z wierszami księgi, to bomba zegarowa dla działu wsparcia.

Blokady i idempotencja nadal obowiązują na ścieżkach embed

Wysyłka po stronie serwera musi używać kluczy idempotencji dla wiadomości OTP i transakcyjnych SMS. Podwójne kliknięcie w interfejsie SaaS nie może powodować dwóch obciążeń dla jednej akcji użytkownika. Ponowienia po przekroczeniu limitu czasu podążają za tym samym kluczem aż do ostatecznego statusu DLR lub zamapowanego błędu.

Mapuj błędy produktu na prawdę w księdze

Sygnał UI SaaS Prawda w księdze Dozwolony następny krok
Wysłano / doręczono Obciążenie + ścieżka DLR istnieje Pokaż ID potwierdzenia
W kolejce Blokada otwarta lub zgłoszenie przyjęte Odpytuj o status
Błąd / wstrzymano Blokada odrzucona lub bl.

Przekazania kanałów pozostają w tym samym portfelu

Jeśli produkt dodaje później e-mail lub połączenia głosowe obok SMS, wydatki nadal trafiają do tej samej księgi prepaid, chyba że przeprowadzisz przekazanie do drugiego kanału za zgodą działu finansowego. Embed nie tworzy darmowego kanału bocznego. Przeczytaj o sąsiedztwie portfela przed włączeniem kolejnego kafelka Live w ustawieniach SaaS.

Powiązane ścieżki operacyjne

Zacznij z IOSOR

Otwórz konsolę IOSOR i bezpośrednio powiąż system kredytów swojego najemcy z głównym rejestrem portfela przedpłaconego. Upewnij się, że każde żądanie osadzenia po stronie serwera przekazuje deterministyczny klucz idempotencji przed zablokowaniem środków w portfelu głównym. Skonfiguruj punkt końcowy webhooka do przetwarzania przychodzących raportów doręczeń, aby otwarte blokady mogły zostać prawidłowo rozliczone w postaci ostatecznych obciążeń lub zwolnień w rejestrze.

Podsumowanie IOSOR

Interfejs SaaS osadzony w aplikacji może prezentować użytkownikom końcowym niestandardowe kredyty na wiadomości, jednak każda faktyczna wysyłka wiąże się z tym samym, pojedynczym portfelem przedpłaconym finansowanym przez dostawcę. Ponowne próby, rozszerzenia kanałów i sygnały statusu użytkownika muszą być uzgadniane bezpośrednio z blokadami w portfelu, a nie z abstrakcjami interfejsu bez pokrycia.

Zapewnij rygorystyczne klucze idempotencji po stronie serwera i mapuj każdy stan interfejsu użytkownika najemcy na prawdziwe odpowiedzi DLR z rejestru. Nie twórz niepotwierdzonych portfeli wtórnych ani nie pozwalaj na ponawianie prób wysyłki z interfejsu bez konkretnych blokad w rejestrze.

Czy ten przewodnik był pomocny?

Powiązane przewodniki