[dulse]

[I lead Radar at Stripe] We're still investigating but have blocked the majority of this attack from the Stripe network. We're going to refund any impacted transactions and waive the fees for those payments. We'll also waive the dispute fee (if a payment has been disputed).

More broadly, we’ve seen an uptick in card testing attempts across Stripe. While the absolute rate of successful card testing across the Stripe network is flat-to-somewhat-down, it’s not evenly spread—some businesses are seeing more than others. For these new testing attacks, we’re deploying mitigants in real time.

[weird-eye-issue]

Will your customers need to give you the full list of the refunded transactions? Since you couldn't detect them in the first place I don't imagine the fees will be automatically refunded?

Also, after posting this thread I just had to refund two more payments from an Indian IP address using a Singapore card with a billing address in the USA with a ZERO risk score. How does that make any sense? There is no CVC check listed and the zip check is "Unavailable"

I simply don't understand some of these scores

How could there not be a minimum risk score in a situation like this where none of the countries even match up...

[rameerez]

I'm the OP of the Twitter thread – I've had the exact same experience: unrealistically low risk scores for most fraudulent transactions. There were plenty of red flags for each of them (400+ cards and 40+ names under one single IP, most payments got already flagged for credit card testing fraud early on before succeeding after many tries...) Even dumb heuristics would have blocked 90% of the fraudulent payments. I appreciate Stripe is fixing this quickly after making it public and refunding fees, but something is definitely wrong with their risk calculation algorithm.

[ripberge]

I have experienced the same. An absolutely ludicrous set of suspicious data points like that and Stripe scores it a zero or near zero. We process hundreds of millions of dollars in transactions. Have gotten zero help from Stripe on this scoring.

[dulse]

We're going to automatically refund the transactions and fees, but also support any write-ins if you feel we missed any. (We have some ways to identify the transactions after they happen).

I agree with you, it's very counter-intuitive why these transactions are getting through Radar. We're iterating on some fixes right now that should stop this going forward by addressing this type of attack.

[SheinhardtWigCo]

One way I can imagine this happening: if the carder is able to steal the cardholder's tracking cookie or other credential that Stripe trusts due to a previous legitimate transaction, and this causes Radar to disregard signals that would normally lead to a high risk score. (Just a hypothesis, I have no inside info.)

[weird-eye-issue]

With the way they cycle through cards in the same checkout session I 100% don't think this is happening, but if it is then I wouldn't even blame Stripe at that point lol

[ANaimi]

What I’d love to know is: many fraudulent users try out different cards one after the other. How is it not the default case that Stripe blocks these users? It’s the most common pattern we see, easily identifiable by the repeated failed attempts with different cards.

[throwway120385]

Why did it take a Hacker News thread for you to actually do something useful about this? If this is the first time you're hearing about that it's a pretty severe failure of multiple layers of your customer service procedures. I certainly wouldn't recommend you guys versus other processors I've used at work who would actually do something about this when calling or emailing through the usual channels. This is a very "Google" way of handling things to have to Tweet or post on HN to get any kind of real support and it's very concerning.

[seeingfurther]

Hi dulse, can you please make a public announcement with much more clarity. We received one of your alert emails but it was very cryptic with very little information and no mention this was happening across the network. Our fraud team spent two hours in a panic until we found this thread via Twitter.