कार्ड टेस्टिंग: पहला चार्जबैक आने से पहले आपके चेकआउट पर असल में क्या होता है

रिजेक्शन की एक बाढ़ जो अभी चार्जबैक नहीं बनी

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

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

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

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

इसके लिए आपको फ्रॉड एनालिस्ट बनने की ज़रूरत नहीं है। सिर्फ़ यह जानना ज़रूरी है कि आपके डैशबोर्ड की वह बाढ़ असल में क्या है, ताकि आप उसे बैकग्राउंड नॉइज़ समझना बंद कर सकें।

कार्ड टेस्टिंग असल में क्या है, और आपके जैसा चेकआउट क्यों आसान निशाना है

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

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

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

J.P. Morgan की मर्चेंट्स के लिए बनी गाइड इन अटैक्स के लिए निशाना चुनने का पैटर्न साफ़ कर देती है: धोखेबाज़ ऐसे मर्चेंट्स की तलाश करते हैं जो अटैक को पहचानने या उससे बचाव करने के लिए तैयार नहीं हैं, और अक्सर उन्हें वही इस्तेमाल करते हैं जिसे गाइड "मूल" कहती है, यानी एक बीच का निशाना जिसका इस्तेमाल सिर्फ़ यह जानने के लिए होता है कि कोई अकाउंट अभी भी एक्टिव है या नहीं। एक छोटा या मध्यम आकार का क्लासिफाइड्स ऑपरेटर जिसका चेकआउट बेहद सीधा है, और जो अक्सर एक सस्ते हाई-रिस्क गेटवे पर चलता है जिसमें Stripe जैसा प्लेटफ़ॉर्म डिफ़ॉल्ट रूप से देने वाला CAPTCHA और मशीन-लर्निंग बचाव शामिल नहीं होता, यह विवरण किसी बड़े रिटेलर से ज़्यादा उस पर फ़िट होता है, साइट किस बारे में है इसलिए नहीं बल्कि वह क्या बनाने का खर्च उठा सकता है इसलिए।

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

किसी के कुछ भी डिस्प्यूट करने से पहले यह आपको क्या कीमत चुका रहा है

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

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

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

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

हाई-रिस्क अकाउंट वही अटैक ज़्यादा बुरी तरह क्यों सहता है

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

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

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

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

इस हफ़्ते क्या जाँचें और क्या बदलें

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

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

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

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

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