Hah. This is in fact a problem area that our Billing (https://stripe.com/billing) team is actively thinking about. You should reach out to ark@stripe.com if you want to discuss -- he can connect you with the right folks.
17,202 karma · joined February 19, 2007
I'm one of Stripe's cofounders.
I do think that software complexity lifecycle management (and how that pertains to organizational considerations) is one of the tough problems in our industry. AWS has done an amazing job in terms of their pace of development and innovation, but, yes, it's also become a pretty complicated suite. I think we all currently face some kind of "fast development", "cohesive integration", "broad functionality" trilemma and how best to surmount it seems a big open question to me.
Stripe's growth thus far has been fueled by individual developers and founders signing up and growing with us to billions of revenue. As we scale, the "impatient developer" will remain the focus of our product development.
Over time, however, we've been increasingly finding that large organizations (like Zoom/Atlassian/Maersk) want to adopt Stripe -- Stripe now has a lot of functionality that they can't get elsewhere. So, we're very eager to continue to grow this side of our business with Mike.
No, it's not. This telemetry is useful for helping businesses avoid crippling fraud losses and we don't use or plan to use it for anything else. I don't think investors even know about it.
We're perfectly happy with the business model we currently have!
More broadly, I assure you that Stripe.js and our fraud prevention technologies are very carefully designed with full compliance with the relevant California (and other) statutes in mind. I’d be happy to connect you with our legal team if you’d like to discuss this in more detail. (I'm patrick@stripe.com.)
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.)
But, yes, part of the intent here is to enable us to achieve better ROC[1] in our models and to block more fraud while also encumbering fewer false positives. From our testing, it's very clear that these bot-detection techniques do substantially improve the accuracy when compared to other, coarser heuristics.
[1] https://en.wikipedia.org/wiki/Receiver_operating_characteris...
To your question about what the data actually includes and what the retention policies are -- we'll put together a summary of this on the page I mentioned in GP.
You're right that, if you don't use Stripe.js, PCI compliance will be more work.
And, yes, you can definitely include Stripe.js only on a single page.
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.)