IOSOR

IOSOR Kunnskap

Verify-sesjonskorrelasjon for finance-eksport: to debet, én ledgerhistorie

Verify oppretter separate debet fra SMS-levering. Finance-eksport trenger sesjonskorrelasjons-ID-er og TTL-/omsend-linjer som matcher leveringen.

Brukeren ba om en kode. Produkt så ett OTP. Lommeboken kan bokføre to linjer: SMS-leveringsdebet som bar koden og Verify-sesjonsdebet (opprett, TTL, sjekk). Team som smelter det til «OTP-kostnad» teller enten dobbelt i board pack eller gjemmer den andre linjen til månedsslutt. Ingen er kontroll. To debet trenger en sesjonshistorie så finance kan eksportere.

IOSOR kjører Verify ved siden av SMS på ett white-label prepaid-ledger. Katalog live er en ekte kanal; in setup er ingen gratissesjon. Rundt USD 1,000+ i måneden blir SMS-linjer og Verify-sesjonslinjer kommersiell gjennomgang. Oppdeling av de to debet: OTP-leveringsdebitering versus verify-økt.

Leveringsdebet vs verify-debet

Reisen er én. Pengene er to. Beslektet, aldri alias. Leveringsdebet dekker kanalen som bar koden: encoding, segmenter, destinasjon, terminalt DLR. Verify-sesjonsdebet dekker utstedelse, TTL-vindu, sjekk, utløp eller omsend-policy. Ser finance bare SMS, ser Verify «gratis» ut. Ser produkt bare Verify, ser SMS-pumping «flere sesjoner» ut. Begge linjene skal være synlige med samme correlation id.

Sesjons-ID-felt finance må eksportere

En finance-eksport skal kunne rekonstruere per sesjon: verify_session_id, relatert message_id eller leverings-id, destinasjon, kanal, TTL, terminal årsak, debitert beløp og tidsstempel per linje. En uke uten correlation id er en kvitteringsbunke, ikke et ledger. Hvis produktdashboardet viser sesjonssuksess mens SMS fortsatt er pending DLR, må eksporten matche begge sider, ikke to separate «ferdig».

Omsend-TTL og dupliserte linjer

Omsend-policyen avgjør om dupliserte linjer dukker opp. En cooldown som blokkerer sesjonen men likevel fyrer SMS (eller omvendt) setter to ledgere i strid. TTL-utløp skal lukke samme Verify-linje, ikke åpne en «spøkelsessesjon». Brukeromsend og systemretry er ulike eiere og ulike cooldowns.

Avstemming før skala

Før skala, en uke avstemming: opprettede sesjoner vs SMS- (eller fallback-) forsøk; terminalt DLR vs sesjonsterminal (levert+sjekket, ikke levert+utløpt, avvist+aldri sjekket); brukeromsend skilt fra systemretry. Forsøk >> sesjoner betyr blast. Sesjoner >> forsøk betyr Verify uten kanal faktureres. Begge faller i kommersiell gjennomgang. Bevis avslutning på en live-korridor før intensitet nær USD 1,000+.

Røde flagg

  • Et blandet «OTP-gebyr» uten SMS-vs-sesjonssplit
  • Verify fakturert som et markedsblast
  • SMS refundert uten å røre sesjonslinjen (eller omvendt) uten policy
  • Omsend-knapp som ignorerer cooldown på én av de to stiene
  • Klientfeil som navngir oppstrømsmerker
  • Verify lovet mens kanalen er in setup
  • Ukeeksport uten session correlation id

Start med IOSOR

Eksporter en ukentlig CSV-fil fra verifiseringspanelet og kontrollere at hver verify_session_id knyttes direkte til de tilsvarende meldings-id-ene for levering. Konfigurer webhook-loggføring slik at den lagrer terminale årsaker for økten sammen med leveringskvitteringer fra operatøren før produksjonsoppdateringer rulles ut.

IOSOR-lærdom

Å spore verifiseringskostnader krever at øktens livssyklus holdes atskilt fra de underliggende meldingsdebetene. Når økonomiavdelingen betrakter autentiseringsgebyrer gjennom én samlet leveringspott uten øktkorrelasjon, vil spøkelsesbelastninger og uregistrerte ombestillingskostnader ødelegge regnskapet.

Var denne guiden nyttig?

Relaterte veiledninger