लखनऊ। UPI पेमेंट के क्षेत्र में काफी हलचल हो रही है और फिनटेक की दुनिया में कई खिलाड़ी मर्चेंट UPI प्लगइन के अपने वर्शन लॉन्च कर रहे हैं। मर्चेंट UPI प्लगइन से निम्नलिखित समस्याओं का समाधान माना जा रहा है।

1. पेमेंट ऐप्स (जिसे TPAP – थर्ड पार्टी एप्लिकेशन प्रोवाइडर्स के रूप में भी जाना जाता है) इंटेंट मॉडल के माध्यम से कम सफलता दर
2. हर नई UPI कार्यक्षमता के लिए पेमेंट ऐप्स की तैयारी

इस ब्लॉग में, हम मूल्यांकन करेंगे कि क्या ये वास्तविक समस्याएं हैं जिन्हें मर्चेंट UPI प्लगइन द्वारा हल किया जाएगा।

1. पेमेंट ऐप्स इंटेंट मॉडल के माध्यम से कम सफलता दर

UPI प्लगइन लॉन्च करने वाले सभी खिलाड़ियों ने दावा किया है कि UPI प्लगइन के साथ पेमेंट करने के लिए यूजरों द्वारा जरुरी स्टेप्स की संख्या में कमी आई है। कुछ लोग यह भी दावा करते हैं कि यह पेमेंट ऐप (आशय प्रवाह) के माध्यम से भुगतान यात्रा की तुलना में चरणों को 5 चरणों से घटाकर 1 चरण कर देता है। यह हकीकत से ज्यादा मार्केटिंग हाइप है।

पेमेंट ऐप फ्लो (प्रवाह) इस प्रकार दिखता है:

स्टेप 1: ग्राहक मर्चेंट पेमेंट पेज पर एक पेमेंट ऐप चुनता है और पेमेंट बटन पर टैप करता है
चरण दो: ग्राहक को पेमेंट ऐप पर ले जाया जाता है जहां डिफ़ॉल्ट UPI विधि पहले से चयनित होती है। ग्राहक उपयोग करने के लिए UPI पद्धति की समीक्षा करता है और पेमेंट ऐप्स के पेमेंट पेज पर पेमेंट बटन दबाता है
चरण 3: ग्राहक को एमपिन पेज पर ले जाया जाता है जहां वह पिन दर्ज करता है और सबमिट करता है। इस स्टेप के बाद पेमेंट प्रक्रिया हो जाता है और ग्राहक को मर्चेंट एप्लिकेशन के ऑर्डर कन्फर्मेशन पेज पर वापस भेज दिया जाता है

UPI प्लगइन फ्लो (प्रवाह):

स्टेप 1: ग्राहक मर्चेंट पेमेंट पेज पर एक UPI अकाउंट चुनता है और पेमेंट बटन पर टैप करता है
चरण दो: ग्राहक को एमपिन पेज पर ले जाया जाता है (अब UPI प्लगइन SDK के भीतर एम्बेडेड है जो मर्चेंट एप्लिकेशन के अंदर होता है) जहां वह पिन दर्ज करता है और सबमिट करता है। इस स्टेप के बाद पेमेंट प्रक्रिया हो जाता है और ग्राहक को मर्चेंट एप्लिकेशन के ऑर्डर कन्फर्मेशन पेज पर वापस भेज दिया जाता है
जैसा कि आप देख सकते हैं, ग्राहकों को पेमेंट ऐप्स के पेमेंट पेज पर ले जाने का एक स्टेप कम हो गया है। इसके बजाय, UPI प्लगइन मॉडल में, UPI पेमेंट विकल्प सीधे मर्चेंट पेमेंट पेज पर दिखाया जाता है।
आइए इस अनुकूलन के कारण सफलता दर में संभावित सुधार पर नजर डालें। उनका दावा है कि ऐप-टू-ऐप रूटिंग ड्रॉप ऑफ का कारण बनती है और UPI प्लगइन इन्हें होता हटा देता है क्योंकि यह मर्चेंट एप्लिकेशन के भीतर एम्बेडेड एक SDK है। नीचे हम जांच करते हैं कि ऐप-टू-ऐप रूटिंग के साथ-साथ SDK को लागू करना तकनीकी नजरिए से एंड्रॉइड पर कैसे काम करता है।
एंड्रॉइड इंटेंट पर ऐप-टू-ऐप रूटिंग एक इंटर-प्रोसेस कम्युनिकेशन (IPC) मॉडल पर काम करता है। मूल ऐप के भीतर एक SDK को लागू करना एक ही प्रक्रिया और एक ही एप्लिकेशन के भीतर काम करता है। तकनीकी तौर पर इन दोनों मॉडलों में बहुत कम अंतर है। इंटर-प्रोसेस कम्युनिकेशन के कारण गिरावट बेहद कम होगी (पेमेंट ऐप के लिए एक नई प्रक्रिया शुरू करने और फिर IPC के माध्यम से नई प्रक्रिया के साथ संचार करने का ओवरहेड)।
यदि मर्चेंट एप्लिकेशन यह जांचता है कि क्या पेमेंट ऐप उपयोगकर्ता के डिवाइस पर इंस्टॉल है और यह भुगतान के लिए तैयार है (यानी कम से कम एक यूपीआई खाता जुड़ा हुआ है और भुगतान के लिए सेट है), तो दोनों मॉडलों के बीच कोई अतिरिक्त ड्रॉप-ऑफ नहीं होना चाहिए।
अब आइए देखते हैं कि UPI प्लगइन पर यूजर के लिए UPI सेटअप प्राप्त करने में क्या लगता है। प्रत्येक यूजर जिसके लिए UPI खाता मर्चेंट एप्लिकेशन के पेमेंट पेज पर दिखाया जाना है, को UPI प्लगइन पर ऑनबोर्ड होना होगा। ऑनबोर्डिंग प्रक्रिया में चार स्टेप होते हैं

1. SMS भेजने की अनुमति यूजर से ली जाती है (यह यूजर के फ़ोन नंबर को वेरीफाई करने के लिए है)
2. डिवाइस रजिस्ट्रेशन/बाध्यकारी आधार पर SMS भेजना
3. यूजर के फोन नंबर लिंकिंग से लिंक किए गए खातों की सूची
4. UPI पिन सेट (यदि ग्राहक द्वारा खाते के लिए पहले से सेट नहीं किया गया है)

अधिकतर मर्चेंट एप्लिकेशन SMS भेजने की अनुमति नहीं लेते हैं। यह एक अतिरिक्त बिंदु और संभावित ड्रॉप ऑफ बिंदु है। उन यूजर के लिए जो SMS भेजने की अनुमति देते हैं, UPI प्लगइन SDK फिर यूजर के डिवाइस को रजिस्टर/बाइंड करने के लिए प्रायोजक बैंक के VMN का उपयोग करके SMS भेजता है। PhonePe पर पिछले सात वर्षों में, हमने SMS भेजने और डिवाइस बाइंडिंग स्टेप में 40% -50% के बीच गिरावट देखी है। इसके अलावा कुछ जोखिम जांच भी की जानी चाहिए ताकि यह सुनिश्चित किया जा सके कि SMS आधारित डिवाइस रेजिटर्ड और बाइंडिंग में कोई धोखाधड़ी न हो। इन धोखाधड़ी की जाँच करने का दायित्व उस एप्लिकेशन पर है जो पेमेंट प्रक्रिया को सक्षम कर रहा है। इसके बाद वैकल्पिक स्टेप #4 आता है। नए UPI यूजर के लिए, पिन सेट के लिए डेबिट कार्ड नंबर दर्ज करना आवश्यक है। अपने अनुभव से, हमने देखा है कि बड़ी संख्या में यूजर के पास डेबिट कार्ड नहीं हैं, हालांकि उनके पास एक बैंक खाता हो सकता है जिसे UPI सक्षम किया जा सकता है। इन सभी चुनौतियों को हल करने के लिए मर्चेंट एप्लिकेशन को महत्वपूर्ण फोकस और निवेश की आवश्यकता होगी।

जब बात आती है कि उनके एप्लिकेशन पर ऑनबोर्डिंग प्रक्रिया कहां से शुरू की जा सकती है तो मर्चेंट के लिए दो विकल्प हैं:

1. पेमेंट पाथ में जब कोई यूजर UPI का उपयोग करके पेमेंट करने का प्रयास करता है
2. पेमेंट पाथ के बाहर (पेमेंट सेटिंग जहां यूजर अपनी सभी पेमेंट जानकारी मैनेज कर सकते हैं)

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

यूजर को शामिल करने में उपरोक्त चुनौतियों को देखते हुए, इसे अपनाना एक चुनौती होगी।

2. प्रत्येक नई UPI कार्यक्षमता के विकास के लिए पेमेंट ऐप पर निर्भरता

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

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

UPI प्लगइन मॉडल व्यापारी अनुप्रयोगों पर निम्नलिखित जिम्मेदारियाँ भी डालता है:

1. नई UPI सुविधाओं का परिचय और स्थिरीकरण
2. UPI प्लगइन फ्रेमवर्क के तहत NPCI द्वारा जारी प्रासंगिक दिशानिर्देशों/सर्कुलर का अनुपालन
3. ऑनबोर्डिंग और डीलिंकिंग प्रक्रिया का रखरखाव और समर्थन। उदाहरण: आज डेबिट कार्ड के साथ पिन सेट/रीसेट सक्षम है। आधार आधारित OTP नया विकल्प है और इसमें नई सुविधाएं भी जोड़ी जाती रहेंगी
4. खाता अधिग्रहण जैसी धोखाधड़ी को रोकने के लिए UPI ऑनबोर्डिंग के लिए जोखिम मैनेजमेंट
5. सभी संपर्क बिंदुओं पर ग्राहक सहायता – ग्राहक ऑनबोर्ड करने में सक्षम नहीं है, पिन रीसेट करने में सक्षम नहीं है, पैसा डेबिट हो गया है लेकिन लेनदेन लंबित है (जिसे UPI में DCR कहा जाता है), आदि।
6. प्रायोजक बैंक SDK द्वारा विवाद प्रबंधन (UDIR) कार्यक्षमता के लिए एकीकरण और समर्थन प्रदान किया गया। UPI प्लगइन लेनदेन के लिए सभी योग्य ग्राहक शिकायतों और विवादों को UDIR के माध्यम से भेजा जाना चाहिए
7. UPI से संबंधित किसी भी समस्या के लिए UPI प्लगइन फ्लो के माध्यम से प्रायोजक बैंक ऐप का प्रचार – सभी यूजर ने प्रायोजक बैंक ऐप डाउनलोड नहीं किया होगा जो UPI का समर्थन करता है
8. डेटा स्थानीयकरण और ऐप सुरक्षा ऑडिट आवश्यकताओं को पूरा करना
   उपरोक्त सभी और बहुत कुछ आज पेमेंट ऐप्स द्वारा किया जा रहा है क्योंकि वे UPI पेमेंट कार्यक्षमता प्रदान करने के व्यवसाय में हैं। हालाँकि, एक व्यापारी के लिए मुख्य व्यवसाय पेमेंट नहीं है। यह उनके व्यवसाय के लिए सहायक है।

निष्कर्ष

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

बस्ती। दुबौलिया थाना क्षेत्र के रामजानकी मार्ग बैरागल गांव के सामने बीती रात अज्ञात लोगों द्वारा एक गल्ला व्यवसायी को लकड़ी के बेट व लोहे के राड से मारपीट कर घायल कर व्यवसायी के जेब में रखा करीब पांच हजार रुपए व मोबाइल लेकर चलता बने।‌घायल व्यवसाई का इलाज जिला अस्पताल में चल रहा है। पीड़ित के चाचा ने अज्ञात के खिलाफ तहरीर दे कर कार्रवाई की मांग की है। जानकारी के अनुसार थाना क्षेत्र के बैरागल गांव निवासी गोविंद की बैरागल गांव के सामने रामजानकी मार्ग पर किराना एवं गल्ले की दुकान है।‌

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

आस पास के लोग हल्ला सुन कर आगे बढ़े तभी मोटरसाइकिल सवार तीनों लोग भाग गये । परिजन इलाज के लिए सीएचसी कलवारी ले गये । जहां पर प्राथमिक उपचार के बाद जिला अस्पताल रेफर कर दिया गया। घायल के चाचा अशोक कुमार ने दुबौलिया पुलिस को अज्ञात मोटरसाइकिल सवार के खिलाफ तहरीर दे कर कार्रवाई की मांग की है।