Stripe fraud prevention is not sophistocated at all. I have been trying different fraud prevention providers and all of them are lame. They check if the ip of the buyer matches the billing location of the card and if not they will not accept the order. So far, the best method I have diwcovered is to verify the order by phone. The phone number provides me with extra knowledge about my customer. I can match their buying ip address with it. I can talk to the customer in their language to verify they are who they say they are. It is not bulletproof but I have yet to see fraudster go to that extend.

When you learn enough about your customers, you should be able to roll out your own fraud prevention solition because generic ones are broken. Here is a recent report about what works and what does not in the generic fraud prevention tools: https://www.braintreepayments.com/resources/kounts-mobile-pa...

> I have yet to see fraudster go to that extend.

You must be in a field with relatively low-volume/low-effort fraud.

I knew of many fraudsters who used to go through phone verification to buy game currency with stolen CCs. This was back in 2011, mind you.

Those graphs are entirely survey-based subjective, there's no metrics at all, and it's also an advertisement for Braintree's fraud service

Look at the original report that the graphs are based on. I think that's where the useful data is.

Braintree's fraud prevention is poor and based on generic metrics. One of my businesses had 32% chargebacks with their service.

30% is an order of magnitude higher than the typical industry fraud-attempt rate. If 30% of orders were charged back you probably had other issues? That's pretty nuts

Curious what kind of products do you sell?

Software for backing up sites.

> It is not bulletproof but I have yet to see fraudster go to that extend.

There's a comment upthread in which someone describes dealing with a fraud ring that uses a call center to defeat exactly this approach. Anecdotally, I know shop owners who have also dealt with would-be fraudsters who will happily talk to them over the phone.

Which is not to say that your experience is anything less than completely valid! It just might not encompass the whole of the range of possible valid experiences.

I've never used stripe specifically, but in my experience its always good to have your own layer of fraud prevention, because if you have too much fraud reach whoever is providing payment processing, they will terminate your account.

Beyond that, a few simple checks will make most fraudsters move onto other websites. It's not about being bulletproof, it's about being harder to abuse than the others.

I think the point is that it's very hard to do as good a job as providers like Stripe and SiftScience will do (assuming machine learning against fraud is not your core competency) - they take into account a lot of the signals you might take into account anyway if you feed them clean data. Better to focus on sending them the clean data.

totally false. Machine learning is not my companies core competency, but we do have a team of data scientists (myself included). Most of the data we get from our data providers is garbage by itself, but using our own data along with features from providers, we are able to pick out a huge amount of fraud.

These types of models are actually quite simple to build and implement if you actually have data.

Exactly the opposite. Generic fraud checks will perform worse

They're not generic, though. Those providers build custom ML models specifically from your data (and they pull in a ton of signals for this), and then have the data of many other merchants to work with.

At a previous employer we found both of those products to be effective.

These systems are the most frustrating to me, because it is the unusual transactions that are more important than the usual ones.

If I have eggs delivered every week, and one of those transaction fails, who cares?

If I buy a plane ticket for a flight that leaves in 30 minutes because of an emergency, I will be fucking enraged if that transaction is blocked.

Similarly if I can't pay the hotel at check-out and because of this delay I miss my flight.

Or when I arrive in a new country and can't pay for the taxi ride, and the ATMs don't work either.

All these events have happened to me.

Effective at preventing fraud - sure But what about false positives?

If the question is whether you'll have any - of course you will! You will no matter what method you go with. At scale it's a pretty easy curve to optimize revenue on top of though, and you have to be willing to accept that bit. You know your customer LTV, you know your fraud rate/cost.

Sift gives you direct control of expected false positive rate, Radar hides that optimization under the hood I think?

Mostly agreed. I don't know anything specifically about Stripe, but I did work on fraud prevention systems for a major company. Being able to aggregate signals across multiple customers is a massive help in fraud detection - in terms of signal quality, bigger is better here.

As a simple illustrative example from the article - a large provider will have history for email addresses and street addresses. Maybe they've seen lots of orders in the past from a given sketchy email address paired with a reshipping center that were all valid, which moves the risk of a transaction from "dodgy" to "probably fine". They'll have historical information that an individual merchant just won't have.

That said, at some point you're going to need to have your own specialists involved, because the big providers aren't going to have the specific domain knowledge about your products/users to make good decisions around the margins. Plus you'll probably want to define your own tolerance for risk.

It depends.

I've worked in the e-commerce industry for more than 10 years, not having proper fraud prevention is something that can bankrupt you. If you _know your customers_, it's easy to create a simple system that would at least notify you of possible fraudulent orders and let you take manual action. Even with the recent Stripe updates, we still see plenty of payments that go through even thought they should've definitely been caught, but because we've our own system in place, they get caught before doing any damage (and subsequently helping Stripe and marking the payments as fraudulent -- I wonder if I can get free Stripe credits for training their models using our own dumb heuristic based code).

There's nothing wrong with adding your own checks based on your specific needs, but you need a baseline to build from. An early-stage startup or a small business just doesn't have the expertise to build a comprehensive fraud prevention system. Fraud prevention providers have huge databases to train their models on and an enormous amount of experience and expertise.

Stripe's fraud detection heuristics are neither sophisticated nor particularly effective.

Judicious use of DNSBLs, port scanning and latency measurements, three measures which shouldn't take a competent technician more than a few days to knock together, will outperform Stripe.

If you're convinced you can outperform Stripe in a couple days, you should probably be launching your own fraud-fighting saas, because you'll make a killing. It's a literal many-billion-dollar opportunity.

I kind of want to take you up on this at a very basic level, as a weekend thing.

Create an API so you can check them all with one request