वयस्क क्लासीफाइड्स में चार्जबैक: आपके मर्चेंट अकाउंट को असल में किस चीज़ से खतरा है

चार्जबैक की असली समस्या वह नहीं है जो मान ली जाती है

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

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

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

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

लिस्टिंग कारोबार में विवाद असल में किस वजह से होते हैं

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

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

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

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

दो सीमाएँ जिन पर एक प्रोसेसर असल में नज़र रखता है

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

मास्टरकार्ड का नियम सार्वजनिक और सटीक है: कोई व्यापारी Excessive Chargeback Merchant प्रोग्राम में तब आता है जब वह एक कैलेंडर महीने में कम-से-कम 100 चार्जबैक दर्ज करता है और चार्जबैक-टु-ट्रांज़ैक्शन अनुपात 1.5% या उससे ज़्यादा होता है, दोनों शर्तें एक साथ ज़रूरी हैं, अकेली कोई एक नहीं। 300 चार्जबैक और 3% अनुपात पर एक और सख़्त स्तर लागू होता है। यह अनुपात खुद उसी महीने की बिक्री के मुक़ाबले नहीं मापा जाता; यह मौजूदा महीने के विवादों की तुलना किसी हाल के महीने की मात्रा से करता है, इसलिए एक अच्छे महीने के बाद आने वाला एक कमज़ोर महीना कागज़ पर यह आँकड़ा बढ़ा सकता है, भले ही कारोबार चलाने के तरीक़े में कुछ न बदला हो। दोबारा बाहर निकलने के लिए एक नहीं, लगातार तीन साफ़ महीने चाहिए।

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

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

अलर्ट, सबूत और जवाब देने की आदत

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

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

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

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

क्रम से क्या करना है

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

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

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

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

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