एंड-यूजर सेंड अभी भी एक ही प्रीपेड लेजर को हिट करता है

एंबेडेड मैसेजिंग एंड-यूजर के लिए मुफ्त लगती है: वे SaaS UI के भीतर सेंड पर टैप करते हैं और एक हरा चेक देखते हैं। पर्दे के पीछे, हर सफल सबमिट अभी भी ISV के स्वामित्व वाले एक ही प्रीपेड लेजर को हिट करता है। उत्पाद द्वारा API एम्बेड किए जाने के कारण कोई दूसरा वॉलेट प्रकट नहीं होता है। यदि ISV होल्ड को फंड नहीं करता है, तो सेंड एक ईमानदार प्रोडक्ट एरर के साथ विफल होना चाहिए — न कि किसी फर्जी डिलीवर स्थिति के साथ।

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

आर्किटेक्चर दस्तावेज़ लाइन: एंड-यूज़र सेंड ≡ ISV प्रीपेड डेबिट। हर डिज़ाइन समीक्षा वहीं से शुरू होती है।

एक ही लेजर, भले ही UI उत्पाद क्रेडिट दिखाता हो

टैलेंट को बेचे जाने वाले मैसेज पैक एक ISV कमर्शियल लेयर हैं। उन्हें ISV द्वारा वित्त पोषित एकल IOSOR वॉलेट पर प्रीपेड होल्ड और डेबिट से मैप होना चाहिए। एक टैलेंट बैलेंस जो कभी लेजर पंक्तियों से मेल नहीं खाता, सपोर्ट के लिए एक बड़ा कर्ज है। वॉलेट लाइनों के खिलाफ साप्ताहिक रूप से टैलेंट उपयोग का निर्यात करें ताकि फाइनेंस वही बर्न देखे जो उत्पाद देखता है।

प्रति टैलेंट दूसरा IOSOR खाता न खोलें जब तक.

होल्ड और आइडेम्पोटेंसी एम्बेड पथों पर भी लागू होते हैं

सर्वर-साइड सेंड को OTP और ट्रांजेक्शनल SMS के लिए आइडेम्पोटेंसी कुंजियों का उपयोग करना चाहिए। SaaS UI में एक डबल-क्लिक से एक उपयोगकर्ता कार्रवाई के लिए दो डेबिट नहीं बनने चाहिए। टाइमआउट के बाद रीट्राई एक टर्मिनल DLR या मैप्ड विफलता तक उसी कुंजी का पालन करते हैं।

जब वॉलेट होल्ड नहीं कर सकता, तो एक उत्पाद-मूल अपर्याप्त-फंड या पॉज़्ड-सेंड स्थिति लौटाएं। जब होल्ड विफल हो जाता है तो डिलीवर किए गए अर्थशास्त्र के साथ कभी भी HTTP 200 न लौटाएं।

उत्पाद त्रुटियों को लेजर की सच्चाई से मैप करें

बीच वाले कॉलम पर सपोर्ट को प्रशिक्षित करें। बिना लेजर पंक्तियों के UI ग्रीन्स के बारे में टिकटे पायलट सप्ताह को बर्बाद करती हैं।

चैनल हैंडओवर एक ही वॉलेट पर रहते हैं

यदि उत्पाद बाद में SMS के साथ ईमेल या वॉयस जोड़ता है, तब भी खर्च उसी प्रीपेड लेजर पर आता है जब तक कि आप वित्त स्वीकृति के साथ दूसरा चैनल हैंडओवर न चलाएं। एम्बेड एक मुफ्त साइड चैनल नहीं बनाता है। SaaS सेटिंग्स में एक और लाइव टाइल फ़्लिप करने से पहले वॉलेट आसन्नता पढ़ें।

संबंधित ऑपरेशनल पाथ

• वॉलेट पर दूसरा चैनल: खर्च हैंडओवर
• आइडेम्पोटेंसी, रीट्राई और पैसा
• मल्टी-टैनेंट खातों में दर सीमाओं को सुरक्षित रूप से लागू करना

IOSOR के साथ शुरुआत करें

IOSOR कंसोल खोलें और अपने टेनेंट क्रेडिट सिस्टम को सीधे प्राथमिक प्रीपेड वॉलेट लेजर से मैप करें। मास्टर वॉलेट पर होल्ड लगाने से पहले सुनिश्चित करें कि सभी सर्वर-साइड एम्बेड अनुरोध एक निर्धारणात्मक आइडपोटेंसी पास करते हैं। आने वाले DLR को प्रोसेस करने के लिए अपने वेबहुक एंडपॉइंट को कॉन्फ़िगर करें ताकि खुले होल्ड अंतिम लेजर डेबिट या रिलीज के रूप में साफ़ तौर पर हल हो सकें।

IOSOR सार

एक एम्बेडेड सास इंटरफेस अंत उपयोगकर्ताओं को कस्टम संदेश क्रेडिट प्रस्तुत कर सकता है, लेकिन हर वास्तविक प्रेषण ISV द्वारा वित्तपोषित एकल प्रीपेड वॉलेट से बंधा होता है। पुन: प्रयास, चैनल विस्तार, और उपयोगकर्ता स्थिति संकेतों को बिना बैक्ड UI एब्स्ट्रक्शन के बजाय सीधे वॉलेट होल्ड के मुकाबले मेल खाना चाहिए। कठोर सर्वर-साइड आइडपोटेंसी कुंजियों को लागू करें और हर टेनेंट UI स्थिति को सच्चे लेजर DLR प्रतिक्रियाओं से मैप करें। असत्यापित द्वितीयक वॉलेट न बनाएं या टेनेंट UI को ठोस लेजर होल्ड के बिना पुन: प्रयास निष्पादित करने की अनुमति न दें।