This is the big problem with Stripe's positioning in the payments food chain ladder.

Block every single fraudulent or suspicious transaction, and you're leaving obscene amounts of money on the table.

The amount of credit card fraud that goes unclaimed or is eaten by liability shift is huge, so if Stripe makes a product like Radar ACTUALLY WORK, they would be missing out big time.

I am confident Stripe's radar's shortcomings are deliberate and not simple bugs or design problems.

It appears they have no incentive for the product to be 100% effective and that would explain why Stripe Radar is billed per screened transaction, regardless of outcome.

We benchmark Stripe Radar against other pure play fraud fingerprinting solutions, and the difference is abysmal. The fact that Stripe claims to have seen 80% of any card before it gets to your store make this fact even worse.

So, like parent says, you are going to see radar scores of 90 and 95 for certain charges (clearly fraudulent carding attempts), followed by scores of 15 or 20 for the same card, IP, fingerprint with absolutely no warning.

I've grown tired of escalating this to Support. They just give me the ML model answer. Basically: "It's a black box!"

You can definitely add a rule to start blocking charges from X places, or with Y velocity, or always enforce 3DS, but then you're taking the model into your own hands, and that has some important consequences.

Your acceptance rate goes down. You're heavily interfering with the model and relying (and trusting) it less, and you realise you really don't need Radar to do that for you.

If you're serious about fraud, you must use a pure player solution that is 100% aligned with your interests.

From what we've seen with Stripe Radar in the past, that doesn't seem to be the case.

I'm a big fan of Stripe in may ways, but I really have a love/hate relationship with this side of their business...