IOSOR

IOSOR Panduan

Debit penghantaran OTP bukan sesi verify: dua baris ledger, seorang pengguna

Segmen SMS dengan kod dan sesi pengesahan ialah dua peristiwa prepaid pada satu pendaftaran. Jangan campurkan menjadi «satu kos OTP» dan jangan sembunyikan baris kedua daripada kewangan.

Pengguna meminta kod. Produk melihat satu OTP. Dompet prepaid merekod dua baris: debit mesej untuk SMS (segmen, destinasi, laluan DLR) dan debit Verify untuk sesi (penciptaan, tetingkap TTL, semakan). Pasukan yang mencampurkannya menjadi «kos OTP» sama ada mengira dua kali dalam board pack atau menyembunyikan baris kedua hingga akhir bulan. Kedua-duanya bukan kawalan.

IOSOR menjalankan Verify prepaid white-label di samping SMS pada satu ledger. Katalog live ialah saluran benar; in setup bukan sesi percuma. Dekat USD 1,000+ penggunaan bulanan, baris SMS dan sesi Verify menjadi bahan semakan komersial. Tiada langganan platform untuk «mengekalkan Verify tersedia».

Satu sesi pengguna, dua baris prepaid

Perjalanan satu. Wang dua.

  1. Debit penghantaran — SMS (atau fallback suara/e-mel) yang membawa kod: pengekodan, segmen, destinasi, DLR terminal.
  2. Debit sesi Verify — dikeluarkan, menunggu, disemak, tamat tempoh, atau polisi resend.

Debit penghantaran bukan debit sesi verify

Peristiwa Apa yang dompet mesti tunjukkan Kegagalan tipikal jika digabung
Kod SMS dihantar Debit segmen, destinasi, pengekodan «Satu OTP» menyembunyikan multipart UCS-2
DLR terminal Baris SMS sama, status dikemas kini Retry dibil dua kali tanpa sesi
Sesi dicipta Debit Verify, TTL, saluran Sesi kelihatan seperti SMS lain
Check / expire Baris Verify

Bagaimana pasukan mengira dua kali atau menanam baris kedua

  • Board pack menambah belanja SMS OTP plus unit Verify yang sudah merangkumi hantaran itu.
  • Kewangan memulangkan SMS tidak dihantar dan juga membatalkan sesi.
  • Papan pemuka menunjukkan kejayaan sesi sementara SMS masih pending DLR.
  • Verify in setup sementara SMS live — sesi dijanjikan, SMS terus mendebit.

Menyelaraskan SMS, DLR dan percubaan verify

Penyelarasan mingguan, satu koridor:

  • Kira sesi dicipta berbanding percubaan SMS (atau fallback).
  • Padankan DLR terminal dengan terminal sesi (delivered+checked, undelivered+expired, rejected+never checked).
  • Asingkan resend pengguna daripada retry sistem — pemilik berbeza, cooldown berbeza.
  • Terbitkan p95 daripada penciptaan sesi → kod dihantar, bukan «kependaman OTP» global.

Bendera amaran

  • «Yuran OTP» bercampur tanpa split SMS / sesi
  • Verify dibil seperti blast pemasaran
  • SMS dipulangkan tanpa menyentuh baris sesi (atau sebaliknya) tanpa polisi
  • Butang resend mengabaikan cooldown pada salah satu daripada dua laluan
  • Nama jenama hulu dalam ralat yang dilihat pelanggan
  • Verify dijanjikan sementara saluran masih in setup

Mulakan dengan IOSOR

Semak semula webhook konsol anda untuk memastikan caj segmen SMS dan kemas kini laporan penghantaran menghasilkan peristiwa lejar yang berasingan daripada percubaan pengesahan sesi. Konfigurasikan sistem pengebilan anda untuk memetakan semakan sesi dan caj pengangkutan kepada ID transaksi yang berasingan sebelum memuktamadkan baki prabayar.

Inti IOSOR

Artikel ini membuktikan bahawa menggabungkan kos pengangkutan segmen SMS dengan logik pengesahan mengaburkan unit ekonomi sebenar dan mewujudkan ralat penyelarasan merentas laporan lembaga serta log kewangan. Menjejak pendebitan penghantaran secara bebas daripada sesi pengesahan adalah penting untuk keterlihatan margin yang tepat dan operasi pengebilan yang bersih.

Adakah panduan ini membantu?

Panduan berkaitan