Stripe include very sophisticated fraud prevention in their standard pricing and charge pennies per transaction if you're on custom pricing. Numerous third-party providers offer excellent fraud detection and prevention tools for CNP transactions. Unless you're big enough to have a dedicated fraud prevention team, just leave it to the professionals.
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...
Braintree's fraud prevention is poor and based on generic metrics. One of my businesses had 32% chargebacks with their service.
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.
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.
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.
At a previous employer we found both of those products to be effective.
Sift gives you direct control of expected false positive rate, Radar hides that optimization under the hood I think?
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.
These types of models are actually quite simple to build and implement if you actually have data.
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.
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).
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.