IOSOR

IOSOR Wiedza

Korelacja sesji Verify do eksportu finansów: dwa debety, jedna historia ledgera

Verify tworzy osobne debety od dostawy SMS. Eksporty finansów potrzebują ID korelacji sesji i wierszy TTL/ponownego wysłania wyrównanych z dostawą.

Użytkownik poprosił o kod. Produkt zobaczył jeden OTP. Portfel może zaksięgować dwa wiersze: debet dostawy SMS, który niósł kod, i debet sesji Verify (utwórz, TTL, sprawdź). Zespoły, które topią to w «koszt OTP», albo liczą podwójnie w board pack, albo chowają drugi wiersz do końca miesiąca. Żadne nie jest kontrolą. Dwa debety potrzebują historii sesji, żeby finanse mogły eksportować.

IOSOR prowadzi Verify obok SMS na jednym white-label prepaid ledgerze. Katalog live to prawdziwy kanał; in setup to nie darmowa sesja. Koło USD 1,000+ miesięcznie wiersze SMS i sesji Verify wchodzą w przegląd komercyjny. Rozbicie dwóch debetów: debet dostawy OTP kontra sesja verify.

Debet dostawy kontra debet verify

Podróż jest jedna. Pieniądze są dwa. Powiązane, nigdy aliasy. Debet dostawy pokrywa kanał, który niósł kod: encoding, segmenty, destynacja, terminalne DLR. Debet sesji Verify pokrywa wydanie, okno TTL, sprawdzenie, wygaśnięcie lub politykę ponownego wysłania. Jeśli finanse widzą tylko SMS, Verify wygląda «za darmo». Jeśli produkt widzi tylko Verify, pompowanie SMS wygląda jak «więcej sesji».

Pola ID sesji, które finanse muszą eksportować

Eksport finansów musi umieć odtworzyć sesję: verify_session_id, powiązane message_id lub id dostawy, destynacja, kanał, TTL, powód terminalny, kwota debetu i znacznik czasu na wiersz. Tydzień bez correlation id to stos paragonów, nie ledger. Jeśli dashboard produktu pokazuje sukces sesji, a SMS wciąż pending DLR, eksport musi zgrać obie strony, nie dwa osobne «gotowe».

TTL ponownego wysłania i zdublowane wiersze

Polityka ponownego wysłania decyduje, czy pojawią się zdublowane wiersze. Cooldown, który blokuje sesję, ale i tak strzela SMS (lub odwrotnie), kłóci dwa ledgery. Wygaśnięcie TTL ma zamknąć ten sam wiersz Verify, nie otwierać «sesji-ducha». Ponowne wysłanie użytkownika i retry systemu to różni właściciele i różne cooldowny.

Uzgodnienie przed skalą

Przed skalą tydzień uzgodnienia: utworzone sesje vs próby SMS (lub fallback); terminalne DLR vs terminal sesji (dostarczone+sprawdzone, niedostarczone+wygasłe, odrzucone+nigdy niesprawdzone); ponowne wysłanie użytkownika oddzielone od retry systemu. Próby >> sesje znaczy blast. Sesje >> próby znaczy fakturowanie Verify bez kanału. Oba odpadają na przeglądzie komercyjnym.

Czerwone flagi

  • Mieszana «opłata OTP» bez splitu SMS vs sesja
  • Verify fakturowany jak blast marketingowy
  • SMS zwrócony bez ruszania wiersza sesji (lub odwrotnie) bez polityki
  • Przycisk ponownego wysłania ignorujący cooldown na jednej z dwóch ścieżek
  • Błędy klienta nazywające marki upstream
  • Verify obiecany, gdy kanał jest in setup
  • Tygodniowy eksport bez session correlation id

Zacznij z IOSOR

Wyeksportuj przykładowy cotygodniowy plik CSV z panelu weryfikacji i sprawdź, czy każdy identyfikator verify_session_id bezpośrednio odpowiada odpowiednim rekordom komunikatów doręczenia message_id. Skonfiguruj rejestrowanie webhooków, aby zapisywać przyczyny zakończenia sesji wraz z potwierdzeniami doręczenia od operatora przed wdrożeniem aktualizacji produkcyjnych.

Podsumowanie IOSOR

Śledzenie kosztów weryfikacji wymaga oddzielenia cyklu życia sesji od leżących u ich podstaw obciążeń za doręczenie wiadomości. Gdy dział finansowy postrzega opłaty za uwierzytelnianie przez jeden połączony koszyk doręczeń bez korelacji sesji, fikcyjne obciążenia i nieprzypisane koszty ponownych wysyłek zakłócają księgi rachunkowe.

Czy ten przewodnik był pomocny?

Powiązane przewodniki