UPI: ग्राहक स्टोर पर लौट आया, पर क्या ऑर्डर डिलीवर कर सकते हैं?

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

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

पहले मैकेनिज़्म समझें

NPCI UPI को इंस्टेंट पेमेंट सिस्टम बताता है और मर्चेंट इंटीग्रेशन के तरीके गिनाता है, जिनमें QR और Intent शामिल हैं। इससे शब्दावली समझने में मदद मिलती है, लेकिन इसकी गारंटी नहीं मिलती कि ऐतिहासिक रूप से बताया गया हर विकल्प किसी ख़ास बिज़नेस के लिए उपलब्ध है। UPI पर NPCI के जवाब।

• Intent: पेमेंट पेज ट्रांज़ैक्शन के डेटा के साथ किसी कम्पैटिबल पेमेंट ऐप को खोलता है, जहाँ ग्राहक भुगतान जारी रखता है।
• QR: ग्राहक उपयुक्त ऐप से कोड में दर्ज पेमेंट जानकारी स्कैन करता है।
• Collect: रिक्वेस्ट मॉडल में भुगतान करने वाले के UPI ID पर पुष्टि के लिए रिक्वेस्ट भेजी जाती है।

यह मैकेनिज़्म NPCI की प्रोडक्ट सामग्री में बताया गया है। पुराने विवरण को फ़्लो की बनावट की व्याख्या की तरह पढ़ना चाहिए, उसकी मौजूदा उपलब्धता की पुष्टि की तरह नहीं। NPCI की प्रोडक्ट बुकलेट।

लागू नियम अलग से जाँचने होंगे। उदाहरण के लिए, PayU नए मर्चेंट्स को Intent और QR की ओर भेजता है और Collect को बताए गए अपवादों के लिए रखता है। रिक्वेस्ट मॉडल के आसपास इंटीग्रेशन बनाने से पहले अपने प्रोवाइडर से सपोर्टेड विकल्प की पुष्टि करें। मर्चेंट पेमेंट स्वीकार करना और निजी P2P ट्रांसफ़र एक-दूसरे का विकल्प नहीं माने जा सकते। PayU का दस्तावेज़।

प्रक्रिया को एक ऑर्डर से जोड़ें

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

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

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

देर से आने वाले जवाब के लिए तैयार रहें

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

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

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

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

जाँच की जगह सुविधाजनक सबूत न रखें

स्क्रीनशॉट टिकट ढूँढने में मदद करता है, लेकिन मर्चेंट को उपलब्ध पेमेंट रिकॉर्ड में पुष्टि की जगह नहीं ले सकता। कर्मचारियों को UPI PIN बताने को नहीं कहना चाहिए। NPCI भी चेतावनी देता है: PIN डालकर QR स्कैन करना पैसा भेजने के लिए है, पैसा पाने के लिए नहीं। धोखाधड़ी पर NPCI की चेतावनियाँ।

रिफ़ंड के लिए तय प्रक्रिया इस्तेमाल करें, पैसा «पाने» वाली रिक्वेस्ट नहीं। NPCI मर्चेंट के स्टेटस से जुड़े सवाल और शिकायतें एक्वायरर बैंक को भेजने की सलाह देता है। मर्चेंट्स के लिए NPCI FAQ।

QR की मियाद ख़त्म हुई, पर पैसा बाद में आया

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

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

एक ऑर्डर पर दो पुष्ट पेमेंट हो सकते हैं

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

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

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