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
Stripe is cheaper than most other processors and charges a flat rate for the transaction, regardless of the upstream cost. Amex is more expensive than Visa for example. A fact of doing business is that things will go up in price, as I'm sure your company also raises prices from time to time.

>>chadwi+do
I think what is being mentioned is that Stripe started keeping the original transaction fees on refunds. In my opinion this is borderline fraudulent since visa/mc/amex do not keep these charges and refund them back to Stripe.

>>poxrud+DD
You do realize that this is a free market? If visa/mc/amex are so much better, people can use them. Charging a flat fee for a service doesn't seem that fraudulent to me.

>>google+R41
Based on your comment you're clearly not a Stripe user, so I'm not sure why you felt the need to post this.

If visa/mc/amex are so much better, people can use them.

Stripe uses visa/mc/amex, it is not a competitor. You completely missed my point. Stripe uses visa/mc/amex to process credit card transactions, then when a refund is issued the CC companies return the charged amount to Stripe, but Stripe does not return the full amount back to the customer. They keep a percentage. This is what I consider "borderline fraudulent".

Charging a flat fee for a service doesn't seem that fraudulent to me.

But it is not a flat fee. They keep a percentage of the refunded amount. So if a customer bought a $1000 item, then changed their mind and cancelled the order 5 min later, Stripe would still keep $40 just for the fun of it. A small flat fee to cover network expenses would be more appropriate, not a percentage of the amount.