
10 अगस्त 20266 मिनट का पाठАдминистратор
PSP चुन रहे हैं? एक बुरा शुक्रवार और कामकाज का आखिरी दिन दिखाने को कहें
खोए हुए रिस्पॉन्स, अटके रिफ़ंड और इंटीग्रेशन से बाहर निकलने पर प्रोवाइडर को परखें। डेमो के वादों की जगह सबूतों की सूची।
सुंदर डेमो दिखाता है कि सफल पेमेंट कैसे होता है। PSP का चुनाव करते समय दूसरा दृश्य ज़्यादा काम का है: शुक्रवार, रिस्पॉन्स खो गया, रिफ़ंड अटक गया, विशेषज्ञ छुट्टी पर है। उससे भी ज़्यादा उपयोगी है उस दिन को पहले से समझ लेना जब आप छोड़ने का फ़ैसला करेंगे। ये दोनों जाँचें फ़ीचर की लंबी सूची से बेहतर बताती हैं कि पार्टनर पर निर्भरता की कीमत क्या है।
सामान्य SLA की जगह किसी खास दिन का विश्लेषण माँगें
काल्पनिक सिनेरियो: शुक्रवार को आपने 40 यूरो के 500 पेमेंट लिए, कुल 20 000 यूरो। शाम को कुछ नोटिफ़िकेशन देर से आए, सोमवार सुबह रिफ़ंड के अनुरोध आए। उम्मीदवार से कहें कि वह दिखाए कि ऑपरेटर, डेवलपर और अकाउंटेंट क्या देखेंगे।
कौन-से इवेंट दोबारा डिलीवर होंगे? अगर API का रिस्पॉन्स खो गया, तो ट्रांज़ैक्शन कैसे ढूँढें? फ़ेल हुआ पेआउट कहाँ दिखता है? रात में कौन जवाब देता है और शिकायत के लिए कौन-सा डेटा चाहिए? मीटिंग का अच्छा नतीजा रिपोर्ट के उदाहरण, डॉक्यूमेंटेशन और तय किए गए कॉन्टैक्ट हैं, न कि यह वादा कि "सपोर्ट हमेशा मदद करेगा"।
टेस्ट का लॉग खुद रखें। हर सिनेरियो के लिए अपेक्षित व्यवहार, असली नतीजा, जाँच की तारीख और अनसुलझा सवाल लिखें। सफल पेमेंट के साथ डिक्लाइन, दोबारा रिक्वेस्ट, रिफ़ंड और ग्राहक के पेज बंद करने की स्थिति भी जाँचें। पायलट प्रोवाइडर के साथ तय होना चाहिए और प्रोडक्ट के अनुमत इस्तेमाल के अनुरूप होना चाहिए।
पहला फ़िल्टर: क्या वे सच में आपका बिज़नेस स्वीकार करते हैं?
सभी उम्मीदवारों को एक जैसा विवरण भेजें: कानूनी इकाई, असली प्रोडक्ट, ग्राहकों के देश, करेंसी, औसत बिल, अपेक्षित टर्नओवर, डिलीवरी की समय-सीमा और रिफ़ंड की प्रक्रिया। P2P प्लेटफ़ॉर्म के लिए अलग से बताएँ कि विक्रेता कौन है, खरीदार कौन है और स्वीकार किया गया पैसा किसका है। विवरण की जगह "ऑनलाइन सर्विसेज़" जैसा धुँधला वाक्य न लिखें।
मॉडल के स्वीकार्य होने की लिखित पुष्टि माँगें। स्पष्ट करें कि कॉन्ट्रैक्ट में पक्ष कौन होगा, हर सर्विस किस कानूनी इकाई के तहत दी जाती है और क्या वह इकाई प्रोवाइडर के खातों में पेमेंट पाने वाले से मेल खाती है। लॉन्च की योजना के लिए "हम ऐसा जोड़ लेते हैं" जैसा मौखिक जवाब काफ़ी नहीं है।
लाइसेंस और अनुमति की जाँच देश पर निर्भर करती है। उदाहरण के लिए, ब्रिटेन में FCA सलाह देता है कि सिर्फ़ कंपनी का नाम नहीं, बल्कि ज़रूरी सर्विस की अनुमति भी जाँचें। यह स्थानीय प्रक्रिया का उदाहरण है, इस बात की पुष्टि नहीं कि एक देश का रजिस्ट्रेशन किसी भी दूसरे देश में काम करने का अधिकार देता है।
सभी कटौतियों के बाद का पैसा दिखाने को कहें
काल्पनिक हिसाब आगे बढ़ाएँ। 20 000 यूरो के टर्नओवर पर फ़ीस 400 यूरो है, नई रिज़र्व होल्डिंग 1 000 यूरो, रिफ़ंड 600 यूरो। कोई और हलचल न हो तो पेआउट के लिए 18 000 यूरो बचते हैं। यहाँ फ़ीस 2% है, जबकि तुरंत मिलने वाले पेआउट में कमी 10% है। ये अलग-अलग इंडिकेटर हैं, और सभी आँकड़े सिर्फ़ उदाहरण के लिए चुने गए हैं।
उम्मीदवार से हर कटौती का आधार, पैसा उपलब्ध होने की तारीख और पेआउट शेड्यूल अलग से बताने को कहें। ऊपर के उदाहरण के लिए कैलेंडर माँगें: कौन-सी रकम किस दिन बैंक में आएगी, क्या रुका रहेगा और कौन-सी शर्तें अभी पूरी करनी हैं। यह भी पूछें कि तय समय में न पहुँचे पेआउट की जाँच कौन करेगा।
पाँच ज़रूरतें, हर एक के साथ सबूत
फ़ाइनलिस्ट के लिए एक छोटा जाँच कार्ड तैयार करें। हर ज़रूरत के सामने अपेक्षित आर्टिफ़ैक्ट लिखें। पैसे के मिलान के लिए आइडेंटिफ़ायर वाली गुमनाम रिपोर्ट चाहिए। गलती के बाद रिकवरी के लिए डॉक्यूमेंटेशन और टेस्ट का नतीजा चाहिए। सपोर्ट के कामकाज के लिए पुष्ट चैनल और एस्केलेशन की प्रक्रिया चाहिए। एक्सेस मैनेजमेंट के लिए रोल की जाँच चाहिए। एग्ज़िट की संभावना के लिए लिखी हुई प्रक्रिया और साफ़ एक्सपोर्ट फ़ॉर्मेट चाहिए।
हर जवाब को तीन में से एक स्थिति दें: पुष्ट, वादा किया गया, जाँचा नहीं गया। सुंदर प्रेज़ेंटेशन के बाद मैनेजर के वादे को तकनीकी तथ्य न बना दें। अगर उम्मीदवार अभी कोई फ़ंक्शन नहीं दिखा सकता, तो निर्भरता और वह शर्त लिखें जिसमें उसकी कमी लॉन्च को रोक देगी। इससे यह झूठा एहसास हुए बिना बातचीत जारी रहती है कि सारे सवाल बंद हो गए।
समझौता आम तौर पर एक ही सर्विस की सुविधा और उस पर निर्भरता की कीमत के बीच होता है। एक डैशबोर्ड टीम के लिए इंटरफ़ेस की संख्या घटाता है, लेकिन यह जाँचना ज़रूरी है कि क्या उस डैशबोर्ड के बिना इतिहास दोबारा बनाया जा सकता है। कई प्रोवाइडर चुनने का विकल्प दे सकते हैं, लेकिन रिकंसिलिएशन, सपोर्ट और स्टेटस के अलग-अलग नियम जोड़ देंगे। दूसरा इंटीग्रेशन अपने आप में तैयार बैकअप प्रोसेस नहीं बनाता।
एक्सेस और कार्ड डेटा: अलग जाँच
कार्ड डेटा से जुड़ी ज़िम्मेदारियों के बँटवारे का विवरण माँगें। PCI SSC ज़ोर देता है कि प्रोसेसिंग किसी कॉन्ट्रैक्टर को सौंपने से मर्चेंट की सारी ज़िम्मेदारियाँ खत्म नहीं होतीं। सर्टिफ़िकेट या लोगो आपके अपने इंटीग्रेशन की सीमाओं की समझ की जगह नहीं ले सकता।
यह भी जाँचें कि क्या इंटीग्रेशन को सिर्फ़ ज़रूरी अधिकार दिए जा सकते हैं। Stripe सीमित API कीज़ की सलाह देता है, जिनकी अनुमतियाँ खास कामों के लिए होती हैं। उम्मीदवार से ऐसा ही बँटवारा दिखाने को कहें, जिसमें ट्रांज़ैक्शन देखने और पेआउट डिटेल बदलने के स्वतंत्र अधिकार भी शामिल हों।
साइन करने से पहले एग्ज़िट की रिहर्सल करें
दस काल्पनिक ऑर्डर लें: सफल, आंशिक रूप से रिफ़ंड हुए, खुले विवाद वाले और पेंडिंग पेआउट वाले। दिखाने को कहें कि नई बिक्री रुकने के बाद कौन-से रिकॉर्ड उपलब्ध रहेंगे, रिफ़ंड कौन पूरे कर पाएगा और हलचल का इतिहास कैसे मिलेगा। पेमेंट डेटा और टोकन के ट्रांसफ़र को अलग से देखें: पक्षों की पुष्टि और अनुमत सुरक्षित प्रक्रिया के बिना यह न मानें कि उन्हें ले जाया जा सकता है।
फिर टीम की मेहनत का आकलन करें। अगर एक असामान्य ट्रांज़ैक्शन के लिए तीन मैनुअल एक्सपोर्ट और ईमेल पर मिलान चाहिए, तो इसे तुलना में शामिल करें। सौ शिकायतों पर काल्पनिक चार अतिरिक्त मिनट 400 मिनट का काम बनाते हैं, भले ही प्रति ट्रांज़ैक्शन टैरिफ़ कम हो। यह वर्कलोड का हिसाब है, किसी खास सप्लायर की क्वालिटी का अनुमान नहीं।
चुनाव के फ़ैसले में हर बचे हुए रिस्क का ओनर तय करें। "लॉन्च के बाद देख लेंगे" को एक ठोस शर्त में बदलना चाहिए: और क्या जाँचा जाएगा, किस ट्रांज़ैक्शन से पहले और किसके द्वारा। वरना खुला सवाल प्रेज़ेंटेशन से तो गायब हो जाएगा, लेकिन सपोर्ट की पहली रात की कतार में फिर दिखेगा।
झूठी सटीकता के बिना फ़ैसला कैसे लें
ज़रूरतों को अनिवार्य और वांछनीय में बाँटें। अस्वीकार्य बिज़नेस मॉडल, कॉन्ट्रैक्ट का अस्पष्ट पक्ष या पैसे का मिलान न हो पाना किसी सुविधाजनक इंटरफ़ेस से पूरा नहीं होता। अनिवार्य फ़िल्टर पार करने वालों में कुल लागत और टेस्ट के एक ही सेट के नतीजों की तुलना करें।
चयन का अंतिम नतीजा लॉन्च की शर्तों वाला फ़ैसला है। चुने गए उम्मीदवार, पुष्ट सीमाएँ, खुले सवाल और वे काम लिखें जो उनके सुलझने से पहले शुरू नहीं किए जा सकते। प्रोडक्ट और भूगोल के बारे में शुरुआती मान्यताएँ भी सहेजें: उनके बदलने पर उपयुक्तता की जाँच दोहरानी होगी।
सफल पायलट और जाँची गई अनुमतियाँ इस बात की गारंटी नहीं देतीं कि शर्तें या पाबंदियाँ कभी नहीं बदलेंगी।
टिप्पणियाँ · 0
अभी कोई टिप्पणी नहीं — पहले बनें।
लॉग इन · टिप्पणी करने के लिए लॉग इन करें।