←back to thread

Stripe records user movements on its customers' websites

(mtlynch.io)
1134 points mtlynch | 3 comments | 21 Apr 20 17:01 UTC | HN request time: 0s | source
Show context
pc ◴[21 Apr 20 17:42 UTC] 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 #
seanwilson ◴[21 Apr 20 19:19 UTC] No.22938383[source]▶
> 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.

Can someone give an example of the kind of fraud schemes involving bots that this would stop? What are the bots programmed to do, how does it benefit the owner of the bots and how do you detect it?

replies(1): >>22938412 #
pc ◴[21 Apr 20 19:21 UTC] No.22938412[source]▶
Sure -- one very common form of attack is "card testing". Here's a quick summary: https://www.forbes.com/sites/tomgroenfeldt/2017/05/02/card-t....
replies(2): >>22938502 #>>22938580 #
1. philshem ◴[21 Apr 20 19:40 UTC] No.22938580[source]▶
My startup was recently facilitating card testing attacks via the Stripe checkout on our website. It wasn't small purchases, but just started and cancelled transactions.

Unfortunately, I was not alerted by Stripe, but by a "customer" whose credit card number had been stolen somewhere and who saw on his statement our company name (I'm not sure how, since the attackers don't complete the transaction).

The startup is dormant, so checking the Stripe dashboard isn't part of my daily routine. Or even my monthly routine. Even when it was active, we had only a handful of transactions - it's a niche market.

I contact Stripe customer support only because I thought the email from the "customer" could be a phishing attempt. Stripe customer support saw the logs and helped me roll a new public key. When I asked why I wasn't informed of such impossibly high token creation, the answer was that it wasn't a feature. When I checked the dashboard logs, I found that there had been 75k tokens created in the last 28 days (100% card testing). That's 75k stolen credit cards that my website (and Stripe) have helped to validate - and just in the last 4 weeks.

For all the promise of AI, I'd be happy just to get an alert that 75k tokens were created in four weeks, while exactly 0 (zero) completed transactions in the same period.

replies(2): >>22938700 #>>22938711 #
2. joering2 ◴[21 Apr 20 19:54 UTC] No.22938700[source]▶
> (I'm not sure how, since the attackers don't complete the transaction).

Its called "pre-auth" or "pre-authorization". It will show up on your statement for up to 48 hours but then will disappear since transaction is not "settled". During this period you would see a descriptor of transaction like NIKE NEW YORK 310XXXX, or if its dynamic/soft descriptor and merchant is utilizing it, it may say your order number and store like NIKE.COM 11-3939329.

3. jedberg ◴[21 Apr 20 19:56 UTC] No.22938711[source]▶
> but by a "customer" whose credit card number had been stolen somewhere and who saw on his statement our company name (I'm not sure how, since the attackers don't complete the transaction)

I detected a hacked database this way. My credit card (a burner from privacy.com) notifies me of any transaction, including pre-authorizations.

Most likely your customer saw the pre-auth show up.