भारत: UPI और IMPS के पेमेंट डिटेल्स भी अलग, समस्याओं की कतारें भी

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

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

पहले तय करें कि असल में क्या इंटीग्रेट किया गया है

NPCI, UPI को IMPS इन्फ्रास्ट्रक्चर पर बने इंस्टेंट पेमेंट सिस्टम के रूप में बताता है। मर्चेंट भुगतान स्वीकार करने के लिए एक्वायरर चाहिए; वही मर्चेंट कैटेगरी तय करता है और इंटीग्रेशन देता है। UPI पता, QR और ऐप पर रीडायरेक्ट किसी सामान्य निजी अकाउंट को सहमत मर्चेंट प्रोडक्ट नहीं बनाते। NPCI का विवरण प्रतिभागियों की भूमिकाएँ समझने में उपयोगी है, लेकिन यूज़र सिनेरियो के पुराने उदाहरणों को अपने-आप लॉन्च का मौजूदा स्पेसिफ़िकेशन नहीं माना जा सकता।

IMPS में आम रूटिंग अकाउंट नंबर और IFSC से होती है; दस्तावेज़ में मोबाइल नंबर और MMID का संयोजन भी बताया गया है। IFSC बैंक रूट से जुड़ा है, MMID संबंधित पहचान योजना से। यह merchant order ID का विकल्प नहीं है। NPCI, SMS और IVR को छोड़कर, IMPS की सीमा 500 000 INR प्रति ट्रांज़ैक्शन बताता है; कोई ख़ास बैंक ग्राहक के लिए उपलब्ध चैनल को और सख़्ती से सीमित कर सकता है।

कौन-से फ़ील्ड आपस में नहीं मिलाने चाहिए

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

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

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

सफलता का पेज और पैसे की स्थिति अलग-अलग चलते हैं

उदाहरण के लिए Razorpay में payment.authorized और payment.captured इवेंट हैं; दस्तावेज़ चेतावनी देता है कि webhook इवेंट के समय की स्थिति भेजता है, भले ही ऑब्जेक्ट तब तक बदल चुका हो। यह एक ख़ास गेटवे का मॉडल है, UPI के सार्वभौमिक स्टेटस नहीं। अपने चेकआउट के लिए भी यही सिद्धांत उपयोगी है: इवेंट की प्रामाणिकता जाँचें, रक़म और ऑर्डर का मिलान करें, मूल स्टेटस सहेजें और वित्तीय एंट्री एक ही बार करें।

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

ख़राबी के बाद रिफ़ंड और ख़रीद का रिफ़ंड अलग प्रक्रियाएँ हैं

असफल ट्रांज़ैक्शन पर RBI के नियम ऐसे डेबिट में फ़र्क़ करते हैं जिसमें लाभार्थी को क्रेडिट नहीं हुआ, और ऐसे UPI भुगतान में जिसकी पुष्टि मर्चेंट को नहीं मिली। प्रकाशित तालिका में संबंधित मामलों के लिए क्रमशः T+1 और T+5 दिए गए हैं, और समय-सीमा पार होने पर मुआवज़ा। ये कुछ ख़ास तकनीकी ख़राबियों को ठीक करने की समय-सीमाएँ हैं, यह वादा नहीं कि कोई भी ख़रीद उतने ही समय में लौट आएगी। T का मतलब ट्रांज़ैक्शन की कैलेंडर तारीख़ है। RBI की तालिका।

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

इंस्टेंट भुगतान आपके सेटलमेंट अनुबंध का वर्णन नहीं करता

«पैसा मर्चेंट के पास कब है» — इस सवाल के लिए अकाउंट का नाम लेना ज़रूरी है। यह एक्वायरिंग अनुबंध के तहत सहमत मर्चेंट अकाउंट या इंटरमीडिएट अकाउंट हो सकता है। PSP का आंतरिक बैलेंस, उपलब्ध बैलेंस और कंपनी के करंट अकाउंट में क्रेडिट को पर्यायवाची नहीं माना जा सकता। settlement report का नमूना माँगें: gross, कमीशन, टैक्स कटौती, रिफ़ंड, रिज़र्व और net। फिर जाँचें कि net वाक़ई बैंक स्टेटमेंट में है।

लिमिट भी अलग से पूछें: प्रति ट्रांज़ैक्शन, प्रति दिन, भुगतानकर्ता का प्रकार, मर्चेंट कैटेगरी और चैनल। किसी पुराने FAQ की संख्या को सभी UPI भुगतानों की सार्वभौमिक सीमा नहीं बनाया जा सकता। पायलट में अनुमत सीमांत रक़में और सामान्य अस्वीकृतियाँ टेस्ट की जाती हैं; नियंत्रण से बचने के लिए भुगतान को टुकड़ों में बाँटना अस्वीकार्य है।

गेमिंग प्रोजेक्ट के लिए सीमा

भारत के Promotion and Regulation of Online Gaming Act, 2025 की धारा 7 में online money gaming service के लिए भुगतान में सहायता पर रोक है; मनी गेम की परिभाषा सिर्फ़ संयोग के खेलों तक सीमित नहीं है। MeitY 2026 के नियम और अधिसूचनाएँ भी प्रकाशित करता है। विदेशी गेमिंग लाइसेंस भारत में ऐसे भुगतान स्वीकार करने की अनुमति नहीं है। इंटीग्रेशन पर चर्चा से पहले ख़ास प्रोडक्ट, लागू क़ानूनों और अदालती फ़ैसलों पर मौजूदा क़ानूनी राय ज़रूरी है।

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