IOSOR

IOSOR علم

OTP ڈیلیوری ڈیبٹ verify سیشن نہیں: دو لیجر لائنیں، ایک صارف

کوڈ والا SMS سیگمنٹ اور تصدیقی سیشن ایک رجسٹریشن پر دو prepaid واقعات ہیں۔ انہیں «ایک OTP لاگت» میں نہ ملائیں اور دوسری لائن مالیات سے نہ چھپائیں۔

صارف نے کوڈ مانگا۔ پروڈکٹ نے ایک OTP دیکھا۔ Prepaid والیٹ نے دو لائنیں لکھیں: SMS کے لیے messaging ڈیبٹ (سیگمنٹس، منزل، DLR راستہ) اور سیشن کے لیے Verify ڈیبٹ (تخلیق، TTL ونڈو، چیک)۔ جو ٹیمیں اسے «OTP لاگت» میں ملا دیتی ہیں وہ یا board pack میں دو بار گنتی ہیں یا دوسری لائن مہینے کے آخر تک چھپاتی ہیں۔ دونوں کنٹرول نہیں۔.

IOSOR SMS کے ساتھ white-label prepaid Verify ایک لیجر پر چلاتا ہے۔ کیٹلاگ live حقیقی چینل ہے؛ in setup مفت سیشن نہیں۔ ماہانہ USD 1,000+ کے قریب SMS لائنیں اور Verify سیشن تجارتی جائزے کا مواد بنتی ہیں۔ Verify «دستیاب رکھنے» کی پلیٹ فارم سبسکرپشن نہیں۔.

ایک صارف سیشن، دو prepaid لائنیں

سفر ایک ہے۔ پیسہ دو ہے۔ متعلقہ، کبھی مترادف نہیں:

  1. ڈیلیوری ڈیبٹ — کوڈ لے جانے والا SMS (یا آواز/ای میل fallback): انکوڈنگ، سیگمنٹس، منزل، ٹرمینل DLR۔
  2. Verify سیشن ڈیبٹ — جاری، انتظار، چیک شدہ، میعاد ختم، یا resend پالیسی۔

اگر مالیات صرف SMS دیکھے تو Verify «مفت» لگتا ہے۔ اگر پروڈکٹ صرف Verify دیکھے تو SMS پمپنگ «زیادہ سیشن» لگتی ہے۔ تصویر: بے ترتیبی کے بغیر OTP۔ دونوں والیٹ لائنیں نظر رکھیں۔.

ڈیلیوری ڈیبٹ verify سیشن ڈیبٹ نہیں

واقعہ والیٹ کیا دکھائے ملانے پر عام ناکامی
کوڈ SMS بھیجا سیگمنٹ ڈیبٹ، منزل، انکوڈنگ «ایک OTP» UCS-2 multipart چھپاتا ہے
ٹرمینل DLR وہی SMS لائن، اپڈیٹ سٹیٹس بغیر سیشن retry دو بار
سیشن بنا Verify ڈیبٹ، TTL، چینل سیشن اور SMS لگتا ہے
Check / expire وہی Verify لائن، ٹرمینل وجہ میعاد ختم کوڈ «SMS لاگت» پر
صارف resend نیا SMS ± پالیسی کے مطابق نیا سیشن کولڈاؤن چھوڑا، دوہری جلن

Resend پالیسی: OTP TTL اور دوبارہ بھیجنے کا وقفہ۔ کولڈاؤن جو سیشن روکے مگر پھر بھی SMS چلائے (یا الٹ) — دو لیجر ایسے الگ ہوتے ہیں۔ وائس fallback چینل live ہو تو تیسری رقم کی شکل — SMS لائن پر پوشیدہ اضافہ نہیں۔.

ٹیمیں دو بار کیسے گنتی ہیں یا دوسری لائن دباتی ہیں

  • Board pack SMS OTP خرچ میں وہ Verify یونٹس شامل کرتا ہے جن میں وہ بھیج پہلے سے ہیں۔
  • مالیات undelivered SMS واپس کرتی ہے اور سیشن بھی منسوخ کرتی ہے۔
  • ڈیش بورڈ سیشن کامیابی دکھاتا ہے جب SMS ابھی pending DLR ہے۔
  • Verify in setup، SMS live — سیشن وعدہ، SMS ڈیبٹ جاری۔

ایک انسان کے دو ڈیبٹ نہ سمجھانے والا prepaid والیٹ رسید پرنٹر ہے۔ مشترکہ correlation id سے دونوں لائنیں برآمد کریں۔ روکنے کے قواعد: پری پیڈ خرچ کنٹرول۔.

SMS، DLR اور verify کوشش کا میل

ہفتہ وار میل، ایک کوریڈور:

  • بنائے گئے سیشن گنیں SMS (یا fallback) کوششوں کے مقابل۔
  • ٹرمینل DLR کو سیشن ٹرمینل سے ملائیں (delivered+checked، undelivered+expired، rejected+never checked)۔
  • صارف شروع resend الگ کریں system retry سے — الگ مالک، الگ کولڈاؤن۔
  • سیشن تخلیق → پہنچا کوڈ کا p95 شائع کریں، عالمی «OTP تاخیر» نہیں۔

اگر کوششیں ≫ سیشن، آپ بلاسٹ کر رہے ہیں۔ اگر سیشن ≫ کوششیں، بغیر چینل Verify بل کر رہے ہیں۔ دونوں تجارتی جائزے میں گرتے ہیں۔.

سرخ جھنڈے

  • SMS/سیشن تقسیم کے بغیر ملا جلا «OTP فیس»
  • Verify مارکیٹنگ بلاسٹ جیسا بل
  • پالیسی کے بغیر SMS واپسی میں سیشن لائن نہ چھونا (یا الٹ)
  • دو راستوں میں سے ایک پر کولڈاؤن نظرانداز کرنے والا resend بٹن
  • کلائنٹ غلطیوں میں اپ اسٹریم برانڈ نام
  • چینل in setup ہو تو Verify کا وعدہ

IOSOR کے ساتھ شروع کریں

اپنے کنسول کے ویب ہکس کا آڈٹ کریں تاکہ یہ یقینی بنایا جا سکے کہ ایس ایم ایس کے حصے کے چارجز اور ڈی ایل آر کی تازہ کارییں سیشن کی تصدیق کی کوششوں سے الگ الگ لیجر ایونٹس تخلیق کریں۔ اپنے بلنگ گیٹ کو اس طرح ترتیب دیں کہ پری پیڈ بیلنس کو حتمی شکل دینے سے پہلے سیشن کے چیکس اور ٹرانسپورٹ کے چارجز کو الگ الگ ٹرانزیکشن آئی ڈیز پر میپ کیا جائے۔ کسی بھی ایسے اکاؤنٹ پر فوری طور پر مصالحتی ہولڈ قائم کریں جہاں دوبارہ بھیجنے پر فعال سیشن کی حالت کو اپ ڈیٹ کیے بغیر ٹرانسپورٹ کے ڈیبٹ درج ہو جائیں۔

IOSOR خلاصہ

اس مقالے نے ثابت کیا کہ ایس ایم ایس کے ٹرانسپورٹ کے اخراجات کو تصدیق کی منطق کے ساتھ ملانے سے حقیقی یونٹ اکنامکس پوشیدہ ہو جاتے ہیں اور فنانس لاگز میں مصالحتی غلطیاں پیدا ہوتی ہیں۔

کیا یہ گائیڈ مددگار تھی؟

متعلقہ رہنما