7 ms·

Don't roll your own crypto, don't roll your own fraud prevention. Stripe include very sophisticated fraud prevention in their standard pricing and charge penni

Don't roll your own crypto, don't roll your own fraud prevention. Stripe include very sophisticated fraud prevention in their standard pricing and charge pennies per transaction if you're on custom pricing. Numerous third-party providers offer excellent fraud detection and prevention tools for CNP transactions. Unless you're big enough to have a dedicated fraud prevention team, just leave it to the professionals.

sbov 9y ago
I've never used stripe specifically, but in my experience its always good to have your own layer of fraud prevention, because if you have too much fraud reach whoever is providing payment processing, they will terminate your account. Beyond that, a few simple checks will make most fraudsters move onto other websites. It's not about being bulletproof, it's about being harder to abuse than the others.
- bpicolo 9y ago
  I think the point is that it's very hard to do as good a job as providers like Stripe and SiftScience will do (assuming machine learning against fraud is not your core competency) - they take into account a lot of the signals you might take into account anyway if you feed them clean data. Better to focus on sending them the clean data.
  - yani 9y ago
    Exactly the opposite. Generic fraud checks will perform worse
    - bpicolo 9y ago
      They're not generic, though. Those providers build custom ML models specifically from your data (and they pull in a ton of signals for this), and then have the data of many other merchants to work with. At a previous employer we found both of those products to be effective.
      - yani 9y ago
        Effective at preventing fraud - sure But what about false positives?
        bpicolo 9y ago
        If the question is whether you'll have any - of course you will! You will no matter what method you go with. At scale it's a pretty easy curve to optimize revenue on top of though, and you have to be willing to accept that bit. You know your customer LTV, you know your fraud rate/cost. Sift gives you direct control of expected false positive rate, Radar hides that optimization under the hood I think?
      - 4ad 9y ago
        These systems are the most frustrating to me, because it is the unusual transactions that are more important than the usual ones. If I have eggs delivered every week, and one of those transaction fails, who cares? If I buy a plane ticket for a flight that leaves in 30 minutes because of an emergency, I will be fucking enraged if that transaction is blocked. Similarly if I can't pay the hotel at check-out and because of this delay I miss my flight. Or when I arrive in a new country and can't pay for the taxi ride, and the ATMs don't work either. All these events have happened to me.
  - chasedehan 9y ago
    totally false. Machine learning is not my companies core competency, but we do have a team of data scientists (myself included). Most of the data we get from our data providers is garbage by itself, but using our own data along with features from providers, we are able to pick out a huge amount of fraud. These types of models are actually quite simple to build and implement if you actually have data.
yani 9y ago
Stripe fraud prevention is not sophistocated at all. I have been trying different fraud prevention providers and all of them are lame. They check if the ip of the buyer matches the billing location of the card and if not they will not accept the order. So far, the best method I have diwcovered is to verify the order by phone. The phone number provides me with extra knowledge about my customer. I can match their buying ip address with it. I can talk to the customer in their language to verify they are who they say they are. It is not bulletproof but I have yet to see fraudster go to that extend. When you learn enough about your customers, you should be able to roll out your own fraud prevention solition because generic ones are broken. Here is a recent report about what works and what does not in the generic fraud prevention tools: https://www.braintreepayments.com/resources/kounts-mobile-payments-and-fraud-2017-report https://www.braintreepayments.com/resources/kounts-mobile-pa...
- bpicolo 9y ago
  Those graphs are entirely survey-based subjective, there's no metrics at all, and it's also an advertisement for Braintree's fraud service
  - yani 9y ago
    Look at the original report that the graphs are based on. I think that's where the useful data is. Braintree's fraud prevention is poor and based on generic metrics. One of my businesses had 32% chargebacks with their service.
    - bpicolo 9y ago
      30% is an order of magnitude higher than the typical industry fraud-attempt rate. If 30% of orders were charged back you probably had other issues? That's pretty nuts
    - pkaye 9y ago
      Curious what kind of products do you sell?
toxic_ 9y ago
Stripe's fraud detection heuristics are neither sophisticated nor particularly effective. Judicious use of DNSBLs, port scanning and latency measurements, three measures which shouldn't take a competent technician more than a few days to knock together, will outperform Stripe.
- bpicolo 9y ago
  If you're convinced you can outperform Stripe in a couple days, you should probably be launching your own fraud-fighting saas, because you'll make a killing. It's a literal many-billion-dollar opportunity.
  - dylz 9y ago
    I kind of want to take you up on this at a very basic level, as a weekend thing.
    - Scoundreller 9y ago
      Create an API so you can check them all with one request
rprime 9y ago
It depends. I've worked in the e-commerce industry for more than 10 years, not having proper fraud prevention is something that can bankrupt you. If you _know your customers_, it's easy to create a simple system that would at least notify you of possible fraudulent orders and let you take manual action. Even with the recent Stripe updates, we still see plenty of payments that go through even thought they should've definitely been caught, but because we've our own system in place, they get caught before doing any damage (and subsequently helping Stripe and marking the payments as fraudulent -- I wonder if I can get free Stripe credits for training their models using our own dumb heuristic based code).
- jdietrich 9y ago
  There's nothing wrong with adding your own checks based on your specific needs, but you need a baseline to build from. An early-stage startup or a small business just doesn't have the expertise to build a comprehensive fraud prevention system. Fraud prevention providers have huge databases to train their models on and an enormous amount of experience and expertise.
splonk 9y ago
Mostly agreed. I don't know anything specifically about Stripe, but I did work on fraud prevention systems for a major company. Being able to aggregate signals across multiple customers is a massive help in fraud detection - in terms of signal quality, bigger is better here. As a simple illustrative example from the article - a large provider will have history for email addresses and street addresses. Maybe they've seen lots of orders in the past from a given sketchy email address paired with a reshipping center that were all valid, which moves the risk of a transaction from "dodgy" to "probably fine". They'll have historical information that an individual merchant just won't have. That said, at some point you're going to need to have your own specialists involved, because the big providers aren't going to have the specific domain knowledge about your products/users to make good decisions around the margins. Plus you'll probably want to define your own tolerance for risk.

sbov 9y ago

I've never used stripe specifically, but in my experience its always good to have your own layer of fraud prevention, because if you have too much fraud reach whoever is providing payment processing, they will terminate your account. Beyond that, a few simple checks will make most fraudsters move onto other websites. It's not about being bulletproof, it's about being harder to abuse than the others.

bpicolo 9y ago
I think the point is that it's very hard to do as good a job as providers like Stripe and SiftScience will do (assuming machine learning against fraud is not your core competency) - they take into account a lot of the signals you might take into account anyway if you feed them clean data. Better to focus on sending them the clean data.
- yani 9y ago
  Exactly the opposite. Generic fraud checks will perform worse
  - bpicolo 9y ago
    They're not generic, though. Those providers build custom ML models specifically from your data (and they pull in a ton of signals for this), and then have the data of many other merchants to work with. At a previous employer we found both of those products to be effective.
    - yani 9y ago
      Effective at preventing fraud - sure But what about false positives?
      - bpicolo 9y ago
        If the question is whether you'll have any - of course you will! You will no matter what method you go with. At scale it's a pretty easy curve to optimize revenue on top of though, and you have to be willing to accept that bit. You know your customer LTV, you know your fraud rate/cost. Sift gives you direct control of expected false positive rate, Radar hides that optimization under the hood I think?
    - 4ad 9y ago
      These systems are the most frustrating to me, because it is the unusual transactions that are more important than the usual ones. If I have eggs delivered every week, and one of those transaction fails, who cares? If I buy a plane ticket for a flight that leaves in 30 minutes because of an emergency, I will be fucking enraged if that transaction is blocked. Similarly if I can't pay the hotel at check-out and because of this delay I miss my flight. Or when I arrive in a new country and can't pay for the taxi ride, and the ATMs don't work either. All these events have happened to me.
- chasedehan 9y ago
  totally false. Machine learning is not my companies core competency, but we do have a team of data scientists (myself included). Most of the data we get from our data providers is garbage by itself, but using our own data along with features from providers, we are able to pick out a huge amount of fraud. These types of models are actually quite simple to build and implement if you actually have data.

yani 9y ago

Stripe fraud prevention is not sophistocated at all. I have been trying different fraud prevention providers and all of them are lame. They check if the ip of the buyer matches the billing location of the card and if not they will not accept the order. So far, the best method I have diwcovered is to verify the order by phone. The phone number provides me with extra knowledge about my customer. I can match their buying ip address with it. I can talk to the customer in their language to verify they are who they say they are. It is not bulletproof but I have yet to see fraudster go to that extend. When you learn enough about your customers, you should be able to roll out your own fraud prevention solition because generic ones are broken. Here is a recent report about what works and what does not in the generic fraud prevention tools: https://www.braintreepayments.com/resources/kounts-mobile-payments-and-fraud-2017-report https://www.braintreepayments.com/resources/kounts-mobile-pa...

bpicolo 9y ago
Those graphs are entirely survey-based subjective, there's no metrics at all, and it's also an advertisement for Braintree's fraud service
- yani 9y ago
  Look at the original report that the graphs are based on. I think that's where the useful data is. Braintree's fraud prevention is poor and based on generic metrics. One of my businesses had 32% chargebacks with their service.
  - bpicolo 9y ago
    30% is an order of magnitude higher than the typical industry fraud-attempt rate. If 30% of orders were charged back you probably had other issues? That's pretty nuts
  - pkaye 9y ago
    Curious what kind of products do you sell?

toxic_ 9y ago

Stripe's fraud detection heuristics are neither sophisticated nor particularly effective. Judicious use of DNSBLs, port scanning and latency measurements, three measures which shouldn't take a competent technician more than a few days to knock together, will outperform Stripe.

bpicolo 9y ago
If you're convinced you can outperform Stripe in a couple days, you should probably be launching your own fraud-fighting saas, because you'll make a killing. It's a literal many-billion-dollar opportunity.
- dylz 9y ago
  I kind of want to take you up on this at a very basic level, as a weekend thing.
  - Scoundreller 9y ago
    Create an API so you can check them all with one request

rprime 9y ago

It depends. I've worked in the e-commerce industry for more than 10 years, not having proper fraud prevention is something that can bankrupt you. If you _know your customers_, it's easy to create a simple system that would at least notify you of possible fraudulent orders and let you take manual action. Even with the recent Stripe updates, we still see plenty of payments that go through even thought they should've definitely been caught, but because we've our own system in place, they get caught before doing any damage (and subsequently helping Stripe and marking the payments as fraudulent -- I wonder if I can get free Stripe credits for training their models using our own dumb heuristic based code).

jdietrich 9y ago
There's nothing wrong with adding your own checks based on your specific needs, but you need a baseline to build from. An early-stage startup or a small business just doesn't have the expertise to build a comprehensive fraud prevention system. Fraud prevention providers have huge databases to train their models on and an enormous amount of experience and expertise.

splonk 9y ago

Mostly agreed. I don't know anything specifically about Stripe, but I did work on fraud prevention systems for a major company. Being able to aggregate signals across multiple customers is a massive help in fraud detection - in terms of signal quality, bigger is better here. As a simple illustrative example from the article - a large provider will have history for email addresses and street addresses. Maybe they've seen lots of orders in the past from a given sketchy email address paired with a reshipping center that were all valid, which moves the risk of a transaction from "dodgy" to "probably fine". They'll have historical information that an individual merchant just won't have. That said, at some point you're going to need to have your own specialists involved, because the big providers aren't going to have the specific domain knowledge about your products/users to make good decisions around the margins. Plus you'll probably want to define your own tolerance for risk.