3 ms·
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 loo
by dulse 3y ago
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 3y agoHi 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 3y agoThanks for the feedback! Will take a look at this, agreed that sounds easy and helpful.
- neurostimulant 3y agoI'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?
- weird-eye-issue 3y agoNo, that's clearly not true. Otherwise this thread would not exist
- neurostimulant 3y agoBut 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 3y agoThat 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 3y agoWhat 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 3y agoRadar fraud rules. Like is already discussed in the Twitter thread. How hard is it to read?
- neurostimulant 3y agoI admit I didn't scroll too far down beyond the signup modal.
- weird-eye-issue 3y ago
- rameerez 3y agoI'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.