←back to thread

1134 points mtlynch | 1 comments | | HN request time: 0.479s | source
Show context
pc ◴[] No.22937303[source]
Stripe cofounder here. The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative. This data has never been, would never be, and will never be sold/rented/etc. to advertisers.

Stripe.js collects this data only for fraud prevention -- it helps us detect bots who try to defraud businesses that use Stripe. (CAPTCHAs use similar techniques but result in more UI friction.) Stripe.js is part of the ML stack that helps us stop literally millions of fraudulent payments per day and techniques like this help us block fraud more effectively than almost anything else on the market. Businesses that use Stripe would lose a lot more money if it didn't exist. We see this directly: some businesses don't use Stripe.js and they are often suddenly and unpleasantly surprised when attacked by sophisticated fraud rings.

If you don't want to use Stripe.js, you definitely don't have to (or you can include it only on a minimal checkout page) -- it just depends how much PCI burden and fraud risk you'd like to take on.

We will immediately clarify the ToS language that makes this ambiguous. We'll also put up a clearer page about Stripe.js's fraud prevention.

(Updated to add: further down in this thread, fillskills writes[1]: "As someone who saw this first hand, Stripe’s fraud detection really works. Fraudulent transactions went down from ~2% to under 0.5% on hundreds of thousands of transactions per month. And it very likely saved our business at a very critical phase." This is what we're aiming for (and up against) with Stripe Radar and Stripe.js, and why we work on these technologies.)

[1] https://news.ycombinator.com/item?id=22938141

replies(52): >>22937327 #>>22937331 #>>22937352 #>>22937362 #>>22937385 #>>22937475 #>>22937518 #>>22937526 #>>22937559 #>>22937599 #>>22937775 #>>22937815 #>>22937962 #>>22938015 #>>22938068 #>>22938208 #>>22938310 #>>22938383 #>>22938533 #>>22938646 #>>22938728 #>>22938777 #>>22938855 #>>22938884 #>>22939026 #>>22939035 #>>22939376 #>>22939803 #>>22939814 #>>22939916 #>>22939952 #>>22940051 #>>22940090 #>>22940177 #>>22940282 #>>22940315 #>>22940317 #>>22940352 #>>22940686 #>>22940751 #>>22941252 #>>22942502 #>>22942538 #>>22942710 #>>22942907 #>>22943100 #>>22943453 #>>22944163 #>>22944509 #>>22944652 #>>22945170 #>>22946136 #
advaita ◴[] No.22937599[source]
millions of fraudulent payments per day

Are there ways for transparently communicating (verifiable) stats for this claim?

To be clear, I am not saying that your claim is not true but if one thing HN has taught me, it is to always ask for data backing up claims that are tall.

replies(3): >>22937708 #>>22937869 #>>22938141 #
pc ◴[] No.22937708[source]
Not sure what verifiable stats could look like here, I'm afraid... but I can assure you that it is in fact true!
replies(2): >>22937751 #>>22938241 #
gruez ◴[] No.22937751[source]
For one, some definitions would be nice. How do you define "fraudulent payments"? If I tried to checkout while on VPN and firefox with resistfingerprinting enabled, and your antifraud system stopped me, did that count toward your "millions per day"?
replies(1): >>22938008 #
pc ◴[] No.22938008[source]
We build models that predict P(payment charged back as 'fraudulent') and then let small random samples through in order to test the accuracy of our predictions. This calibration means that we can compute a pretty accurate "true" total from those we have blocked.
replies(1): >>22938524 #
cosmie ◴[] No.22938524[source]
Out of curiosity, when a transactions is part of one of those random samples and is flagged as fraudulent, are the costs/impacts to the merchant the same as any other fraud chargeback/dispute (particularly those that don't use Stripe Chargeback Protection)?
replies(1): >>23005560 #
1. _Microft ◴[] No.23005560[source]
The question was interesting. Too bad we did not get an answer here.