[mlm]

(I work at Stripe.)

For credit card processing, automated fraud prevention does in fact come standard on all Stripe accounts and takes into account a great number of signals including some that you brought up below, like whether the location of the IP address used matches the location of the billing address.

For ACH, we've built even more stringent verification--as well as any other signals we might take into account, purchasers have to demonstrate, through microdeposits or Plaid, that they have direct access to the bank account in question.

It's impossible to prevent all fraud, but we take it very seriously and are investing heavily in continually improving and expanding what we do there. It sounds like you may have had some specific bad experiences, and we'd love to hear your feedback and suggestions for improvement. Please do reach out--I'm [e-mail].

[tyingq]

Your description does not match Stripe's documentation. Specifically, there's no mention of matching geo-IP to billing address.

The problem I see with Stripe's fraud prevention is that it appears to be "all or none", with no visibility or control on our end.

The only control knob appears to be whether to allow Stripe to automatically decline things it thinks are fraud. It doesn't appear to provide any detail on why it thought something was fraud.

So it seems to leave two choices:

- Allow stripe to decline things, and try to address false positives manually. There is no "go ahead and charge this button", by the way...you would have to contact the customer.

- Set stripe not to decline things, but lose even the limited visibility to "stripe would have declined this".

The real problem, in my mind, is that fraud risk for both the banks and providers like Stripe is really small. You risk very little.

The vast majority of the cost goes back the individual merchants/sellers, who have the least visibility into what the risk of an individual transaction is.

Thus, there's very little incentive for the banks, or stripe, to provide decent tools. A shame, because your ability to see the bigger pictures means your tools would always be better than anything we can use.

[mlm]

We've been thinking about (and working on) a lot of these issues--we're definitely aware that users would like (totally reasonably!) more visibility and control. If you have any more feedback, I'd love to hear it!

[tyingq]

Appreciate the response. I suppose the most simple change would be visibility to "would have declined" if the "automatically decline detected fraud" buttons are set to off.

That would allow the flexibility for merchants to make their own decisions without the hassle of manually dealing with false positives. The trouble with the false positives is that you have to talk the customer into entering all their data again, without having anything specific to tell them, like "Er, you were declined, but I have no idea why...can you try again?".

[bebrown2]

Adyen does a good job providing a developer-centric platform with robust controls around fraud rules and other elements. I'd encourage you to benchmark them. You and your colleagues can also drop me an email anytime to discuss: [e-mail].

[rwmurrayVT]

This is not coming from a specific bad experience. Quite the opposite. I just got home from a commute. I will email you shortly.

I am curious how good it is if it is standard.. Some how major vendors lost quite a lot of money on hoverboards with Stripe.

[reviseddamage]

You mention Plaid for bank data scraping, but what do you do for the other banks Afaik Plaid supports about 12-13 banks (~80% population coverage).

[zachperret]

Plaid will be rolling out support for many more banks in the coming weeks.

[reviseddamage]

that's fantastic news and congrats on your deal with Stripe and your new funding.