EDIT: It appears that risk_score is indeed not available but risk_level is. You are still able to use your own logic to say for instance "don't capture if card country and tokenization IP country don't match and risk_level is elevated".

I honestly don't think it affects my answer much. They offer a less granular but still useful version for free.

AFAIK Radar also for free applies these learnings to the charges and blocks high risk ones for you.

> If Stripe had an API endpoint where developers could get the risk level of a transaction before the payment intent was put into motion then we could in theory build our own risk management tool at our app level by saying "if $risk_score > X then deny transaction".

But you can. The majority of what Radar custom rules allow you to do you can implement fairly easily on your own. You can take the risk scoring into account by separating auth (then looking at the risk score and make your own decisions) and capture (see link above). Granted it's a bit annoying you have to do a separation of auth and capture while with Radar custom rules you don't have to but it's not that big a deal.

There are possibly some pieces you cannot completely reproduce but for the most part you can build your own rules on your own. Even if one were to follow your reasoning of them using your transaction data to learn, Stripe doesn't owe you the part of Radar that allows you to write custom rules. That's an entirely tangential feature: Those are rather simple if statements that have little to do with the ML part of Radar.

I also encourage you to question your entire argument here. You'd have processed with Stripe if they used that data for anti-fraud ML or not. They didn't take that away from you or lured you into anything.

The actual work is in their engineers building the ML system, maintaining it (also: computing cost), tuning it, updating it, adding new data, cleaning up data (like extracting info from unstructured data on transactions).

I don't even think they owe their users the free version to be honest, but it's in their interest as well to make sure merchant exposure to fraud is reduced, and so you get it.

Blaming them for trying to make some money with an add-on system that simplifies writing custom rules like "if card country not IP country" or ones that combine the risk score, seems a bit rich.

And just to too this off I do have my qualms with some Stripe fees that seem outrageous, but Radar/Radar for teams, really?

I'm not sure what you are selling on Stripe but if it in anyway relates to software I'd expect some degree of understanding for the monetization approach.