IOSOR

IOSOR Kunskap

OTP-leveransdebet är inte verify-sessionen: två ledger-rader, en användare

Ett SMS-segment med koden och en verifieringssession är två prepaid-händelser på samma registrering. Blanda dem inte till «en OTP-kostnad» och göm inte den andra raden för ekonomi.

Användaren bad om en kod. Produkten såg ett OTP. Prepaid-plånboken bokade två rader: meddelandedebet för SMS (segment, destination, DLR-väg) och Verify-debet för sessionen (skapande, TTL-fönster, kontroll). Team som blandar till «OTP-kostnad» antingen dubbelräknar i board pack eller gömmer den andra raden till månadsslut. Ingen av dem är kontroll.

IOSOR kör white-label prepaid Verify bredvid SMS på ett ledger. Katalog live är en riktig kanal; in setup är ingen gratis session. Nära USD 1,000+ månadsanvändning blir SMS-rader och Verify-sessionsrader kommersiellt granskningsmaterial. Ingen plattformsprenumeration för att «hålla Verify tillgängligt».

En användarsession, två prepaid-rader

Resan är en. Pengarna är två.

  1. Leveransdebet — SMS (eller röst/e-post-fallback) som bar koden: kodning, segment, destination, terminal DLR.
  2. Verify-sessionsdebet — utfärdad, väntade, kontrollerad, utgången eller resend-policy.

Leveransdebet är inte verify-sessionsdebet

Händelse Vad plånboken ska visa Typiskt fel vid sammanslagning
Kod-SMS skickat Segmentdebet, destination, kodning «Ett OTP» döljer UCS-2-multipart
Terminal DLR Samma SMS-rad, uppdaterad status Retry debiterad två gånger utan session
Session skapad Verify-debet, TTL, kanal Sessionen ser ut som ett till SMS
Check / expire Samma Verify-rad, terminal

Hur team dubbelräknar eller gräver ner den andra raden

  • Board pack lägger SMS OTP-spend plus Verify-enheter som redan inkluderar de sändningarna.
  • Ekonomi återbetalar odelevererat SMS och annullerar också sessionen.
  • Dashboards visar sessionssuccé medan SMS fortfarande är pending DLR.
  • Verify in setup medan SMS är live — sessioner lovade, SMS debiterar vidare.

Stämma av SMS, DLR och verify-försök

Veckovis avstämning, en korridor:

  • Räkna skapade sessioner mot SMS- (eller fallback-) försök.
  • Para terminal DLR med sessionsterminal (delivered+checked, undelivered+expired, rejected+never checked).
  • Separera användarinitierad resend från system-retry — olika ägare, olika cooldown.
  • Publicera p95 från sessionsskapande → levererad kod, inte global «OTP-latens».

Röda flaggor

  • En blandad «OTP-avgift» utan SMS-/sessionssplit
  • Verify fakturerad som marknadsblast
  • SMS återbetalat utan att röra sessionsraden (eller tvärtom) utan policy
  • Resend-knapp som ignorerar cooldown på en av två vägar
  • Upstream-varumärken i kundsynliga fel
  • Verify utlovad medan kanalen är in setup

Börja med IOSOR

Granska dina konsolwebbhookar för att säkerställa att SMS-segmentkostnader och leveransrapporter genererar skilda händelser i huvudboken från sessionsverifieringsförsök. Konfigurera din faktureringsgrind för att mappa sessionskontroller och transportavgifter till separata transaktions-ID:n innan förbetalda saldon slutgörs.

IOSOR sammanfattning

Den här artikeln visade att en sammanslagning av transportkostnader för SMS-segment med verifieringslogik döljer den sanna enhetsekonomin och skapar avstämningfel i rapporter och ekonomiloggarna. Att spåra leveransdebiteringar oberoende av verifieringssessioner är avgörande för korrekt marginalsynlighet och ren faktureringshantering.

Var den här guiden till hjälp?

Relaterade guider