4 ms·

> Stripe has all the power to prevent many forms of fraud and provides this as a service as long as you pay a premium for it in the form of Radar. You have to p

by pc 7y ago

> Stripe has all the power to prevent many forms of fraud and provides this as a service as long as you pay a premium for it in the form of Radar. You have to pay extra on top of the 2.9% + 30c per transaction to get this protection. Radar's ML-based shield is free for all accounts on standard pricing. See https://stripe.com/pricing#radar-pricing https://stripe.com/pricing#radar-pricing. (We only charge if you want to set custom rules etc.)

nickjj 7y ago
> (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.
- audiometry 7y ago
  " 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.
- patio11 7y ago
  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.)
  - freeone3000 7y ago
    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!
  - nickjj 7y ago
    > You're also welcome to do post-charge processing using our risk scores. But if it's a post-charge operation, then the transaction already took place and it's too late. If I need to refund a transaction after the fact because the transaction looks risky, then I lose out on the non-refundable processing fee that you now take, so I lose there. Can you lay out a 100% exact work flow of how I can implement what Radar for teams does without losing money to extra transaction fees through either paying insurance on each transaction, or losing refund / dispute fees?
    - patio11 7y ago
      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.
- quelltext 7y ago
  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-outcome-risk_score 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.
mtnGoat 7y ago
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.
- quelltext 7y ago
  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?
  - mtnGoat 7y ago
    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.

by pc 7y ago

nickjj 7y ago

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

audiometry 7y ago
" 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.
patio11 7y ago
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.)
- freeone3000 7y ago
  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!
- nickjj 7y ago
  > You're also welcome to do post-charge processing using our risk scores. But if it's a post-charge operation, then the transaction already took place and it's too late. If I need to refund a transaction after the fact because the transaction looks risky, then I lose out on the non-refundable processing fee that you now take, so I lose there. Can you lay out a 100% exact work flow of how I can implement what Radar for teams does without losing money to extra transaction fees through either paying insurance on each transaction, or losing refund / dispute fees?
  - patio11 7y ago
    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.
quelltext 7y ago
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-outcome-risk_score 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.

mtnGoat 7y ago

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.

quelltext 7y ago
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?
- mtnGoat 7y ago
  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.