If you don't choose to write your own software using your own data, that's cool; you can buy that software from us, for two cents a transaction (or less).

We're a software company selling to software developers. We're cool with you writing your own software with your own data if you think your engineers are sufficiently efficient at this to make that the best possible use of their time. (The businessman in me suggests that it is extremely unlikely you can profitably employ engineers to write this software at most likely scales of your business and, contingent on being able to do that, it is quite likely there are a hundred better projects not upper bounded at 2 cents a transaction, but you are a project away from constructively disproving this if you strongly disagree.)

This kind of move is always galling. McGraw-Hill/Platts is terrible with this, where they take data from traders' transactions and then resell it back to them at extortionate rate. Whole market hates them.

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.