> (We only charge if you want to set custom rules etc.)

The rules are what really allows merchants to protect themselves against fraud but this information isn't possible to obtain without help from their payment gateway (ie. Stripe).

In other words, merchants have no reasonable options to set up rules like what Radar does while using our own custom logic because there's no API that Stripe provides for us to get things like the risk score before the transaction takes place.

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 AFAIK nothing like this is possible, so our only option is to pay the extra transaction cost for Radar or deal with a less than ideal fraud protection even though Stripe can technically do this already. It just feels really dirty. It feels like instead of optimizing for the greater good and making the developer / business experience awesome, Stripe would rather pivot from being a payment gateway to an insurance company and then nickel and dime the businesses that helped build Stripe initially.

It's one of those things where it's like, we've been using you for years (quite happily in fact), but you collected all of this data from us and now instead of helping us by offering fraud detection across the board, you'd rather sell our data back to us in the form of insurance.

You're welcome to do your own risk scoring on any signals you want prior to directing us to charge a credit card for you. You're also welcome to do post-charge processing using our risk scores. Some companies will e.g. do post-transaction reviews prior to shipping; some write their own workflow SaaS into their admins to do this.

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.)

The issue is there's no hook between when the transaction is sent and the risk score is analyzed, and when the transaction is processed - after the risk score is returned, the transaction is already processed, and it's too late to deny!

I understand that you are contemplating a build-or-buy decision and do not want to purchase the software which we sell. You can ask the engineering teams that you want to dedicate to this to scope out the build option; there are likely tradeoffs you can make which would make this a 3 engineer-year project or 30 engineer-year project. It is implausible that their design document for the build option will conveniently fit into an HN comment. I cannot write that design document for you as I do not have a good understanding of what data you believe you possess at the moment or e.g. the margin characteristics of your business, which would likely determine your tolerances with respect to some tradeoffs to make at design stage.

I wish your teams the best of luck and skill in this project. If in the alternative you would like to dedicate their time and attention to more pressing concerns in your business, our software is available for 2 cents a transaction.

> I wish your teams the best of luck and skill in this project. If in the alternative you would like to dedicate their time and attention to more pressing concerns in your business, our software is available for 2 cents a transaction.

Do you happen to work for Stripe support?

I'm just asking because your response reminds me of how they addressed my questions in email. It's very dismissive of my original questions, and then tries to guide the conversation away from my question into some type of "hey, good luck with whatever you do" response.

I'm not asking for an evaluation of whether or not it's a good use of engineering time for me to implement this feature. I'm just asking how I can do risk score assessment on my own without paying your extra transaction fees, or be forced into doing a post-transaction refund (and then lose the transaction fee on the refund).

You mentioned I'm free to do my own risk assessment, but I'm trying to say that's not possible to do in such a way that doesn't involve me paying extra money to Stripe since your API purposely goes out of its way to remove critical information unless you pay extra for Radar for teams (in which case using your API for this info wouldn't be necessary since your platform would provide that functionality in your dashboard).

> Do you happen to work for Stripe support?

He does work for Stripe. There are at least 4 Stripe employees in this discussion performing damage control: pc, patio11, nkohari, edwinwee, and anyone who has not yet self-disclosed.

" you collected all of this data from us and now instead of helping us by offering fraud detection across the board, you'd rather sell our data back to us in the form of insurance."

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.

My understanding is that what Radar does that you cannot is the ML to calculate the risk scoring and they give that to you for free: https://stripe.com/docs/api/charges/object#charge_object-out...

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.

> But you can. The majority of what Radar custom rules allow you to do you can implement fairly easily on your own. You can even take the risk scoring into account by separating auth (then looking at risk level and make your own decisions) and capture: https://stripe.com/docs/api/charges/object#charge_object-out...

Did you read the documentation you've linked to? :D

This field you linked is only available with Radar for Fraud Teams (it says this in the last sentence of the outcome.risk_score field). This is the extra Radar feature that you need to pay insurance / extra fees for. It's not available for everyone by default. Stripe purposely removes it from the API response because they know that score is the missing link to be able to do risk assessment on your own.

So as mentioned before, this feels really dirty because they are taking your private data and are profiting from it by selling it back to you and others in the form of insurance -- and there's nothing you can do about it.

True, but you can still use the less granular risk_level. So yeah, you don't get the full detail but you can still use the data they learned.

> So as mentioned before, this feels really dirty because they are taking your private data and are profiting from it by selling it back to you and others in the form of insurance -- and there's nothing you can do about it.

No, you and everybody else processing on Stripe has left that data there whether it's used for Radar's ML or not. I absolutely don't see anything dirty with them monetizing the software they built on that data.

Custom rules are the useful ones! The cost of Radar is a huge gripe of mine as well, we have lost thousands to a single fraudster that would have been easy to block with simple rules... The loss was less then the cost of Radar though. ;(

Otherwise, the API can be a bit confusing, but I've learned to just be very careful when I read the docs and to read them throughly.

What were those simple rules?

I'm curious of whether they really required Radar custom rules specifically or whether Radar rules would just have been more convenient than writing your own rule evaluator?

he was using email addresses on the same few domains, cards, even using the same IPs, wasnt very clever at all. Radar would have been an easy fix.