SMS फ़ॉरवर्डर ने ट्रांसफ़र देखा। क्या ऑर्डर बंद किया जा सकता है?

«SMS फ़ॉरवर्डर ऑनलाइन है» का मतलब सिर्फ़ इतना है कि सिस्टम के किसी हिस्से ने हाल ही में जवाब दिया। इससे यह नतीजा नहीं निकलता कि वह बैंक नोटिफ़िकेशन पा रहा है, रक़म सही निकाल रहा है और सारे इवेंट आगे भेज रहा है। P2P ऑपरेटर के लिए यह फ़र्क़ सीधे पैसों का है: छूटा हुआ मैसेज भुगतान की मान्यता में देरी करता है, और ग़लत पढ़ा गया मैसेज ऐसे पैसे की पुष्टि कर सकता है जो है ही नहीं।

यहाँ फ़ॉरवर्डर का मतलब है वह टूल जो डिवाइस या किसी अन्य सहमत स्रोत से ट्रांज़ैक्शन की अनुमत सूचनाएँ प्रोसेसिंग सिस्टम तक पहुँचाता है। यह संभावित प्राप्ति को जल्दी पकड़ने में मदद करता है। पैसा पाने वाले की अनुबंधीय भूमिका, काम के इस मॉडल के लिए बैंक की अनुमति और वित्तीय मान्यता का आधार अलग से तय होते हैं। ऐप इंस्टॉल करने से इनमें से कोई भी शर्त नहीं बदलती।

बैंक और ऑर्डर के बीच कई स्वतंत्र इवेंट होते हैं

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

कोई भी हिस्सा अटक सकता है या बगल वाले हिस्से से अलग पूरा हो सकता है। बैंक ने पैसा क्रेडिट कर दिया, लेकिन नोटिफ़िकेशन अभी नहीं आया। डिवाइस को मैसेज मिल गया, लेकिन नेटवर्क चला गया। सर्वर ने इवेंट सहेज लिया, पर जवाब नहीं पहुँचा और ऐप ने दोबारा भेज दिया। सिस्टम ने नोटिफ़िकेशन को ऑर्डर से मिला दिया, लेकिन बाद में बैंक स्टेटमेंट में दूसरी रक़म दिखी। इन स्थितियों में अलग-अलग कार्रवाई चाहिए, भले ही ग्राहक की स्क्रीन पर सब «पेमेंट अटक गया» जैसी दिखें।

इसलिए इवेंट के साथ ट्रांज़ैक्शन का समय (अगर वह भरोसेमंद रूप से उपलब्ध हो), डिवाइस पर मिलने का समय और सर्वर पर मिलने का समय सहेजा जाता है। पार्सिंग और मैचिंग का समय अलग से दर्ज किया जा सकता है। इन्हें एक टाइमस्टैम्प में मिला देने पर यह समझना असंभव हो जाता है कि देरी बैंक की है, डिवाइस की, नेटवर्क की या अपनी प्रोसेसिंग कतार की।

सबसे पहले तय करें कि असल में कौन-सा डेटा चाहिए

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

अनुमतियाँ डिवाइस और डेटा का मालिक किसी ख़ास उद्देश्य और जानकारी पाने वाले के लिए देता है। नोटिफ़िकेशन एक्सेस को फ़ोन की सारी सामग्री भेजने की सहमति नहीं समझना चाहिए। Google Play, SMS और कॉल लॉग के साथ काम को अलग से सीमित करता है; पढ़ने का तकनीकी तरीक़ा होना ऐप के वितरण या उपयोग की अनुमति नहीं है। प्लेटफ़ॉर्म और बैंक की लागू आवश्यकताएँ लॉन्च से पहले जाँची जाती हैं।

ऑथेंटिकेशन मैसेज, OTP और किसी कार्रवाई की पुष्टि के अनुरोध इस चैनल से बाहर रखे जाते हैं। फ़िल्टरिंग का काम अनावश्यक ट्रांसमिशन रोकना है, न कि सर्वर पर पहुँच चुके सीक्रेट को बाद में मिटाने की कोशिश करना। अगर अनुमत नोटिफ़िकेशन को भरोसेमंद ढंग से अलग करना संभव नहीं, तो वह स्रोत उपयुक्त नहीं है। रिकंसिलिएशन की सुविधा के बदले ज़्यादा व्यापक एक्सेस देना समझदारी भरी क़ीमत नहीं है।

असली मैसेज पर भी पार्सर ग़लती कर सकता है

एक अभ्यास नोटिफ़िकेशन में 12 000 का क्रेडिट और 524 000 का नया बैलेंस है। बैंक का टेम्पलेट बदलने के बाद पहली मिलती-जुलती रक़म निकालने वाला लॉजिक ट्रांज़ैक्शन की रक़म की जगह अकाउंट बैलेंस लौटाने लगता है। मैसेज असली है, भेजने वाला जाना-पहचाना है, कनेक्शन सुरक्षित है, लेकिन प्रोसेसिंग का नतीजा वित्तीय रूप से ग़लत है।

इसलिए टेम्पलेट और पार्सर का संस्करण सबूतों की कड़ी का हिस्सा होता है। अज्ञात फ़ॉर्मैट को अनुमानित मिलान के आधार पर पक्का नतीजा देने की जगह जाँच के लिए भेजा जाता है। प्रोटोकॉल को क्रेडिट, डेबिट, रिवर्सल और सूचना वाले मैसेज में फ़र्क़ करना चाहिए। हर धनात्मक संख्या को नई प्राप्ति में नहीं बदला जा सकता।

अगर एक साथ 12 000 के दो ऑर्डर खुले हों, तो «रक़म और सबसे नज़दीकी समय» का जोड़ भी काफ़ी नहीं। अतिरिक्त संकेत उतने ही इस्तेमाल होते हैं, जितने स्रोत वाक़ई भेजता है। अगर ज़रूरी रेफ़रेंस नहीं है, तो सिस्टम अस्पष्टता स्वीकार करता है। मैचिंग पूरी करने के लिए वह ऑर्डर नंबर से रेफ़रेंस गढ़ता नहीं।

दोबारा डिलीवरी उबाऊ होनी चाहिए

मान लीजिए सर्वर ने नोटिफ़िकेशन सहेज लिया, लेकिन डिवाइस को पुष्टि नहीं मिली। दोबारा भेजने पर दूसरी वित्तीय एंट्री नहीं बननी चाहिए, बल्कि पहले से स्वीकार किए गए इवेंट का लिंक लौटना चाहिए। मैसेज का स्थिर आइडेंटिफ़ायर और डिलीवरी की सहेजी गई स्थिति दोहराव को नए इवेंट से अलग करने में मदद करते हैं। लेकिन दो नोटिफ़िकेशन का टेक्स्ट एक जैसा होना यह साबित नहीं करता कि असली ट्रांसफ़र सिर्फ़ एक था।

बैंक डेटा आने पर अवलोकनों को वास्तविक प्राप्ति के इर्द-गिर्द जोड़ा जाता है। SMS, push और स्टेटमेंट की एक लाइन एक ही ट्रांज़ैक्शन से जुड़ी हो सकती हैं। उलटे, एक जैसी रक़म पर दो अलग बैंक रेफ़रेंस दो भुगतानों की पुष्टि कर सकते हैं। इसलिए डिलीवरी चैनल का डीडुप्लिकेशन और पैसों की प्राप्ति का डीडुप्लिकेशन अलग-अलग काम हैं।

कनेक्शन लौटने पर कतार मूल समय बनाए रखते हुए नियंत्रित ढंग से भेजी जाती है। पुराने मैसेज सिर्फ़ इसलिए ताज़ा भुगतान नहीं लगने चाहिए कि सर्वर को वे अभी मिले हैं। जुड़े हुए कुछ ऑर्डर पहले ही एक्सपायर हो चुके हो सकते हैं या मैन्युअल जाँच में जा चुके हो सकते हैं; उनकी प्रोसेसिंग में मौजूदा स्थिति और जारी किए गए पेमेंट डिटेल्स का इतिहास ध्यान में रखना होगा।

«डिवाइस चालू है» और «स्रोत काम कर रहा है» की जाँच अलग-अलग

ऑपरेशनल डैशबोर्ड आख़िरी कनेक्शन, अनुमत स्रोत की स्थिति, सबसे पुराने न भेजे गए इवेंट की उम्र, बिना पुष्टि वाली डिलीवरी की संख्या और आख़िरी सफल रिकंसिलिएशन दिखा सकता है। ट्रांज़ैक्शन न हों तो नोटिफ़िकेशन न आना सामान्य है। लेकिन अगर बैंक में प्राप्तियाँ दिख रही हैं और चैनल चुप है, तो यह एक दिखाई देने वाली विसंगति है।

Android नोटिफ़िकेशन लिसनर के कनेक्ट और डिस्कनेक्ट होने की स्थितियों को दस्तावेज़ करता है, और बैटरी सेवर मोड बैकग्राउंड नेटवर्क काम को टाल सकते हैं। टेस्टिंग में इन बातों का ध्यान रखना होगा। ये अनुमतियों को चुपके से बढ़ाने या डिवाइस की सुरक्षा बायपास करने का बहाना नहीं हैं। कामकाजी आर्किटेक्चर में ख़राबी का पता लगाना, साफ़ एस्केलेशन और प्राप्तियों की जाँच का वैकल्पिक अनुमत तरीक़ा शामिल होता है।

भरोसेमंद स्रोत खो जाने पर ऑपरेटर प्रभावित रूट पर नए असाइनमेंट रोक सकता है, जबकि पहले से दिए गए निर्देशों की प्रोसेसिंग जारी रखता है। मौजूदा ग्राहक अब भी पैसा भेज सकते हैं। खुले ऑर्डर की सूची के बिना चैनल सीधे बंद कर देने से प्राप्तियाँ ठीक उसी समय निगरानी से बाहर रह जाएँगी, जब अनिश्चितता सबसे ज़्यादा होती है।

नतीजा बैंक के आधार पर मापें, मैसेज की गिनती से नहीं

एक दिन की कल्पना करें जिसमें 100 पुष्ट बैंक प्राप्तियाँ हैं। फ़ॉरवर्डर ने इनमें से 95 के नोटिफ़िकेशन समय पर भेजे, तीन के देर से भेजे और दो छोड़ दिए। इसके अलावा आठ इवेंट दोबारा आए। सर्वर को 106 मैसेज मिले: 98 अनोखे अवलोकन और आठ दोहराव।

«100 भुगतानों पर 106 इवेंट» वाला आँकड़ा गुणवत्ता के बारे में कुछ नहीं बताता। इस उदाहरण में पहचान की पूर्णता 98% है, और सभी प्राप्तियों के मुक़ाबले समयबद्धता 95%। मैचिंग की ग़लतियाँ, एक्सेप्शन की उम्र और सिर्फ़ रिकंसिलिएशन में मिले ट्रांज़ैक्शन का हिस्सा अलग से गिने जाते हैं। स्वतंत्र बैंक डेटा के बिना छूटे मैसेज हर में आते ही नहीं, और सिस्टम असल से बेहतर दिखता है।

फ़ॉरवर्डर का अंतिम नतीजा एक जाँचने योग्य अवलोकन है, जो आगे के फ़ैसले के लिए उपयुक्त है। अगर अनुबंध कमज़ोर संकेत पर तेज़ मान्यता की अनुमति देता है, तो यह लिमिट, ज़िम्मेदार व्यक्ति और बाद के रिकंसिलिएशन वाला एक अलग, सोचा-समझा जोखिम है। ऐसे संकेत को अंतिम बैंक पुष्टि कहना ग़लत है। अच्छा ऑटोमेशन पैसा खोजने का समय घटाता है और यह साबित करने की क्षमता बनाए रखता है कि असल में कौन-सा पैसा मिला।