IOSOR

IOSOR ज्ञान

अंतिम वापरकर्त्याचे पाठवणे तरीही एकाच प्रिपेड लेजरवर परिणाम करते

एमबेडेड सेंड अजूनही ISV प्रिपेड वॉलेटमधूनच रक्कम वजा करते. उत्पादन ज्याला निधी देत नाही असे दुसरे लेजर तयार करू नका — होल्ड्स, पुन्हा प्रयत्न आणि आयडेम्पोटेन्सी प्रामाणिक राहिली पाहिजे.

अंतिम वापरकर्त्यासाठी एमबेडेड मेसेजिंग विनामूल्य वाटते: ते SaaS UI मध्ये Send वर टॅप करतात आणि त्यांना हिरवी टिक दिसते. परंतु बॅकएंडला, प्रत्येक यशस्वी सबमिट अजूनही ISV च्या मालकीच्या एकाच प्रिपेड लेजरला डेबिट करते. उत्पादनाने API एमबेड केले म्हणून दुसरे वॉलेट तयार होत नाही. जर ISV ने होल्ड्ससाठी निधी दिला नाही, तर पाठवण्याची क्रिया प्रामाणिक उत्पादन त्रुटीसह अपयशी ठरली पाहिजे — बनावट डिलीव्हर्ड स्टेटस दाखवून नाही.

काल्पनिक अकाउंटिंग हा अपयशाचा मुख्य प्रकार आहे: IOSOR वॉलेटचे समर्थन नसलेला इन-ॲप क्रेडिट मीटर, प्रिपेड लेजर रिकामे होत असताना SaaS रिफंड, किंवा आयडेम्पोटेन्सीशिवाय पुन्हा केलेले प्रयत्न जे एकाच OTP ला दोनदा डेबिट करतात. एमबेड कन्सोल लपवते; ISV हीच निधी देणारी संस्था राहते.

आर्किटेक्चर दस्तऐवज ओळ: अंतिम वापरकर्ता सेंड ≡ ISV प्रिपेड डेबिट. प्रत्येक डिझाइन पुनरावलोकन तिथूनच सुरू होते.

एकच लेजर, अगदी UI उत्पादन क्रेडिट्स दाखवत असले तरीही

भाडेकरूंना विकले जाणारे मेसेज पॅक्स हा ISV चा व्यावसायिक स्तर आहे. ते ISV निधी देत असलेल्या एकाच IOSOR वॉलेटवरील प्रिपेड होल्ड्स आणि डेबिटशी मॅप केले पाहिजेत. लेजर पंक्तींशी कधीही जुळत नाही अशी भाडेकरूची शिल्लक सपोर्ट टीमसाठी मोठी डोकेदुखी ठरते. वित्त विभागाला उत्पादनासारखाच खर्च दिसावा यासाठी वॉलेट लाईन्सविरुद्ध आठवड्याला भाडेकरू वापराची नोंद निर्यात करा. भागीदार वेगळेपण हा स्पष्ट करार असल्याशिवाय प्रत्येक भाडेकरूसाठी दुसरे IOSOR खाते उघडू नका.

होल्ड्स आणि आयडेम्पोटेन्सी एमबेड मार्गांवर अजूनही लागू होतात

सर्व्हर-साइड पाठवण्यासाठी OTP आणि ट्रान्सॅक्शनल SMS साठी आयडेम्पोटेन्सी की वापरणे आवश्यक आहे. SaaS UI मधील डबल-क्लिकमुळे एका वापरकर्त्याच्या क्रियेसाठी दोन डेबिट तयार होऊ नयेत. टाइमआउटनंतर पुन्हा केलेले प्रयत्न अंतिम DLR किंवा मॅप केलेल्या त्रुटीपर्यंत त्याच कीचे अनुसरण करतात. जेव्हा वॉलेट होल्ड करू शकत नाही, तेव्हा उत्पादनाशी सुसंगत अपुरे निधी किंवा पाठवणे थांबवल्याची स्थिती परत करा.

उत्पादनाच्या त्रुटींची लेजरच्या सत्याशी सांगड घाला

SaaS UI सिग्नल लेजर सत्य परवानगी दिलेले पुढील पाऊल
पाठवले / पोहोचवले डेबिट + DLR मार्ग अस्तित्वात आहे पावती ID दाखवा
रांगेत होल्ड उघडले किंवा विनंती स्वीकारली स्थिती तपासा
अपयशी / थांबवले होल्ड नाकारले किंवा गेट बंद केवळ नवीन हेतूने पुन्हा प्रयत्न करा
बनावट यश डेबिट नाही / होल्ड नाही पूर्णपणे निषिद्ध
नाकारले वॉलेटमध्ये अपुरा निधी प्रिपेड खाते रिचार्ज करा

सपोर्ट टीमला मधल्या कॉलमचे प्रशिक्षण द्य.

चॅनेल हस्तांतरण एकाच वॉलेटवर राहते

उत्पादनाने नंतर SMS व्यतिरिक्त ईमेल किंवा व्हॉइस जोडल्यास, वित्त विभागाच्या मंजुरीसह आपण दुसरे चॅनेल हस्तांतरण चालवल्याशिवाय खर्च एकाच प्रिपेड लेजरवर जमा होईल. एमबेड विनामूल्य साइड चॅनेल तयार करत नाही. SaaS सेटिंग्जमध्ये दुसरी लाईव्ह टाईल चालू करण्यापूर्वी वॉलेट शेजारचे नियम वाचा.

संबंधित ऑप्स मार्ग

IOSOR सह प्रारंभ करा

IOSOR कन्सोल उघडा आणि तुमच्या भाडेकरू क्रेडिट सिस्टीमला थेट प्राथमिक प्रीपेड वॉलेट लेजरशी मॅप करा. मास्टर वॉलेटवर होल्ड ठेवण्यापूर्वी प्रत्येक सर्व्हर-साइड एम्बेड विनंती एक निश्चित आयडम्पोटन्सी की पास करत असल्याचे सुनिश्चित करा. येणारी DLR प्रक्रिया करण्यासाठी तुमचा वेबहुक एंडपॉइंट कॉन्फिगर करा जेणेकरून उघडे होल्ड अंतिम लेजर डेबिट किंवा रिलीझमध्ये स्पष्टपणे सुटतील.

IOSOR सारांश

एका एम्बेड केलेल्या साॅफ्टवेअर इंटरफेसद्वारे अंतिम वापरकर्त्यांना सानुकूल संदेश क्रेडिट्स दाखवले जाऊ शकतात, परंतु प्रत्येक वास्तविक प्रेषण हे ISV द्वारे वित्तपुरवठा केलेल्या एकाच प्रीपेड लेजरशी जोडलेले असते. रीट्राय, चॅनेल विस्तार आणि वापरकर्ता स्थिती संकेत यांनी अनबॅक्ड UI ॲब्स्ट्रॅक्शनऐवजी थेट वॉलेट होल्ड्सशी जुळवून घेतले पाहिजे.

कडक सर्व्हर-साइड आयडम्पोटन्सी की लागू करा आणि प्रत्येक भाडेकरू UI स्थितीला खऱ्या लेजर DLR प्रतिसादांवर मॅप करा. अनबॅक्ड सेकंडरी वॉलेट तयार करू नका किंवा ठोस लेजर होल्डशिवाय भाडेकरू UI रीट्राय अंमलात आणण्याची परवानगी देऊ नका.

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

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