Here's hoping it also reduces the exorbitant amount of false positives we've been seeing with Stripe's fraud prevention services, which cost us a lot in lost legitimate sales.
I'm sorry to hear that! Feel free to email me (patrick@stripe.com) and I'll connect you with the team if you'd like us to do a deeper dive.
But, yes, part of the intent here is to enable us to achieve better ROC[1] in our models and to block more fraud while also encumbering fewer false positives. From our testing, it's very clear that these bot-detection techniques do substantially improve the accuracy when compared to other, coarser heuristics.
A user shouldn't have to email a cofounder to get in touch with a team member. The last time I integrated stripe on a site as a final test before it went live I had my cousin make a purchase and the site got flag as potential money laundering because we had the same last name. At the time literally zero customer service. It took 8 years before stripe started doing any customer support. Cool launch pages but personally I'll never use stripe again
I've always launched with fraud turned down. The bots don't know you're there yet and Stripe can figure out your traffic. Then, you can turn it up once you get a few dozen or so sales under your belt.
We have the opposite problem. People with 50 carding attempts and radar scores of 30 or so. There is no value in Radar if so many of these cases pop up because you can’t really tell the truth from the false.
We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases.
Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.
