बांग्लादेश: bKash, Nagad और बैंक अकाउंट एक-दूसरे की जगह नहीं ले सकते

«bKash और Nagad एक ही API से जोड़ देंगे» — यह वादा कुछ नहीं बताता कि पैसा किन अकाउंट में आएगा। बांग्लादेश में प्रोसेसिंग के लिए मुख्य सवाल API से पहले शुरू होता है: पैसा पाने वाला मर्चेंट है, एजेंट है, निजी वॉलेट का मालिक है या पेमेंट इंटरमीडियरी? इन भूमिकाओं के उद्देश्य, एक्सेस की शर्तें और पाबंदियाँ अलग हैं। उपयोगकर्ता का जाना-पहचाना फ़ोन नंबर अभी क़ानूनी और लेखा ढाँचे को स्पष्ट नहीं करता।

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

मिलती-जुलती स्क्रीन के पीछे चार भूमिकाएँ

निजी ट्रांसफ़र, मर्चेंट पेमेंट, एजेंट का नक़दी वाला काम और किसी कंपनी का पेआउट अलग-अलग ट्रांज़ैक्शन हैं। Bangladesh Bank घरेलू MFS सेवाओं में P2P, P2B और B2P का अलग से वर्णन करता है। इसलिए «वॉलेट ट्रांसफ़र स्वीकार करता है» वाक्य यह साबित नहीं करता कि उस अकाउंट को दूसरी कंपनियों का राजस्व बड़े पैमाने पर जमा करने के लिए इस्तेमाल करने की अनुमति है। ज़रूरत पुष्ट भूमिका की है, सिर्फ़ चलते हुए बटन की नहीं।

bKash Merchant के ऑनबोर्डिंग फ़ॉर्म में दुकान, संपर्क व्यक्ति, NID, ट्रेड लाइसेंस और बैंक अकाउंट की जानकारी माँगी जाती है। यह बाद में जाँच वाला आवेदन है, ऑटोमैटिक मंज़ूरी नहीं। छोटे रिटेल और f-commerce कारोबारों के लिए अलग से Personal Retail Account भी है। यहाँ Personal नाम आसानी से भ्रम पैदा करता है: ऑपरेटर PRA को साफ़ तौर पर बिज़नेस अकाउंट में गिनता है।

PRA के प्रकाशित पेज पर पहचान और SIM की अलग आवश्यकताएँ दी गई हैं, साथ ही भुगतान प्राप्ति की सीमा 30 000 BDT प्रति ट्रांज़ैक्शन और प्रति दिन, तथा 500 000 BDT प्रति माह। ये आँकड़े ख़ास इसी प्रोडक्ट के हैं, जिसे 12 अक्टूबर 2026 को जाँचा गया, और पूरे bKash का वर्णन नहीं करते। अनुबंध पर हस्ताक्षर से पहले चुनी गई कैटेगरी की मौजूदा तालिका लेनी चाहिए। एक अकाउंट प्रकार की लिमिट को दूसरे के वादे के रूप में इस्तेमाल नहीं किया जा सकता।

जब बिक्री दस्तावेज़ों से आगे निकल जाए, तो Nagad से क्या पूछें

सिर्फ़ इसलिए कि दोनों प्रोडक्ट मोबाइल वॉलेट जैसे दिखते हैं, bKash के स्टेटस, refund API और नियम Nagad पर लागू नहीं किए जा सकते। Nagad के जाँचे गए सार्वजनिक लिमिट पेज से भरी हुई संख्यात्मक तालिका नहीं मिल सकी। इसलिए यहाँ कोई सार्वभौमिक मौजूदा लिमिट जानबूझकर नहीं दी गई है। यह जाँच की एक ठोस सीमा है, यह दावा नहीं कि लिमिट नहीं हैं।

व्यावसायिक प्रस्ताव के लिए प्रदाता की क़ानूनी इकाई, merchant प्रोडक्ट का सटीक नाम, कलेक्शन की शर्तें, रिपोर्ट का नमूना, दिशा-वार लिमिट और इंटीग्रेशन दस्तावेज़ का मौजूदा संस्करण माँगें। अगर एग्रीगेटर इस्तेमाल हो रहा है, तो पता करें कि Nagad के साथ अनुबंध का पक्ष कौन है और ग़लत स्टेटस के लिए कौन ज़िम्मेदार है। डेमो की या अनौपचारिक लाइब्रेरी यह साबित नहीं करती कि आपके कारोबार के लिए production उपलब्ध है।

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

पेमेंट डिटेल्स और सबूत: फ़ोन नंबर काफ़ी नहीं

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

दस्तावेज़ी गेटवे मॉडल का उदाहरण SSLCOMMERZ है: tran_id दुकान तय करती है, val_id जाँच के लिए इस्तेमाल होता है, bank_tran_id बैंक की ओर का है। VALIDATED का मतलब सफल ट्रांज़ैक्शन का दोबारा वैलिडेशन है, दूसरा भुगतान नहीं। Refund के अपने refund_trans_id और refund_ref_id होते हैं; अनुरोध सफलतापूर्वक बनना refunded स्टेटस के बराबर नहीं है। ये ख़ास SSLCOMMERZ के फ़ील्ड हैं, bKash या Nagad का नेटिव स्पेसिफ़िकेशन नहीं। गेटवे दस्तावेज़।

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

बैंक एक और परत है, बड़ा वॉलेट नहीं

Bangladesh Bank, BEFTN, NPSB और RTGS को अलग करता है। BEFTN बैच एक्सचेंज से जुड़ा है, NPSB संबंधित ट्रांज़ैक्शन की इंटरबैंक स्विचिंग से, और RTGS तय कामकाजी समय में रियल-टाइम ग्रॉस सेटलमेंट से। सभी बैंक भुगतानों के लिए एक जैसी समय-सीमा का वादा नहीं किया जा सकता। चुना गया बैंक, चैनल, प्रोसेसिंग शेड्यूल और उस अकाउंट प्रकार के नियम चाहिए।

मर्चेंट सेटलमेंट के लिए पूछें कि MFS भुगतान कहाँ ख़त्म होता है और बैंक में निकासी कहाँ शुरू होती है। कलेक्शन कमीशन, निकासी, रिफ़ंड और संभावित करेंसी कन्वर्ज़न इकोनॉमिक्स की अलग-अलग लाइनें हैं। अगर ख़रीदार ने 1 000 BDT दिए, तो कम बैंक प्राप्ति को अपने-आप कम भुगतान नहीं मानना चाहिए: पहले अनुबंध के अनुसार कटौतियाँ जाँचें। उलटी ग़लती है — जब पहले से दर्ज भुगतानों का सेटलमेंट बैच आए, तो पूरी रक़म दूसरी बार जोड़ देना।

वर्जित गतिविधि नाम बदलने से मर्चेंट कारोबार नहीं बन जाती

bKash की आधिकारिक सूचना में जुआ और ऑनलाइन बेटिंग में भाग लेना या उसका आयोजन साफ़ तौर पर वर्जित कैटेगरी में गिनाए गए हैं। ऑपरेटर सेवा बंद करने और क़ानूनी कार्रवाई का प्रावधान रखता है। इसलिए ऐसा ट्रैफ़िक «सामान्य merchant» पर लेने का प्रस्ताव ग्राहक के विदेशी लाइसेंस से वैध नहीं हो जाता।

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