zlacker

>>mtlync+(OP)
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

>>pc+P7
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers.

Until it is.

Google once said their motto was "Don't be evil", look at where they are now.

Careful about those promises.

>>ta1234+ak
Indeed -- although our business model is, I think, more closely aligned with our users. We serve only one kind of customer: businesses receiving payments with Stripe. Our revenue is a roughly linear function of that of our customers.

>>pc+kk
I appreciate the security and the clarity on this issue. I only wish you didn't sneak in a pricing increase for long-standing users a few months ago, and I wish Stripe was more honest about its enterprise pricing.

>>michae+Em
I apologize that anything about the pricing change felt sneaky. (We tried to do the opposite: we emailed every single impacted customer!) I posted a few thoughts about the refund change here: https://news.ycombinator.com/item?id=22893388.

We're not transparent about enterprise pricing since our costs on any given user are so country/business model/implementation-dependent. It's less that our sales team isn't willing to share the details and more that the models themselves are very complicated and change frequently. (Visa and Mastercard are both making big changes to their pricing this year, for example, and that will change almost all of them.)

>>pc+uo
I appreciate that. My particular beef with the enterprise negotiation experience was that Stripe lists a specific number after which they're open to negotiating and when we'd far exceeded that number (with minimal fraud risk due to the nature of our business), their answer was "You have too many Amex customers, but aren't you happy you're grandfathered into x, y, and z feature we now charge extra for [which we don't even use]".

Then shortly after, Stripe raised pricing on a model I'd just been told was grandfathered in.