SMS सेगमेंट अकाउंटिंग: एक संदेश एक खर्च पंक्ति क्यों नहीं होती

उपयोगकर्ता ने एक संदेश टाइप किया। प्रीपेड वॉलेट ने तीन इकाइयाँ डेबिट कीं। यह बग नहीं है — यह सेगमेंट अकाउंटिंग है, और वित्त टीमें जो GSM-7 बनाम UCS-2 तथा मल्टीपार्ट संयोजन नहीं समझतीं, बिलिंग इंजन पर टिकट खोलती हैं जो ठीक डिज़ाइन के अनुसार काम कर रहा है। यह गाइड उन वित्त और प्रोडक्ट लीड्स के लिए है जो प्रीपेड व्हाइट-लेबल मैसेजिंग चलाते हैं और खर्च को समझाने योग्य चाहते हैं, न कि “इनवॉइस पर भरोसा करें”।.

IOSOR हर SMS खर्च पंक्ति को सेगमेंट संख्या, एन्कोडिंग और गंतव्य तक पुनर्निर्माण योग्य मानता है — अपारदर्शी प्लेटफ़ॉर्म शुल्क नहीं। मासिक प्लेटफ़ॉर्म उपयोग लगभग USD 1,000+ के पास सेगमेंट अनुशासन साफ मासिक मिलान और बार-बार “यह महँगा क्यों पड़ा” एस्केलेशन के बीच का अंतर है।.

एक SMS एक खर्च पंक्ति क्यों नहीं है

GSM-7 बनाम UCS-2: कैरेक्टर सेट गणित क्यों बदलता है

• GSM-7 सीमित लैटिन वर्णमाला और छोटे प्रतीक सेट को कवर करता है; प्रत्येक वर्ण प्रति सेगमेंट कम “बजट” लेता है
• UCS-2 (GSM-7 के बाहर कोई भी वर्ण — इमोजी, अधिकांश गैर-लैटिन स्क्रिप्ट, कुछ विराम चिह्न) पूरे संदेश को व्यापक एन्कोडिंग में धकेलता है जिसकी प्रति-सेगमेंट वर्ण सीमा कम होती है
• एक “अदृश्य” वर्ण (दस्तावेज़ से स्मार्ट कोट, चेकमार्क, इमोजी) चुपचाप पूरे संदेश को GSM-7 से UCS-2 पर पलट सकता है

मल्टीपार्ट सेगमेंटेशन और संयोजन ओवरहेड

एकल-सेगमेंट सीमा पार करना सुरुचिपूर्ण ढंग से “गोल” नहीं होता — संदेश कई सेगमेंट में बँटता है, प्रत्येक संयोजन ओवरहेड लेकर, और उसी के अनुसार फिर से बिल होता है।.

सेगमेंट गिनती कहाँ छिपती है

• कंपोज़र पूर्वावलोकन “1 संदेश” दिखाता है जबकि वास्तविक एन्कोडिंग 2–3 बिल्ड सेगमेंट देता है
• टेम्पलेट वैरिएबल जो केवल कुछ प्राप्तकर्ताओं के लिए लंबाई सीमा से आगे धकेलते हैं
• लोकेल-विशिष्ट वर्ण (उच्चारण, गैर-लैटिन स्क्रिप्ट) जो एक भाषा में QA पास करते हैं और दूसरी में लागत बढ़ाते हैं

प्रीपेड वॉलेट से सेगमेंट मिलान

हर डेबिट पंक्ति में होना चाहिए: गंतव्य, संदेश लंबाई, पहचानी एन्कोडिंग, सेगमेंट संख्या और इकाई दर — मिश्रित “SMS शुल्क” नहीं। यदि वित्त वॉलेट डेबिट को इन पाँच फ़ील्ड पर मैप नहीं कर सकता, लेजर मिलान योग्य नहीं — उस पर विश्वास से भरोसा है।.

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

बड़ी मात्रा में संदेश भेजने से पहले IOSOR कंसोल में अपने आउटबाउंड टेम्प्लेट पेलोड की समीक्षा करें। किसी भी ऐसे पेलोड को चिन्हित करने के लिए API सत्यापन गेट कॉन्फ़िगर करें जो एकल खंड से अधिक हो या अप्रत्याशित रूप से GSM-7 से UCS-2 एन्कोडिंग में बदल जाए। सुनिश्चित करें कि आपके डिलीवरी रिपोर्ट वेबहुक सामान्य संदेश గణना के बजाय शेष राशि की कटौती को सीधे सटीक बिल किए गए खंड గణना से जोड़ते हैं।

• प्रीपेड होल्ड रिजर्व: उच्च अभियान समcurrent के तहत उपलब्ध वॉलेट बैलेंस की गणना
• इनवॉइस सप्ताह मूल्य निर्धारण: उद्धरण बनाम बिल की गई पंक्तियाँ
• अभियान के बीच में कैरेक्टर सेट बदलने पर छिपे हुए डेबिट को रोकें

IOSOR सार

एक अकेला आउटबाउंड टेक्स्ट संदेश शायद ही कभी एक ही खर्च पंक्ति में बदलता है। GSM-7 और UCS-2 एन्कोडिंग के बीच का चुनाव, बहु-भाग संयोजन के हेडर ओवरहेड के साथ मिलकर, यह सुनिश्चित करता है कि गतिशील पाठ में थोड़ा सा बदलाव या एक भी विशेष वर्ण प्रत्येक प्राप्तकर्ता के लिए आपके बिलिंग को आसानी से दोगुना कर सकता है।