ऑर्डर एक्सपायर हुआ, पैसा आ गया: P2P ऑर्डर का जीवन-चक्र

लेट पेमेंट को समझने के लिए 10 000 के एक सांकेतिक भुगतान को लेते हैं। पेमेंट निर्देश की अवधि 10:15 पर ख़त्म हो गई। ख़रीदार ने 10:14 पर ट्रांसफ़र भेजा, लाभार्थी के बैंक ने उसे 10:17 पर दर्ज किया, और ऑपरेटर ने एंट्री 10:20 पर देखी। तब तक दुकान ऑर्डर रद्द कर चुकी थी। देर किसने की, और क्या इस भुगतान को न हुआ मान सकते हैं? जवाब उस ट्रांज़ैक्शन के समय और नियमों पर निर्भर करता है, लेकिन ऑर्डर किसी भी रंग में दिखे, पैसे का हिसाब रखना अब ज़रूरी है।

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

ऑर्डर और प्राप्ति के आइडेंटिफ़ायर अलग होते हैं

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

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

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

बीच की स्थितियाँ उपयोगी हैं

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

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

ख़ास API में दस्तावेज़ी एक्सेप्शन भी होते हैं। PayStar के विवरण में लिखा है कि शिकायत के बाद P2P ऑर्डर पुराने आइडेंटिफ़ायर के साथ Failed से Success में बदल सकता है। वहीं इवेंट इतिहास को पूरी ट्रेसिंग की गारंटी नहीं बताया गया है। यह उस इंटरफ़ेस की विशेषता है जिसे अपने इंटीग्रेशन के लिए पुष्ट करना होगा, किसी भी P2P प्लेटफ़ॉर्म का सार्वभौमिक नियम नहीं।

देर से आई प्राप्ति को मिनट-दर-मिनट समझें

10 000 के ट्रांसफ़र पर लौटते हैं। लॉग में कम से कम निर्देश ख़त्म होने का समय 10:15, बैंक में प्राप्ति का समय 10:17 और पकड़े जाने का समय 10:20 सहेजा जाता है। भेजने का समय 10:14 ख़रीदार के सबूत से पता चला है और उसकी जाँच ज़रूरी हो सकती है। ये समय एक-दूसरे की जगह नहीं लेते। अगर अनुबंध लाभार्थी के अकाउंट में क्रेडिट के समय को मानता है, तो ख़रीदार का जल्दी बटन दबाना अपने-आप अवधि नहीं बढ़ाता।

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

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

एक भुगतान के दो हिस्से

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

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

पैसा न होने पर कमी को हाथ से «सिस्टम का मुआवज़ा» लिख देना ख़ास तौर पर ख़तरनाक है। इससे ट्रांज़ैक्शन की इकोनॉमिक्स बदलती है और स्पष्ट फ़ैसला चाहिए: अंतर की फ़ंडिंग कौन करेगा और क्यों। वरना सपोर्ट स्क्रीन पर कन्वर्ज़न तो सुधार देगा, लेकिन सेटलमेंट में ऐसा कर्ज़ बना देगा जिसे समझाया न जा सके।

मैसेज का दोहराव और दूसरा ट्रांसफ़र एक जैसे दिखते हैं

एक ही बैंक प्राप्ति के लिए SMS, push, स्टेटमेंट की एंट्री और दोबारा एक्सपोर्ट किया गया डेटा आ सकते हैं। ये एक घटना के कई अवलोकन हैं। भरोसेमंद मिलान के बाद ये सबूत को मज़बूत करते हैं, मिली रक़म नहीं बढ़ाते। हर अवलोकन का अपना स्रोत सहेजा जाता है, लेकिन वित्तीय मान्यता एक ही प्राप्ति से जुड़ी होती है।

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

किसे पर्याप्त सबूत माना जाए

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

मिलान में रक़म, मुद्रा, लाभार्थी, बैंक रेफ़रेंस, समय-सीमा और अनुमत भेजने वाले को ध्यान में रखना चाहिए। नाम मिल जाना भी पैसों के स्रोत की वैधता साबित नहीं करता। स्रोतों के बीच विरोधाभास होने पर मामला जाँच में जाता है, सबसे सुविधाजनक स्टेटस चुनकर नहीं सुलझाया जाता।

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