क्रेडिट कार्ड नेटवर्क के दुरुपयोग की अंडरग्राउंड दुनिया
(chargebackstop.com)- एक SaaS सेवा ने कार्ड approval decline rate में अचानक बढ़ोतरी को ट्रैक करते हुए card testing attack का पता लगाया, जिसमें auto-generated नाम और अजीब email domains इस्तेमाल हो रहे थे
- हमला बड़े पैमाने के bot traffic की बजाय प्रति मिनट अधिकतम 4 कार्ड तक के मैनुअल या हल्के automation के ज्यादा करीब था, और कार्डों में एक ही bank, funding source और US-issued होने जैसी समानताएँ थीं
- सार्वजनिक Telegram channels और online tools में BIN, CVC, expiry date, कुछ खास websites पर pass होने की अधिक संभावना वाले card numbers बनाने के तरीके, और Stripe Checkout auto-run tools साझा किए जा रहे थे
- सफल fraudulent payments में से 15% chargeback में बदले, और disputes accept करने, refunds, subscriptions cancel करने और verification के लिए ChatGPT से बने Python scripts का उपयोग हुआ
- Stripe Radar का default risk score अधिकतर मामलों में 0~5 के बीच कम था, जबकि वास्तविक बचाव में प्रति घंटे की failed payment count को सीमित करने वाले custom Radar rules सबसे उपयोगी साबित हुए
card testing attack की खोज और शुरुआती प्रतिक्रिया
- कुछ हफ्ते पहले कार्ड approval decline rate सामान्य से अधिक होने का alert आया
- Stripe dashboard में auto-generated लगने वाले नामों और अजीब email domains वाले users की कई failed payments दिखीं
- सेवा ने इसे एक सामान्य card testing attack मानते हुए Stripe Radar सक्रिय किया और checkout में CAPTCHA जोड़ने का काम backlog में डाल दिया
- लगभग उसी समय Pieter Levels और Danny Postma ने भी Twitter पर इसी तरह के हमलों के बारे में साझा किया
- Pieter Levels ने लिखा कि उन्होंने Philippines से आए
Jake Smithनाम के 240 customers को refund और cancel किया, और card testing payments की राशि $7,000 थी - Danny Postma ने लिखा कि
jack smithनाम से fraudulent payments हो रही हैं और Stripe से तेज समाधान की जरूरत है
- Pieter Levels ने लिखा कि उन्होंने Philippines से आए
हमले का पैटर्न मैनुअल के करीब था
- कुछ हफ्तों बाद approval decline rate का alert फिर आया, और अस्थायी Stripe Radar rules जोड़कर प्रतिक्रिया शुरू की गई
- traffic को विस्तार से देखने पर पता चला कि attacker प्रति मिनट अधिकतम 4 कार्ड test कर रहा था, और ज्यादातर समय हमले की तीव्रता और स्थिरता इससे भी कम थी
- Stripe के card testing prevention materials के आधार पर देखें तो इस सेवा का implementation अपेक्षाकृत अच्छी तरह सुरक्षित था
- user को checkout खोलने से पहले login करना पड़ता था
- Payment Element इस्तेमाल हो रहा था और कुछ signals भी उपयोग में थे
- Stripe docs के अनुसार card testing protection का स्तर
excellentके करीब होना चाहिए था
- अतिरिक्त जांच और सहकर्मी समीक्षा के बाद यह निष्कर्ष निकला कि यह traffic मैनुअल हमला या बहुत हल्के automation के करीब था
सार्वजनिक चैनलों में घूमते कार्ड parameters और tools
- हमले में इस्तेमाल किए गए अधिकांश कार्डों में एक जैसी विशेषताएँ थीं
- सभी एक ही bank से जारी हुए थे
- सभी का funding source एक ही था
- सभी US में जारी किए गए थे
- card parameters बहुत ज्यादा समान होने के कारण यह सवाल उठा कि क्या ये सचमुच bank से leak हुए कार्ड थे
- सार्वजनिक रूप से उपलब्ध channels में credit card के BIN, CVC, expiry date, और इन inputs से valid card numbers बनाने वाले tool links मिले
- BIN का मतलब Bank Identification Number है, यानी card number के शुरुआती 6~8 अंक
- funding source बताता है कि कार्ड debit, credit या prepaid है
- सार्वजनिक Telegram channels में Spotify Premium या YouTube Premium को गैरकानूनी तरीके से पाने के निर्देश देने वाले messages भी थे
- एक सार्वजनिक अंडरग्राउंड ecosystem मौजूद था, जहाँ ऐसे card parameters साझा किए जा रहे थे जिनके कुछ खास websites, आमतौर पर SaaS, पर approve होने की संभावना अधिक थी
- इस सेवा पर हुआ हमला भी संभवतः किसी खास private Discord server या Telegram channel से शुरू हुआ मैनुअल हमला था, लेकिन सटीक स्रोत नहीं मिल सका
- सार्वजनिक channels में अक्सर ऐसे संदेश दिखते थे कि कुछ दिनों बाद channel private हो जाएगा, और लगता था कि गतिविधि का बड़ा हिस्सा ऐसी जगहों पर हो रहा था जहाँ पहुँचना संभव नहीं था
- ऐसे कई online tools भी मौजूद थे जो auto-generated card lists लेकर उन्हें किसी मनचाहे Stripe Checkout session पर अपने-आप चला देते थे
- यह अप्रत्याशित था कि पूरी तरह Stripe के end-to-end नियंत्रण वाला Stripe Checkout भी automation के प्रति संवेदनशील हो सकता है
- कुछ tool code Gmail के random invalid email addresses generate कर रहे थे
disputes, refunds और subscription cancellations तक पहुँची बाद की सफाई
- कुछ attackers payments में सफल रहे और उन्होंने वास्तव में products खरीद लिए, जिससे बाद की सफाई की लागत बढ़ गई
- पैमाना समझने के लिए 1 मई के बाद 5 से अधिक failed payments वाले customers को data store से query किया गया
- ChatGPT की मदद से Python script बनाकर उन customers के email domains निकाले गए
- domain list के आधार पर database query करके, उन्हीं domains वाले email addresses से बने सफल payments की सूची निकाली गई
- एक और ChatGPT-generated script से यह जांचा गया कि कौन से payments पहले से dispute में हैं
- सफल fraudulent payments में से 15% chargeback में बदल गए
- chargeback अनुपात: {p:15}
- सभी disputes accept करने और हर मामले में Stripe की £20 fee सहने का फैसला किया गया
- Stripe में minimum-privilege restricted key बनाकर, ChatGPT से chargeback accept करने की script तैयार की गई
- फिर script से सूची के payments निकाले गए, non-dispute payments refund किए गए, और वे payments बनाने वाले customers की active subscriptions cancel की गईं
- refunded payments पर भी सफल payment और refund प्रक्रिया के दौरान Stripe और network fees का नुकसान हो सकता था
- अंतिम verification script से पुष्टि की गई कि सभी payments या तो dispute accepted थे या refunded, और उन customers के पास कोई active subscription बाकी नहीं थी
- ChatGPT ने scripts चलाते समय सावधानी और छोटे sample tests की सलाह दी, scripts की manually review की गई, और customer data, IDs या API keys साझा नहीं की गईं
अमेरिकी बैंकों की approval practices से बढ़ता बोझ
- online payments की दुनिया को कारोबारी दृष्टि से काफी अनुचित माना गया
- dispute जीतने की संभावना कम होती है
- Stripe के अनुसार dispute activity को 0.75% से कम रखना होता है
- व्यापारी dispute जीते या हारे, हर dispute पर £20 देना पड़ता है
- दूसरी ओर banks, खासकर अमेरिकी banks, निम्न स्थितियों में भी payments approve कर सकते हैं
- पूरा नाम गलत हो
- CVV/CVC valid न हो
- expiry date गलत हो
- billing address आंशिक रूप से दिया गया हो और ZIP code भी गलत हो
- इन स्थितियों में भी 3D Secure authentication जरूरी नहीं कि trigger हुआ हो
- सवाल बना रहता है कि सिर्फ सही card number होने पर payment का जोखिम व्यापारी क्यों उठाए
- prepaid cards में ऐसे checks की संभावना सीमित हो सकती है, लेकिन सुधार की गुंजाइश फिर भी है
जो Stripe Radar rules वास्तव में असरदार रहे
- शुरुआती प्रतिक्रिया Stripe Radar को सक्रिय करना थी
- Stripe Radar एक machine learning आधारित solution है जो हर payment को score देता है और कुछ indicators मेल न खाने पर automatic blocking के लिए डिज़ाइन किया गया है
- इस मामले में Radar का default judgement ज्यादा मददगार नहीं था
- अधिकांश fraudulent payments का risk score 0~5 के बीच कम था
- उल्टा कुछ वैध customers दो बार 3D Secure challenge fail करने के बाद block हो गए
- इस अनुभव से customers की किस्मत machine learning के हवाले करने को लेकर चिंता पैदा हुई
- ज्यादा उपयोगी feature Stripe Radar custom rules थे
- 3D Secure challenge request करना
- manual review में भेजना
- पूरी तरह block करना
- Radar rules pseudocode जैसे दिखते हैं, लेकिन वे malicious payment attempts को सीमित करने के लिए काफी जटिल logic व्यक्त कर सकते हैं
- सबसे उपयोगी उपाय था प्रति customer 1 घंटे, 1 दिन और 1 हफ्ते में संभव payment failures की संख्या पर व्यावहारिक सीमा लगाना
- CAPTCHA जोड़ना, failure rates की निगरानी करना, और custom Radar rules साझा करना तब तक के लिए व्यावहारिक प्रतिक्रिया है जब तक banks approvals की जिम्मेदारी अधिक नहीं लेते
लागत आखिरकार व्यापारियों और ग्राहकों पर ही आती है
- payment processor fees, chargeback penalties, engineering cost और platform से निकाले जाने के जोखिम तक, fraud की लागत दुनिया भर के व्यवसाय उठाते हैं
- Stripe द्वारा merchants से £20 chargeback fee लेना भी अनुचित व्यवहार का एक उदाहरण माना गया
- यह लागत अंततः ऊँची कीमतों के रूप में customers पर डाली जाती है
- जिन payment networks पर हम रोज़ निर्भर करते हैं, उनका दुरुपयोग करना आसान है, और किसी कार्ड से charge संभव है या नहीं इसका अंतिम फैसला issuing bank के विवेक पर निर्भर करता है
- जब तक banks approvals में अधिक जिम्मेदारी नहीं लेते, तब तक merchants के पास approval failure rates को बारीकी से देखना, CAPTCHA जोड़ना और Stripe Radar rules को बेहतर बनाना ही लगभग व्यावहारिक विकल्प हैं
1 टिप्पणियां
Hacker News की रायें
सबसे हैरान करने वाली बात यह नहीं कि Stripe payments का दुरुपयोग करने वाले समूह हैं, बल्कि यह है कि लेखक ने ChatGPT से payment processing automation script बनवाई
खास तौर पर दिक्कत यह थी कि वह chargeback processing के लिए थी, और लेख के संदर्भ से लगा कि लेखक में उस script को खुद लिखने या verify करने की technical क्षमता कम थी
Stripe fraud prevention संभाल लेगा, यह मानकर भरोसा टूटने पर नाराज़ होते हुए, वह फिर किसी दूसरी ऐसी technology पर अंधा भरोसा कर रहा है जिसे वह समझता नहीं
समस्या सिर्फ Stripe नहीं है, बल्कि भरोसा कहीं भी सौंपकर सब ठीक होने की उम्मीद करने वाला रवैया है
लेखक ने payment processing नहीं सौंपी थी; उसने उन accounts के chargebacks को scan करके मूल रूप से “accept” button दबाने वाली script बनाई थी
technical क्षमता कम होने का निष्कर्ष कहाँ से आया, यह भी साफ नहीं, और लेख में भी कहा गया था कि “मैंने सभी scripts को ध्यान से review किया और customer data, IDs, API keys share नहीं कीं”
इस प्रक्रिया में उसने बस ChatGPT से script बनाकर समय बचाया
वह non-technical है या सिर्फ समय बचाना चाहता था, यह नहीं पता, लेकिन सच कहूँ तो ऐसी execution की तारीफ होनी चाहिए
इन scripts ने जीवन-मृत्यु या business के core decisions तय नहीं किए, बल्कि bulk data को filter करके manual verification के लायक results जल्दी तैयार करने वाले tools के रूप में काम किया
बल्कि यह ChatGPT के सबसे उपयोगी use case जैसा दिखता है। यानी समय की कमी वाले founder के लिए, किसी खास goal के साथ थोड़े समय के लिए जरूरी expertise लेकर script बनाने वाला capability amplification tool
पहले यही result पाने के लिए freelancer ढूँढने, hire करने और समझाने में हफ्ते लग जाते; अब यह लगभग मुफ्त में तुरंत बनाया जा सकता है
ऐसी चीज़ को reflexively “हैरान करने वाला” या irresponsible कहना समझ में आता है, लेकिन यह काफी “आजकल के बच्चों” वाली प्रतिक्रिया लगती है
अगर यही भविष्य है, तो developers के लिए बेहतर होगा कि वे non-technical लोगों की बढ़ती self-sufficiency को support करें और सोचें कि founders ChatGPT से scripts बेहतर तरीके से कैसे request कर सकते हैं
यह कहना मुश्किल है कि इस क्षेत्र में मेरी technical expertise कम है; मैं बस अपना समय जितना हो सके efficient तरीके से इस्तेमाल करना चाहता हूँ
लेखक ने पहले ही जवाब दिया है कि उसने script review की और sensitive data upload नहीं किया, इसलिए उस हिस्से में जोड़ने को कुछ नहीं है
बहुत से लोग ChatGPT का प्रभावी इस्तेमाल करते हैं, लेकिन उसके output पर अंधा भरोसा नहीं करते। मेरे लिए ChatGPT starting point है, final output नहीं
हर कोई उस वकील जैसा मूर्ख नहीं होता जिसने hallucinated case citations को verify किए बिना legal brief में paste कर दिया था
मैंने ऐसे बहुत से लेख पढ़े हैं, लेकिन जब विषय coding या debugging पर meta लेख न हो, तब लेखक अचानक यह कहे कि उसने coding के लिए Stack Overflow पर निर्भर किया—ऐसा मुझे शायद ही याद है
अगर कोई foreign company अमेरिका में payments accept करती है, तो ऐसी चीज़ को बस cost of doing business मानकर चलना चाहिए
अमेरिका में credit card fraud socialized है। end consumer responsible नहीं होता, इसलिए chip and PIN, two-factor authentication, 3D Secure जैसी चीज़ें इस्तेमाल करने की जरूरत ही महसूस नहीं होती
कोई suspicious transaction दिखे तो bank app में एक button दबाते ही कुछ मिनटों में payment reverse हो जाती है
Banks और payment processors के incentives भी इसी तरफ हैं कि transactions को जितना तेज और आसान हो सके approve किया जाए, ताकि लोग उनका ज्यादा इस्तेमाल करें
लेखक ने जैसा कहा, expiry date, billing address, ZIP code match न होने पर भी आम तौर पर payment हो जाता है
नुकसान यह है कि सारी responsibility merchant पर धकेल दी जाती है, और merchant को इसकी भरपाई के लिए सबके लिए prices बढ़ाने पड़ते हैं
Denmark में भी वही consumer protection, chargeback की संभावना, और bank account लुट जाने पर consumer का पैसा न डूबे इसके लिए government guarantee है
फिर भी purchase के समय mandatory chip and PIN और 3D Secure जैसी मजबूत protections हैं
मुझे नहीं लगता कि अमेरिका में बेहतर card security न होने का कोई rational reason है। बस लगता है कि वे चाहते ही नहीं
अमेरिका में यह आम तौर पर transaction amount का करीब 2% होता है, जबकि EU में इसे अधिकतम 0.3% तक सीमित किया गया है
पैसे के transfer के scale को देखते हुए वह भी अभी बड़ा लगता है
यह cost भी आखिरकार socialized होकर consumers पर डाल दी जाती है, और cash देने वाले लोग भी higher prices के रूप में इसे भुगतते हैं
वैसे, 3D Secure में कुछ banks की terms के तहत card owner fraud payment के लिए liable हो सकता है
अगर mobile phone two-factor authentication है, तो phone और wallet का साथ में चोरी हो जाना ही काफी है, और मैंने news में ऐसे cases देखे हैं जिनमें लोग हजारों dollars गंवा बैठे
उन्हें सिर्फ dollar पर 1–2 cents, ज्यादा से ज्यादा 5 cents तक का reward “points” के रूप में दिखता है, और 1 cent को 100 points जैसा दिखाया जाता है, तो वह अच्छा लगता है
जो दिखाई नहीं देता वह है overall product prices में 3–5% से ज्यादा markup, chargebacks और processing costs, fraud payments, weak security, अब भी magnetic stripe accept करने वाली stores, और ढेरों middlemen
Bank fees, card issuer fees, network fees, premium card fees लगातार जुड़ते रहते हैं
पूरा chaos है और मुझे सच में इससे नफरत है
उम्मीद है FedNow से बदलाव आएगा। लोगों का पैसा चूसने वाले middlemen हटने चाहिए, parasites और waste खत्म होने चाहिए
पिछले 2 सालों से मैं जिन दो organizations से जुड़ा हूँ उन्हें चला रहा था, और दोनों पर French bank cards इस्तेमाल करने वाले automated credit card verification bots ने हमला किया और बहुत से cards pass हो गए
बेशक, दोनों organizations ने payment site को harden करने की मेरी पहले की warnings ignore की थीं, और उनमें से एक अब भी Magento 1 इस्तेमाल कर रहा था
यह सिर्फ anecdote है, लेकिन असली समस्या यह है कि credit cards ACH जितने ही patchwork जोड़-तोड़ वाले legacy system हैं और कोई भी उन्हें meaningful तरीके से ठीक करना नहीं चाहता
Credit cards अमेरिका में invent हुए थे, इसलिए technology पुरानी है और upgrades में बहुत समय लगता है
manual payments के मामले में India का UPI काफी अच्छा लगता है। मैंने सुना है कि payment process होने से पहले customer अपने phone पर हर payment approve करता है
चार्जबैक फीस के संदर्भ में, Visa ने कुछ साल पहले Verifi नाम की कंपनी का अधिग्रहण किया था
उसके नए products Rapid Dispute Resolution और Order Insight हैं
RDR किसी transaction के chargeback में बदलने से पहले automatic refund करने देता है, और Visa 4 डॉलर की fee लेता है। शर्त यह है कि MCC code high-risk न हो
Order Insight विवादित payment के लिए specific data तुरंत उपलब्ध कराने देता है, और अगर customer ने पहले 3 बार payment किया हो तो chargeback जारी नहीं किया जा सकता
हमारे business में win rate, average order value और chargeback fee के आधार पर यह बहुत आसान फैसला था
अब Visa या merchant bank के 1% chargeback rule की लगातार चिंता भी नहीं करनी पड़ती
यह सिर्फ Visa payments पर लागू होता है, लेकिन वे कुल transaction volume का करीब 50% थे
आखिर में, Visa असल में processors के एक बड़े revenue source को छीन रहा है। अगर processor TSYS है, तो वह RDR fee के तौर पर 10 डॉलर लेने की कोशिश करेगा
Ethoca के बारे में सुना है, उनका SEO वाकई अच्छा है। Verifi से काफी मिलता-जुलता लगता है
समझ नहीं आता कि अमेरिका banking के मामले में इतना पीछे क्यों दिखता है
UK ने 2004 से chip and PIN लागू किया था और 2006 से इसे अनिवार्य कर दिया था, जबकि अमेरिका ने लगभग 10 साल बाद follow किया
Faster Payments ज्यादातर bank accounts के बीच instant transfer मुफ्त देता है। अमेरिकी customers से money transfer पाना, US Wise account होने पर भी, हमेशा nightmare रहा है
EU में strong customer authentication लागू होने के बाद से ज्यादातर नए payments को mobile banking app या किसी दूसरे two-factor authentication method से approve करना पड़ता है
उससे पहले भी कम से कम postal code और CVV match करना जरूरी था
ये उपाय ऐसे लगते हैं जैसे banks fraud की जिम्मेदारी customers पर डाल रहे हों, लेकिन किसी भी हालत में नुकसान customer को ही होता है
जिस culture में card fraud को व्यापक रूप से स्वीकार कर लिया जाता है, उसमें उस cost की भरपाई के लिए prices बढ़ते हैं
table पर terminal से सीधे pay करने के बजाय, server को card देना पड़ता है और इंतजार करना पड़ता है कि वह कहीं जाकर manual processing करे
पिछले कुछ सालों में शायद सुधार हुआ हो, लेकिन Canada में 2000s की शुरुआत के बाद से यह तरीका इस्तेमाल नहीं होता
नतीजतन वह Y% अधिक customers को handle कर सकती है, और अगर Y, X से बड़ा है तो long term में ज्यादा profit कमा सकती है
अमेरिका में विशाल scale की वजह से कई businesses में यह तरीका काम करता है
उदाहरण के लिए McDonald's के लिए lunch peak time में fraud नहीं है यह check करने में 1 second लगाने के बजाय payments को तेजी से process करना शायद margins के लिहाज से बेहतर हो
Europe में यह काम न करे, लेकिन real cost analyze करते समय मुझे लगता है कि transaction speed और scale वाले dimension को miss किया जा रहा है
जैसे ही fraud और profit का balance companies के खिलाफ होने लगेगा, अमेरिका में भी major anti-fraud controls लगभग तुरंत on हो जाएंगे
50 states में हजारों छोटे regional banks हैं, और हर state भी काफी independent है
ऐसे environment में बड़ी नई technology deploy करना कहीं ज्यादा मुश्किल है
chip and PIN internet payments पर काम नहीं करता
bank transfers international level पर अच्छी तरह fit नहीं होते
address verification और CVV on करना आसान है, लेकिन इससे legitimate transactions भी ज्यादा reject हो सकते हैं। कभी-कभी उसका cost पकड़े गए fraud risk से बड़ा होता है
fraud liability customer पर नहीं, merchant पर डाली जाती है
बेशक merchant fraud cost आखिरकार prices में reflect होती है और customer ज्यादा pay करता है, लेकिन सिर्फ इस अर्थ में कि fraud की सारी costs अंततः consumers पर pass on होती हैं
असल में ऐसा नहीं है; यह जटिल समस्या है, और Atlantic के दोनों तरफ के actors changes का फायदा उठाने के लिए bad-faith games खेल रहे हैं
साथ ही इसमें शामिल roles को भी नजरअंदाज किया जा रहा है
stable job वाले mid-20s लोग कई कारणों से real system का लगातार छोटा हिस्सा बनते जा रहे हैं
EU और बाकी जगहों में भी कुछ लोग मानते हैं कि कामकाजी 20s लोग exploit हो रहे हैं और अपने rights खो रहे हैं
मेरी पुरानी company का server hack हो गया था, और API key चुराकर उसी server से carding किया गया
PayPal ने हमसे कहा कि हमें 100,000 डॉलर fees चुकानी होंगी
हम course registration fees के लिए दिन में अधिकतम 5 transactions, प्रति transaction करीब 4,500 डॉलर ही process करते थे
hacker ने random credit card numbers पर हर second 1 डॉलर authorization requests चलाईं
आखिर में carding fees हमें नहीं देनी पड़ीं, लेकिन उन्हें परवाह नहीं है
उन्हें परवाह इसलिए नहीं है क्योंकि वे fraud से पैसा कमाते हैं
हमने settings में order amount सिर्फ 2,500–6,000 डॉलर के बीच allow किया था, लेकिन authorization requests पर वे check नहीं करते थे
सच में पागलपन है
यह करीब 2010 की बात थी और तब Stripe Canada में उपलब्ध नहीं था
Stripe का fraud prevention भयानक है, और यह जानबूझकर है
वे risk management cost खुल्लमखुल्ला customers पर डाल रहे हैं। यह अश्लील हद तक है
मैं credit card fraud prevention में काम करता हूँ, और मैं इस काम में बहुत शानदार भी नहीं हूँ, लेकिन हमारी 3.5 लोगों की team ने इस तरह के carding attacks रोकने वाला system आसानी से बनाया और maintain किया
merchants carding attacks रोकने का मुख्य तरीका यह है कि खुद को अगले target की तुलना में थोड़ा ज्यादा झंझट वाला बना दें
मुझे लगता है Stripe को लगता है कि चूँकि वे pain और cost users पर डाल सकते हैं, इसलिए सबसे आसान attack target वाले बड़े network बने रहना भी ठीक है
Stripe बहुत कम cost में भी ऐसे नुकसान को आसानी से रोक सकता है
कुछ पैसे बचाने के लिए वे users को तकलीफ झेलने देने का फैसला कर रहे हैं
Stripe Taxes और खराब currency conversion भी वही strategy है
शुरुआत में वे service ठीक से नहीं देते, और आखिरकार आपको एहसास होता है कि Stripe transaction costs कुल price के double-digit percentage तक पहुँच जाती हैं
मैं Stripe का Edwin हूँ. मैं बस यह जोड़ना चाहता हूँ कि यह लेख एक महीने पुराना लेख (https://piotrmierzejewski.com/p/card-networks-exploitation) कॉपी करता है
उसके बाद से हमने इस समस्या का ज़्यादातर हिस्सा ठीक कर दिया है. इस तरह की card testing कम हुई है, और अब Radar को ऐसे हमले पकड़ लेने चाहिए
chargeback के बारे में, हम भी chargeback से नफरत करते हैं और उन्हें जितना हो सके कम करना चाहते हैं
असल में हम कुछ ऐसी चीज़ों पर काम कर रहे हैं जो इसमें मदद करेंगी
बैंक chargeback fees अलग-अलग रकम में लगाते हैं, और उनका औसत 20 डॉलर की fee के रूप में दिखता है
यह Stripe-only fee नहीं है, और हम chargeback से profit नहीं कमाते
हमने अभी-अभी इस साल के बाकी समय के लिए कंपनी की योजना पूरी की है, और इस तरह की fraud को कम करना सबसे बड़ी प्राथमिकता है
अगर आपको लगता है कि आपके साथ भी ऐसा कुछ हो रहा है, तो edwin@stripe.com पर मेल कर सकते हैं
सच में, यह मैं आपके customer के तौर पर कह रहा हूँ
पिछले साल मैं एक e-commerce कंपनी में systems, CI, infrastructure और software सब संभालने वाली भूमिका में काम करता था
ऐसी चीज़ें सच में बहुत आम थीं, और हर हफ्ते कम से कम एक दिन नए patterns समझने और उन्हें रोकने में जाता था
attackers हमारे system से credit cards verify कर रहे थे
आखिरकार हमने cart और checkout तरफ के लगभग सारे attacks रोक दिए, लेकिन requests आती रहीं
बाद में एक unrelated PHP issue के लिए logs खंगालते समय, एक software engineer ने बताया कि एक ऐसे page पर भारी traffic आ रहा था जहाँ बाद के लिए payment method save किया जाता था
वह platform card असली है या नहीं जांचने के लिए 1 डॉलर का charge करता था, और attackers उसी का इस्तेमाल करके cards लगातार चला रहे थे
credit card चोर सच में बड़े जुगाड़ू होते हैं
Stripe के साथ fraud detect करने के लिए, मुझे कभी यह सलाह मिली थी कि अगर आप इसे seriously कम करना चाहते हैं और transaction volume पर्याप्त है, तो अपना fraud detection model train करना अच्छा रहेगा
कोई simple logistic classifier जैसा model भी काम कर सकता है
Stripe Radar हर business की बारीक specifics के लिए tuned नहीं होता, और यह कौन-सा product खरीदा जा रहा है, site खोलने के बाद purchase तक कितना समय लगता है जैसी अतिरिक्त signals को शामिल कर सकता है
custom Radar rules भी कुछ हद तक काम करते हैं
मैं समझता हूँ कि कई indie operators के पास ऐसा करने के लिए resources या इच्छा नहीं होती
खरीदे जा सकने वाले solutions भी हैं, लेकिन वे महंगे हैं और आम तौर पर high-volume merchants को target करते हैं
शायद किसी दिन Stripe fine-tunable Radar product लाए
यह एक और वजह है कि credit card industry खत्म हो जानी चाहिए
security protocols या तो हैं ही नहीं या 21वीं सदी की शुरुआत के बाद upgrade नहीं हुए हैं, और intermediaries के abuses भी अनगिनत हैं
इन झंझटों को संभालने की लागत higher transaction fees और chargeback fees के रूप में merchants पर डाल दी जाती है, और आखिरकार consumers पर पहुंचती है
यह भी नहीं भूलना चाहिए कि credit card industry consumers में सबसे खराब spending habits को बढ़ावा देती है, और अंतहीन कर्ज़ की गुलामी के चक्र को बनाए रखती है