UPI AutoPay जोड़ें—‘किसी भी ऐप से भुगतान’ पहले दिखाना जरूरी

सदस्यता के लिए UPI AutoPay जोड़ते समय भुगतान पटल पर किसी भी UPI ऐप से भुगतान का विकल्प पसंदीदा ऐप के सीधे विकल्पों से पहले और प्रमुखता से दिखाएँ। NPCI की ब्रांड मार्गदर्शिका यही दृश्य क्रम बताती है और ऐप तथा QR से आवर्ती आदेश पंजीकरण के प्रवाह दिखाती है। ग्राहक को अनुमति देते समय व्यापारी, राशि, आवृत्ति और वैधता की शर्तें समझ आनी चाहिए।

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

आदेश बनाते समय सदस्यता की शर्तें मिलाएँ

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

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

ऐप चयन और QR से पंजीकरण का रास्ता परखें

मोबाइल पर ग्राहक को उपलब्ध UPI ऐप चुनने दें। यदि कुछ पसंदीदा ऐप के सीधे बटन भी हैं, तो खुले ऐप विकल्प के बाद रखें। वेबसाइट पर UPI पहचान भरकर अनुरोध भेजने का प्रवाह और दूसरे उपकरण से स्कैन करने के लिए QR, ग्राहक के संदर्भ के अनुसार अलग रास्ते हैं। हर रास्ते का लक्ष्य एक ही सदस्यता की शर्तों वाला आवर्ती आदेश होना चाहिए।

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

पूर्व सूचना के लिए जिम्मेदारी और समय तय करें

सामान्य आवर्ती डेबिट के लिए RBI के परिपत्र में जारीकर्ता द्वारा ग्राहक को डेबिट से कम से कम 24 घंटे पहले सूचना भेजने का नियम बताया गया है। व्यापारी अपने प्रोसेसर से स्पष्ट करे कि आगामी शुल्क की जानकारी जारीकर्ता तक कैसे पहुँचती है और सूचना तथा वसूली की स्थितियाँ उसे कैसे मिलेंगी। ग्राहक को व्यापारी की ओर से भेजा गया बिलिंग संदेश अनिवार्य पूर्व सूचना का स्वतः विकल्प नहीं है।

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

वेबहुक से आदेश और भुगतान की अलग स्थितियाँ मिलाएँ

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

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

विफल वसूली को उसी बिलिंग अवधि से जोड़ें

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

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

ऐप और प्रोसेसर बदलते समय पुराने आदेश अलग रखें

Razorpay के अंतर-संचालनीयता दस्तावेज़ के अनुसार नया ढाँचा पुराने उद्देश्य कोड 14 की जगह AZ और व्यापारी के कंपनी PAN से निकला Merchant Identifier Code इस्तेमाल करता है; Razorpay पात्र पुराने आदेशों का चरणबद्ध स्थानांतरण कर रहा है, जबकि नए आदेशों को शुरू से अंतर-संचालनीय बनाना अभी पारिस्थितिकी तंत्र की तैयारी पर निर्भर है। स्थानांतरण के लिए ग्राहक के बैंक और UPI ऐप का समर्थन आवश्यक है। अपात्र पुराने आदेश मौजूदा प्रवाह में चलते हैं, इसलिए ग्राहक को उनके ऐप बदलने पर स्वतः पोर्ट होने का आश्वासन न दें।

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

यह भी पढ़ें:

• UPI Lite या UPI 123PAY: छोटे भुगतान के लिए कौन-सा विकल्प कब काम आता है
• Google Pay और PhonePe में UPI AutoPay कैसे बंद करें: ऋण वाले mandate की अलग सीमा
• Merchant Center में मुफ्त सूची बनाएँ—भारत में डिलीवरी विवरण जरूरी