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 सारांश

या लेखामुळे हे सिद्ध झाले की एसएमएस सेगमेंट वाहतूक खर्च पडताळणी लॉजिकमध्ये मिसळल्यामुळे खरी युनिट अर्थव्यवस्था अस्पष्ट होते आणि सर्व बोर्ड पॅक आणि फायनान्स लॉगमधील पुनर्रचना त्रुटी निर्माण होतात.

हा मार्गदर्शक उपयुक्त होता का?

संबंधित मार्गदर्शक