पाकिस्तान: Raast, JazzCash और easypaisa में ट्रांसफ़र और मर्चेंट पेमेंट का फ़र्क़

«JazzCash से भुगतान हुआ» — रिकंसिलिएशन के लिए इतना कहना काफ़ी नहीं। JazzCash और easypaisa या Raast, किसी के भी मामले में ख़रीदार ने ट्रांसफ़र किया हो सकता है, मर्चेंट पेमेंट गेटवे से भुगतान किया हो सकता है या बाद में भुगतान के लिए टोकन लिया हो सकता है। इसी तरह Raast किसी दूसरे प्रदाता के ऐप के अंदर भी दिख सकता है। फ़ोन पर दिखने वाला ब्रांड ट्रांज़ैक्शन का प्रकार नहीं बताता, और भुगतान के निर्देश दिखना पैसा मिलने के बराबर नहीं है।

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

Raast ID और merchant alias अलग-अलग काम करते हैं

SBP, P2P के लिए Raast ID को अकाउंट से जुड़े मोबाइल नंबर के रूप में बताता है। ट्रांसफ़र रजिस्टर्ड ID या IBAN पर भेजा जा सकता है; भेजने वाले के पास अपना Raast ID होना ज़रूरी नहीं। व्यक्तियों के FAQ में लिखा है कि एक ID एक अकाउंट से जुड़ा होता है और उसे दूसरे अकाउंट से दोबारा जोड़ा जा सकता है। इस विवरण में रेल ख़ुद घरेलू ट्रांसफ़र के लिए है, और सटीक लिमिट बैंक से पता करनी चाहिए।

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

Raast P2M में QR, merchant alias, IBAN और Request to Pay की सुविधा है, जिसमें तुरंत या बाद की तय तारीख़ पर भुगतान हो सकता है। SBP ऑनबोर्डिंग पर बिज़नेस वेरिफ़िकेशन और ऐसे रिफ़ंड अनुरोध संभालने की क्षमता माँगता है, जिन्हें मर्चेंट स्वीकार या अस्वीकार करता है। पुष्टि या अस्वीकृति की तुरंत सूचना का प्रावधान भी है। ये भागीदारों के लिए आवश्यकताएँ हैं, इस बात का सबूत नहीं कि किसी भी बैंक ने आपके कारोबार को सारी सुविधाएँ पहले ही दे दी हैं। P2M पर सर्कुलर।

Request to Pay भुगतान का प्रस्ताव है, डेबिट नहीं

चेकआउट के अंदर अनुरोध बनाने, भुगतानकर्ता की सहमति और वित्तीय नतीजे को अलग रखें। अपने रिकॉर्ड के लिए order ID, attempt ID, प्रदाता की ओर से अनुरोध का आइडेंटिफ़ायर, वैधता अवधि, अपेक्षित रक़म, लाभार्थी और अंतिम transaction reference उपयोगी हैं। यह सुझाया गया डेटा मॉडल है; API फ़ील्ड के असली नाम आपका MSP तय करता है, यह लेख नहीं।

एक अभ्यास उदाहरण: ग्राहक ने Later अनुरोध खोला, फिर ख़ुद IBAN पर ट्रांसफ़र भेज दिया। अगर प्रोसेसिंग दोनों रास्तों को अलग-अलग ऑर्डर मानती रहे, तो दोहरा भुगतान और दोहरी डिलीवरी हो सकती है। एक ही ऑर्डर के वैकल्पिक प्रयासों को मिलाने की नीति चाहिए। पुष्ट अतिरिक्त भुगतान अलग से निपटाया जाता है — उसे ग्राहक के अगले ऑर्डर में घुलाया नहीं जाता और चैट में मिले किसी भी पते पर नहीं भेजा जाता।

JazzCash: फ़ील्ड का सटीक अर्थ बनाए रखें

गेटवे के प्रकाशित दस्तावेज़ में pp_TxnRefNo मर्चेंट तय करता है, pp_Amount तय मौद्रिक स्केल में बिना दशमलव विभाजक के भेजा जाता है, और pp_TxnCurrency में PKR होता है। ट्रांज़ैक्शन की समय-सीमा और pp_SecureHash भी इस्तेमाल होते हैं। रिफ़ंड reference के ज़रिए मूल ट्रांज़ैक्शन से जुड़ता है। यह इंटरफ़ेस का एक ख़ास प्रकाशित संस्करण है: production से पहले इसे आपको दिए गए स्पेसिफ़िकेशन से मिलाना चाहिए, जिसमें सिग्नेचर और स्टेटस का क्रम भी शामिल है।

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

JazzCash ऑनबोर्डिंग विवरण में दस्तावेज़ों की जाँच, बायोमेट्रिक, अनुबंध पर हस्ताक्षर और बिज़नेस के नाम पर रजिस्ट्रेशन बताता है; eligibility में CNIC और NTN का ज़िक्र है। consumer वॉलेट होना इन चरणों की जगह नहीं लेता। गेटवे के उपलब्ध पेमेंट तरीक़ों में मोबाइल अकाउंट, कार्ड और vouchers शामिल हैं, इसलिए सिर्फ़ JazzCash का नाम यह तय नहीं करता कि ख़रीद का पैसा किस साधन से आया।

easypaisa: टोकन पुष्ट भुगतान नहीं है

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

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

असली ऑपरेशनल बोझ कहाँ पैदा होता है

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

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

पेमेंट सर्विस का लाइसेंस जुए का लाइसेंस नहीं है

Pakistan Code में जुए की रोकथाम पर विशेष क़ानून है। इसलिए विदेशी gambling लाइसेंस और रेगुलेटेड वॉलेट से जुड़ाव पाकिस्तान में ऐसे कारोबार की वैधता साबित नहीं करते। तकनीकी तरीक़ों का यह विश्लेषण पाबंदियों से बचने का रास्ता नहीं है। व्यावसायिक लॉन्च से पहले लागू स्थानीय क़ानूनी आधार और सेवा देने वाली संस्था से कैटेगरी की स्पष्ट मंज़ूरी चाहिए।

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