[dulse]

Really sorry to hear about that experience — we need to do better here. If you want to shoot me an email (wmegson [at] stripe [dot] com) I can take a closer look at those specific charges. We are identifying those charges and are going to automatically refund any impacted transactions and waive the fees for those payments. We'll also waive the dispute fee (if a payment has been disputed).

The team is digging into why the risk score is low. In general, the types of signals you describe weigh pretty heavily in Radar’s risk assessment, and should result in higher risk scores. In this particular attack, fraudulent actors are using some pretty sophisticated scripts to try and obtain lower risk scores. We’re iterating quickly to address and stop these types of attacks and score them correctly going forward.

[mchusma]

Hi dulse, while you are here, there is another issue with high-risk payments. You can see in your dashboard the count of "high-risk payments", but there is no way to actually review which payments were flagged as high-risk. This seems like it should be easy to implement. I'd expect there to be a report or filter here in the payments tab. I hope you can help!

[dulse]

Thanks for the feedback! Will take a look at this, agreed that sounds easy and helpful.

[neurostimulant]

I'm under impression that we basically don't need worry about card testing if we're using Stripe Checkout instead of direct API calls. Is that true?

[rameerez]

I'm the thread OP – can confirm we're using Stripe Checkout and all CC processing happens in a fully-managed Stripe Checkout page.

We're not using any other API from Stripe other than that required to launch the hosted Checkout page.

[weird-eye-issue]

No, that's clearly not true. Otherwise this thread would not exist

[neurostimulant]

But OP doesn't specify whether he's using Stripe Checkout integration (where stripe 100% control the landing page hosted in stripe domain) or other integration types (e.g. direct API call / embed which has higher risk). With Stripe Checkout integration type, you redirect users to a payment page hosted by stripe and have no ability to check whether the user is performing card testing there because the payment page is in stripe's domain, so stripe should be the one responsible with card testing prevention when using this discussion integration type.

[simfree]

That is a very hopeful (and naive) view of liability in the merchant processor space. By default all liability falls onto the business, not your merchant processor unless you specifically negotiated for a liability shift.

Stripe will not eat the fees for card testing.

[neurostimulant]

What can we do then? Stripe's own documentation recommends us to use Stripe Checkout because it's the most secure against card testing, and that checkout page is owned and operated by stripe so it's not like we can add custom card testing detection logic there.

[weird-eye-issue]

Radar fraud rules. Like is already discussed in the Twitter thread. How hard is it to read?

[weird-eye-issue]

You are so naive (and wrong) lol

Also, it is mentioned in the thread they are using Stripe Checkout (we are too)