16 ms·

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

by pc 6y ago

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 https://news.ycombinator.com/item?id=22938141

kelvin0 6y ago
From my naive perspective, if the CC or other provider validate the customer's credentials all is good and you get paid. Integration of a payment method seems fairly simple and straightforward (I'm not a web dev). I don't really know about the types of fraud that are possible and what a Saas should be prepared for. Question: what are the typical fraudulent activities and their symptoms?
Lukesys 6y ago
Dude, you are a machine!
sam1r 6y ago
In other words, it’s useful data for them to collect as a whole..
jimhi 6y ago
While I believe this, you might want to add a way for the developer to disable certain GET variables or pages from being sent. I doubt sending everything helps Stripe detect fraud.
- pc 6y ago
  Yes, this is a good point.
- hombre_fatal 6y ago
  You can already selectively include it on pages. And it doesn't make sense to me to "disable certain [parts of the url]".
  - jimhi 6y ago
    Some websites send sensitive or identifying data in their GET variables. I personally have analytics data on my pages I don't want to give to Stripe for no reason and definitely does not help them track fraud.
mmastrac 6y ago
Awesome response, handled exactly as it should have been. There was a clear ambiguity in the terms, clarified and then codified.
- sixQuarks 6y ago
  I didn't even read the article. I immediately clicked through to the comments because I knew Patrick would clarify it. Stripe is one of a handful of companies I actually trust.
mtlynch 6y ago
Hi Patrick, thanks for reading! Glad to hear you're going to clarify that language in the ToS. I'm interested to know if you're open to implementing mechanisms that limit what data Stripe collects within my app. I'm happy to help Stripe prevent chargebacks against my app, but I'd like to be in control of what parts of my app's data I hand over to help achieve that rather the current situation which basically grants the library carte blanche to vacuum up whatever data it wants.
- pc 6y ago
  Yep, certainly open to that. We'll address that in the page we put together about this.
  - skoskie 6y ago
    This should be a case study in how to properly handle bad press. Of course, it helps when you’re Doing The Right Thing™ to begin with, as it limits your recovery to simple reassurance of the user base. Still, it appears this is being handled exceptionally well.
- bdcravens 6y ago
  Would it make sense to update your blog post to include pc's response?
  - mtlynch 6y ago
    Yep, I linked to it at the bottom.
deleted 6y ago
[deleted]
darknoon 6y ago
As an end user, can you provide me with all of the event data you have collected about me? Or does Stripe help sites that integrate stripe.js to respond to data requests? Ie, CCPA / GDPR says I have the right to see and correct it if I live in one of those jurisdictions.
- lmkg 6y ago
  CCPA has a Right to Access like GDPR does, but it does not have a Right to Rectification. Under both laws, if Stripe claims to be a Processor/Service Provider, then they have an obligation to facilitate sites using Stripe to respond to access requests. But they have no obligation to process those requests themselves. I think CCPA requires they direct you to the actual Controller, but that's one aspect of CCPA that has changed since December.
- lrpublic 6y ago
  You could send a subject access request to dpo@stripe.com - it would be interesting to see how they respond if you share the unique identifier mentioned in the article.
brogrammernot 6y ago
We’re big-time Stripe users (ACH mostly to the tune of $300M+ annually) but soon will be branching into debit/credit & in the research so far have found the Radar product impressive. Having this information up-front and center makes it easier to pass to our Infosec folks + another check in the transparency box. As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already. The JS package is really nifty and helpful though, we will be able to standup a one-off late payment page utilizing their checkout flow & one-time payments (server/client - couldn’t expose all the SKUs to folks so had to go that route instead of just client) but the fact we could use Stripe to send the emails with our branding & all we have to really do is pull the payment they owe & create a checkout session to hand-off to Stripe is pretty awesome.
- pc 6y ago
  Glad you're liking Radar! 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.
  - brogrammernot 6y ago
    We are, indeed. As far as PCI compliance, I was just saying your comment about more work is true depending on your setup w/o using Stripe.js. In our business we already have our own proprietary fraud models and other PII we secure, so the level of effort to keep PCI compliance for the additional Stripe components is a wash whether or not we use Stripe.js I totally agree if you're going to use Stripe and you don't have to deal with PCI already in your normal course of business it's a complex area to navigate & using stripe.js is a much smoother path to take. Basically goes back to basic principles, don't add more stress or work for something outside your core competencies unless necessary & in many cases, I can see where companies should just leverage stripe.js plus the UI utilities as they're well done & save a lot of time. Big fans of Stripe, even if your ACH rates are significantly more than Wells Fargo or others :P
  - 6y ago
drocer88 6y ago
"This data has never been, would never be, and will never be sold to advertisers or any other third parties. " Does this mean it "will not be shared with or rented to" advertisers?
- pc 6y ago
  Yes.
- lotsofpulp 6y ago
  “Will never be sold” is an unprovable claim. I assume if any company has a liquidity crisis, all assets are up for sale.
advaita 6y ago
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.
- pc 6y ago
  Not sure what verifiable stats could look like here, I'm afraid... but I can assure you that it is in fact true!
  - gruez 6y ago
    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"?
    - pc 6y ago
      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.
      - cosmie 6y ago
        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)?
        _Microft 6y ago
        The question was interesting. Too bad we did not get an answer here.
beervirus 6y ago
How long is this data retained, and what does it actually include? > This data has never been, would never be, and will never be sold/rented/etc. to advertisers. Unless Stripe goes bankrupt, in which case it'll be liquidated along with all the other assets.
- pc 6y ago
  I'll ask our legal team if we can somehow contractually preclude ourselves from sharing this data in the case of liquidation or otherwise bind ourselves in a useful fashion... 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.
  - pilingual 6y ago
    If you get clarity on liquidation, please consider open sourcing it à la YC's startup documents. It's something I've long wanted to include in my projects.
  - rkagerer 6y ago
    I hope the result has some teeth to it, and I'd like to see follow up once this item is complete. If I were negotiating for a vendor to collect such an invasive level of personal data about me or my customers, I would insist on accordingly strong protections. At a minimum there should be clause in your ToS making our consent expressly contingent on you upholding your protection commitments, particularly around what data is collected, who it's shared with, and when it is destroyed or 100% anonymized. It should insist you have contracts containing terms of equal strength in place with any of your vendors, subcontractors, partners, etc. who might conceivably gain access to the sensitive data. The clause should be written such that the liability follows along to any assigns, heirs, successors, etc, and it should be excluded from any loopholes in other portions of the contract (particularly any blanket ones which allow you to change the ToS without gaining fresh, explicit consent) and preferably free from any limitations of liability. I'm glad Stripe is taking a responsive approach to the matter and I hope you'll consider this feedback when you revisit your legal agreements.
  - 6y ago
lrpublic 6y ago
And how much GDPR risk? Is it not the case that sites using this would have to explicitly gain consent from visitors to capture data in advance?
- lmkg 6y ago
  Under GDPR, no. Fraud detection is the canonical Legitimate Interest, and the only one mentioned by name in the text of the law. PECR is a different matter. That's more restrictive but I'm not sure about the exact contours of what's considered "essential."
  - lrpublic 6y ago
    I don’t think recital 47 allows carte blanche data collection in the name of fraud detection, and at the very least I would think there is an obligation for disclosure of the data collection, a mechanism to access it (DSAR) and the ability to correct inaccuracies.
    - lmkg 6y ago
      You're correct about all of these points. GDPR still means that the principles of transparency, purpose limitation, data minimization, etc. are in play, as are data subject rights like access, rectification, and erasure. I was only addressing the specific issue of consent from your previous comment. Consent wouldn't be necessary if there's a different legal basis, and fraud detection qualifies as a Legitimate Interest. Note that collecting consent still doesn't give you carte blanche to collect all the datas. The principle of data minimization still restricts you to only the data you need for the purpose you state when gathering consent.
      - lrpublic 6y ago
        For the avoidance of doubt, the main point of my comment was the not insignificant risk (a maximum fine of 20 million euro or 4% of turnover if that is greater) if a data controller does not meet the obligations of the GDPR. Consent, as you point out, is only one aspect of this.
asclepi 6y ago
Here's hoping it also reduces the exorbitant amount of false positives we've been seeing with Stripe's fraud prevention services, which cost us a lot in lost legitimate sales.
- pc 6y ago
  I'm sorry to hear that! Feel free to email me (patrick@stripe.com) and I'll connect you with the team if you'd like us to do a deeper dive. 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_characteristic https://en.wikipedia.org/wiki/Receiver_operating_characteris...
  - gmu3 6y ago
    A user shouldn't have to email a cofounder to get in touch with a team member. The last time I integrated stripe on a site as a final test before it went live I had my cousin make a purchase and the site got flag as potential money laundering because we had the same last name. At the time literally zero customer service. It took 8 years before stripe started doing any customer support. Cool launch pages but personally I'll never use stripe again
    - ryneandal 6y ago
      It isn't the only source for getting support for a particular issue, calmate.
    - globile 6y ago
      We have the opposite problem. People with 50 carding attempts and radar scores of 30 or so. There is no value in Radar if so many of these cases pop up because you can’t really tell the truth from the false. We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases. Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.
carapace 6y ago
FWIW, reading this I thought "Isn't that for fraud detection?" and then I got to the part where your agent says "it's for fraud detection"... I'm normally against this sort of thing (even though everybody does it, it seems like) but in this case, it's clear that this really is "works as intended" at least to me, FWIW.
- skoskie 6y ago
  My thoughts exactly as I was reading. Analytics gathering that’s not related to UI improvements wouldn’t bother to collect information on pointer movements. But it turns out to be a pretty good tool for bot detection. That’s why you can now just check a box to verify you’re human (Something about that sentence feels quite dystopian). I just don’t see the issue with Stripe’s practice here. They have a clear business model, and selling user data could severely undermine that model.
  - amenod 6y ago
    Sure, but business models change. The main issue here is that this behavior is enabled by default and hidden. If API would be used like this, I would see no problem: ``` import { ensureUsersAreTrackedForFraudPrevention, loadStripe, } from '@stripe/stripe-js'; ensureUsersAreTrackedForFraudPrevention() ``` Of course, they will never do that, because then many developers would opt-out, and they need the masses to make fraud prevention work.
    - djur 6y ago
      If the API was used like that it could be disabled trivially by someone committing fraud.
    - hjnilsson 6y ago
      Likely many developers would opt-in when business sees the 5% surcharge for extra fraud. And regardless, stripe explicitly says in their documentation that you should include stripe.js on every page of your app, so they can do tracking of pointers movements for fraud detection. This has not been hidden in any way from devs.
ta1234567890 6y ago
> 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.
- pc 6y ago
  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.
  - michaelsitver 6y ago
    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.
    - pc 6y ago
      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 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.)
      - michaelsitver 6y ago
        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.
im3w1l 6y ago
If it's recorded and transmitted it can be intercepted by intelligence agencies.
ddevault 6y ago
Hey pc, good to see you here on HN. Things like this bother me as a Stripe customer who advocates strongly for privacy. I've asked repeatedly for options which let me have more control over what exactly is happening on my page - or to have a JavaScript-free flow on Stripe.com that I can redirect users to in order to complete their card details. Another easy option would be to use subresource integrity so that I can audit each release of Stripe.js, but your team has turned this down, too. Of course, I could go full PCI, but PCI compliance is a big burden for small businesses. Do you have any plans for making Stripe more accomodating of users with privacy concerns?
- pc 6y ago
  Hi ddevault -- we would like to do this, and I'm very supportive in principle (and, per GP, we are perfectly fine with anyone not using Stripe.js), but our current product/engineering focus is on trying to build better tools for the businesses who are losing tens or hundreds of thousands of dollars to fraud. We think we have to first help the businesses who need help immediately. We'll probably then circle back to build products that explore more points on the [efficacy of fraud prevention] - [PCI burden] continuum.
  - ddevault 6y ago
    Thanks for the info, pc! I'm worried that this is a dismissive answer, though. Stripe has been in business for 10 years, and fraud has been and will continue to be a constant battle for you. When can I expect to start seeing other problems like this prioritized?
    - pc 6y ago
      Definitely no dismissiveness intended -- apologies. While Stripe has been in business for 10 years, Radar (our fraud prevention tool) has only existed for 3.5. We've made a good deal of progress in that time and I would guess that it's 1-2 years away from being sufficiently complete that we can start to seriously focus on things other than fraud. (As it happens, I just had a conversation about this with the guy who leads it.)
meowface 6y ago
In my opinion, there's no moral issue with doing this. Fighting fraud and other kinds of cybercrime is an endless cat-and-mouse game. Although there are very bad associations with it, one simply does need to use fingerprinting and supercookies/"zombie cookies"/"evercookies" if they want even a fighting chance. I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though.
- mtlynch 6y ago
  > I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though. Is this view conditional on the type of data Stripe is currently collecting or would it apply to any data Stripe collects? Would this be true if Stripe began recording every keystroke in the app and hooked every XHR request to my backend server and sent copies to Stripe? I agree that Stripe has a sensible reason for using this data. If I started seeing a high rate of chargebacks, I'd consider enabling Stripe on more parts of my site so that Stripe could consume user behavior earlier on to detect fraud. My issue is that if there's no agreement about what data Stripe is allowed to collect and what their retention policies are, then the implicit agreement is that Stripe can just collect anything it has access to and hold it forever. As JavaScript running on my page, Stripe.js has access to basically all user data in my app. There are certain types of user data I would not be comfortable sharing with Stripe, even if it improved fraud detection, so I'd like there to be clear limits on what they're gathering.
  - meowface 6y ago
    Yes, I would say it's conditional. They should be more explicit about what data they're collecting from users. Opaque enough to not reveal all of the exact techniques, but clear enough so site owners can make an informed decision. (Someone dedicated and experienced enough could probably reverse engineer Stripe.js and figure out everything it's doing if they really wanted, but they're also probably updating it regularly.)
seanwilson 6y ago
> 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?
- pc 6y ago
  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-testing-by-fraudsters-is-up-200-percent-this-year/#235f6fbc19e4 https://www.forbes.com/sites/tomgroenfeldt/2017/05/02/card-t....
  - seanwilson 6y ago
    > Credit card testing, a tactic used by fraudsters to test stolen credit card numbers with small incremental purchases before making large-dollar purchases on the card Testing for what? That the card hasn't been cancelled or has zero money on it? Can they test for how much money is on the card or anything else useful? And they need bots because they might have say 1000s of cards from a database hack and most of the cards won't be useful? What kind of large dollar purchases would someone try to make once a card has been confirmed? Why not let bots attempt lots of large dollar purchases?
    - kayfox 6y ago
      They test the cards so that they can sell the card list and promote such a sale with assertions about how much of it is good (100% tested, etc). These brokers don't want to get involved in any significant fraudulent charges for various reasons.
      - seanwilson 6y ago
        Once you have a stolen card though, what large purchases could you realistically get away with that won't leave an audit trail right back to you?
kristianc 6y ago
Having worked at an ML fraud prevention company, can confirm that this is a pretty standard part of a fraud prevention stack. It's essentially used to block credential stuffing. There's a high probability your bank also does this.
- XelNika 6y ago
  There's a difference between doing collecting data on your own site and doing it on third-party sites so banks are a bad example (unless your banks work differently than mine).
  - kristianc 6y ago
    Banks only don’t do it on third party sites as they very rarely have third party endpoints. If they did, they would do it there too. If you want an example of another payment processor that does this - Authorize, PayPal, WorldPay will all do this too.
threepio 6y ago
Stripe customer here. The question raised is, more broadly, "Is Stripe collecting this data in a legal and ethical way?" This too can be readily answered in the negative. It doesn't matter whether "Stripe.js collects this data only for fraud prevention" or if it works in practice. Under CalOPPA [1], Stripe still has to disclose the collection of the data, and (among other things) allow customers to opt out of collection of this data, and allow customers to inspect the data collected. Stripe's privacy policy refers to opt-out and inspection rights about certain data, but AFAICT not this. [This is not legal advice] [1] http://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?lawCode=BPC&division=8.&title=&part=&chapter=22.&article= http://leginfo.legislature.ca.gov/faces/codes_displayText.xh... [2] https://stripe.com/privacy#your-rights-and-choices https://stripe.com/privacy#your-rights-and-choices
- pc 6y ago
  https://stripe.com/privacy https://stripe.com/privacy describes what we do in some detail (including disclosing that we use this kind of browsing data). 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.)
  - jonny_eh 6y ago
    Why not address it here publicly? I don't think you want/expect everyone observing this discussion on HN to reach out to you.
    - deleted 6y ago
      [deleted]
    - pc 6y ago
      Oh, offer was made in case GP wants to have a deeper discussion/back-and-forth than is readily achievable with an online forum. Timing constraints notwithstanding, we work hard to answer questions on HN too.
lixtra 6y ago
>> Stripe records the full URL, including query parameters and URL fragments (e.g., /account?id=12345#name=michael), which some websites use to store sensitive information. Can you comment on this part as well? If you collect sensitive data unbeknownst to website owners and users you are most likely in for some trouble (i.e. gdpr)
jbverschoor 6y ago
Put your money where your mouth is, and put in the terms that this data will ever be sold/rented to advertisers. If it is, pay a penalty of $25 per datapoint. Also, if not advertisers, who will get this information? Make it any “third party”.
- jbverschoor 6y ago
  Woohoo bury mob
e_commerce 6y ago
Please reduce fees. Stop collecting fees on refunds.
rglover 6y ago
This goes without saying but I love it when Patrick jumps in to respond to stuff like this on here (and always thoughtfully, too).
mwcampbell 6y ago
> (CAPTCHAs use similar techniques but result in more UI friction.) Not only are they inconvenient, but they're often inaccessible for some users. So I just wanted to say thanks for not going that way, even if the cost we must pay is some theoretical compromise in privacy. Edit: On thinking about this some more, it occurred to me that by using a user's activities on a web page to determine whether they're a bot committing fraud, you might be inadvertently penalizing users that use assistive technologies, such as a screen reader, voice input, eye-tracking, etc. I haven't had a problem with this when doing a Stripe checkout with a screen reader, but I just wonder if this possible pitfall is something that your team has kept in mind.
- abiogenesis 6y ago
  If they are really in full compliance with the relevant California (and other) statutes as the co-founder claimed they must have also taken the accessibility aspect into account.
3xblah 6y ago
"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." The language of the revised ToS could go something like "Stripe shall only use the data for fraud prevention. Stripe shall not permit the data to be used for any other purpose, inlcuding, without limitation, any use that aims to increase customer acquisition or sales of products or services." The problem with statements like "We only use the data for X" is that this is not a limitation. It is perhaps a representation of what Stripe is doing as of the date of the ToS, however it does not mean Stripe does not have permission to use the data for any other purpose. Further, it only applies to Stripe. Another party could be using the data for some other purpose besides fraud prevention and the statement would still be true. Nothing requires that there be a sale or "rental" for another party to make use of the data. The problem with statements like "We will never sell/rent/etc. the data to Y" is that it does not prevent Stripe from using the data to help Stripe or other parties to sell products and services. Stripe does not need to sell or rent the data to provide that assistance. To recap, a ToS should limit how the data can be used. Stating how a company currently uses the data is not a limitation. Stating that a company will not sell or rent the data does not necessarily limit how the data can be used by that company or anyone else. Facebook does not sell or rent data but their collection of data ultimately results in more advertising on the web, and on Facebook-owned websites. How does that happen. The first problem is the collection of data above and beyond what is needed to fulfill a user's request, i.e., the purpose for which it was collected. Ideally we could stop the unnecessary collection of user data, e.g., through law and regulation, and this would reduce the amount of data we need to worry about. The second problem is that after users "agree" to the collection of data, there are no contractual obligations on the collector over how the data can be used, other than not sharing it.
dmit 6y ago
> The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative. Are Stripe co-founders paid by the word, or did that message get through about two dozen lawyers before being posted?
mhdhn 6y ago
It could be disclosed with a court order though, right?
woodandsteel 6y ago
>This data has never been, would never be, and will never be sold/rented/etc. to advertisers. Is there a reliable, independent way your customers can verify this statement is true? Or is it perhaps your position that there is no legitimate reason for people to want this? And let me add that "Nobody else does this" is not a suitable answer.
andrewstuart 6y ago
You're expecting people to trust Stripe. The problem is that there's not much reason left to trust tech companies by default.
jonplackett 6y ago
It's nice when you go into the comments expecting the worst, that Stripe are now one of the bad guys after all, only to find a perfectly reasonable explanation and a clarification from someone talking plain english. Nice.
samstave 6y ago
Can you please go into more detail about the exact method that “sophisticated fraud rings” use to attack? Like what specifically do they do, please ELI5
cosmotic 6y ago
Updating the TOS on the Stripe site doesn't really apply when the site executing the script is the site that consumes the API. The user of the consumer site never sees the Stripe TOS.
neop1x 6y ago
It's like installing anti-cheating rootkit to windows kernel. It's like recording your voice, taking retina scan, requiring you to take off your clothes and bugging a GPS device on you before swiping a card in a physical shop. How can it be possibly OK? For fraud prevention? Yes, if every customer were under 24/7 surveilence, there wouldn't be frauds (nor terrorists). Unless they were too smart to hack all the devices and fake the data. It is very wrong and there is no way it can be justified to monitor all URLs and mouse movements before the payment. Having javascript available doesn't mean you are allowed use it for spying on customers! Black Mirror in real life. It will get worse if people accept this and agree with this. Quite sad. :(
bobblywobbles 6y ago
Thanks for posting this explanation and making an effort to update your terms of service to call out this behavior. We appreciate that you are intent on fixing this, it helps us know that there are honest people working at Stripe and helps clear the fog that what seem to be a lot of us believing you are doing malicious things. I hope you and your family stay healthy during this pandemic.
EastSmith 6y ago
> 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 So, in order of Stripe to make more money (1.5% less fraud), you chose to track everybody. Probably me too. Thanks for that.
softwarejosh 6y ago
i worked for a company that made tools like this for diagnosing ui flow issues with machine learning, its possible and likely some companies use this for tracking their users, but it has some meritable uses as well.
rmrfrmrf 6y ago
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers. I don't think first-order data access is really the problem here, but rather where that data is going in general and who is authorized to access it, for how long, etc., and the volume of data any one person has access to at one time.
SquishyPanda23 6y ago
> This data has never been, would never be, and will never be sold/rented/etc. to advertisers. This is kind of a straw man. These valuable data sets are typically kept by tech companies to keep a competitive edge. For example, not even Google sells or rents user data. The more relevant question is "is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?" My guess is that the answer to this is likely yes. Fraud prevention is the current product built on this data. But it would be shocking if the company never put the data set to additional uses.
- pc 6y ago
  > Is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?" 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!
  - SquishyPanda23 6y ago
    Okay thanks for the prompt response!
    - pc 6y ago
      Hey, that's not how arguments on the internet are supposed to go :-).
      - fb03 6y ago
        ^ What an insanely good interaction, right here.
      - SquishyPanda23 6y ago
        Haha :) I'll take this moment to say I appreciate how active you've been on HN responding to questions every time a Stripe article pops up. I realize this can't be very fun for you to have this as the top result for the last however many hours.
techntoke 6y ago
I recently was denied a credit application because I used Linux when I filed out the application. Not only that, but they still ran my credit. They even told me on the phone the reason they denied my application because I was using a suspicious browser (Chromium). Let's be honest here. Stripe.js may be about fraud prevention, but what that means is that you'll use every method available to gather data about that individual to build an identity. Then in 3 years when someone changes positions, that system will end up getting compromised, sold to the highest bidder, shared with some government agency, or used for nefarious purposes. This will be tied to all their IP, OS information, transactions, etc. Just like they are using facial recognition at several retail stores. They make you use a chip reader now for credit/debit transactions, but it has no use online. I'd rather see an open-source universal effort towards decentralized currency, voting, identity, etc.
- djsumdog 6y ago
  I'm running into more and more things that claim they don't support Firefox on Linux. We're headed to browser monoculture
juped 6y ago
There's many instances when someone from $company shows up in one of these threads on "$company is doing something nefarious" to do damage control... and I think this is the first one that doesn't reflect poorly on the $company in question. The reason for this is that Stripe did do something wrong, and it wasn't in the script - it was in the disclosures and communication surrounding the script. So rather than PR spin, this is actually addressing the real problem. To all other companies (and Stripe on some other day), this one thread is the exception that proves the rule that damage control in internet comments is a bad look.
masterfooo 6y ago
You got caught, spin it as much as you want. This has nothing to do with fraud. We know you got caught because of the speed of your response. This is called damage control, there is also a more scientific name for it called plausible deniability. I am disgusted with this form of surveillance. I will make sure that I won`t use Stripe in the future and force vendors to use something else.
yashap 6y ago
This seems like a pretty good reason to phone home with this data, but ... sending back urls WITH query params? It’s pretty common for sensitive data to be in query params, sometimes even things like bearer tokens. I can’t see how query params would be very useful for fraud detection, and sensitive data like this is something you really want to avoid collecting, IMO that’s low hanging fruit to remove.
- unreal37 6y ago
  That's just bad application design to have sensitive info in the URL.
xyst 6y ago
Since when do billionaire CEOs respond to these types of posts?
pulse7 6y ago
How can you say "...will never be sold/rented/etc. to advertisers"? Are you the fortune teller or a prophet? In case of a new CEO or changed ownership everything can change...
- volgar1x 6y ago
  Does that kind of data even have value for advertisers ? Beside the user tracking cookie I personally think the rest is fine if Stripe cannot tell some kind of buyer pattern (and sell it).
amelius 6y ago
Be careful with that. We have seen recently (see social distancing apps) that even public health does not justify invasion of privacy, so why should online fraud?
toasted_flakes 6y ago
This isn't Stripe's fault here, but if to make a payment online you need to track everyone just to make sure the transaction isn't fraud, then the system is broken. Why can't online payments use a use two-factor authentication by default?
- unreal37 6y ago
  Because, "business". That is, sales will drop for anyone who does this. That's friction that will reduce sales, and online sellers will move to a provider that does not do this. Stripe would go out of business if it made it more difficult to buy things.
philip1209 6y ago
It seems like sending users to the new Stripe-hosted Checkout would probably be better for everybody, too.
Frost1x 6y ago
>This data has never been, would never be, and will never be sold/rented/etc. to advertisers. I chortled a bit. Everything beyond has is questionable, though I believe there is sincerity about past actions and maybe even ethical business considerations. If location data can be used for supplemental revenue in a fashion that won't hurt revenue more than help revenue, it will, it's only a question of when. It may or may not be advertising, but it absolutely will be used for all sorts of functions beyond fraud detection (if it's not already), especially once Stripe is publicly traded and/or gobbled up by some other massive business.
cookiengineer 6y ago
Don't get me wrong, but a lot of CTOs said so in the past...including the one responsible for the infamous google PREF cookie that helped the NSA spy on literally the whole planet due to how google safe browing service has to be implemented. As long as there's no control, your statement is worth nothing. Even if you are acting morally correct with the data, your future replacement might not. PayPal were the good guys, too, until they were not. In my opinion these tracking mechanisms are not GDPR compliant, as there's no opt-out possibility.

by pc 6y ago

kelvin0 6y ago

From my naive perspective, if the CC or other provider validate the customer's credentials all is good and you get paid. Integration of a payment method seems fairly simple and straightforward (I'm not a web dev). I don't really know about the types of fraud that are possible and what a Saas should be prepared for. Question: what are the typical fraudulent activities and their symptoms?

Lukesys 6y ago

Dude, you are a machine!

sam1r 6y ago

In other words, it’s useful data for them to collect as a whole..

jimhi 6y ago

While I believe this, you might want to add a way for the developer to disable certain GET variables or pages from being sent. I doubt sending everything helps Stripe detect fraud.

pc 6y ago
Yes, this is a good point.
hombre_fatal 6y ago
You can already selectively include it on pages. And it doesn't make sense to me to "disable certain [parts of the url]".
- jimhi 6y ago
  Some websites send sensitive or identifying data in their GET variables. I personally have analytics data on my pages I don't want to give to Stripe for no reason and definitely does not help them track fraud.

mmastrac 6y ago

Awesome response, handled exactly as it should have been. There was a clear ambiguity in the terms, clarified and then codified.

sixQuarks 6y ago
I didn't even read the article. I immediately clicked through to the comments because I knew Patrick would clarify it. Stripe is one of a handful of companies I actually trust.

mtlynch 6y ago

Hi Patrick, thanks for reading! Glad to hear you're going to clarify that language in the ToS. I'm interested to know if you're open to implementing mechanisms that limit what data Stripe collects within my app. I'm happy to help Stripe prevent chargebacks against my app, but I'd like to be in control of what parts of my app's data I hand over to help achieve that rather the current situation which basically grants the library carte blanche to vacuum up whatever data it wants.

pc 6y ago
Yep, certainly open to that. We'll address that in the page we put together about this.
- skoskie 6y ago
  This should be a case study in how to properly handle bad press. Of course, it helps when you’re Doing The Right Thing™ to begin with, as it limits your recovery to simple reassurance of the user base. Still, it appears this is being handled exceptionally well.
bdcravens 6y ago
Would it make sense to update your blog post to include pc's response?
- mtlynch 6y ago
  Yep, I linked to it at the bottom.

deleted 6y ago

[deleted]

darknoon 6y ago

As an end user, can you provide me with all of the event data you have collected about me? Or does Stripe help sites that integrate stripe.js to respond to data requests? Ie, CCPA / GDPR says I have the right to see and correct it if I live in one of those jurisdictions.

lmkg 6y ago
CCPA has a Right to Access like GDPR does, but it does not have a Right to Rectification. Under both laws, if Stripe claims to be a Processor/Service Provider, then they have an obligation to facilitate sites using Stripe to respond to access requests. But they have no obligation to process those requests themselves. I think CCPA requires they direct you to the actual Controller, but that's one aspect of CCPA that has changed since December.
lrpublic 6y ago
You could send a subject access request to dpo@stripe.com - it would be interesting to see how they respond if you share the unique identifier mentioned in the article.

brogrammernot 6y ago

We’re big-time Stripe users (ACH mostly to the tune of $300M+ annually) but soon will be branching into debit/credit & in the research so far have found the Radar product impressive. Having this information up-front and center makes it easier to pass to our Infosec folks + another check in the transparency box. As far as not using the JS, I was under the impression as long as you’re not storing the account or card numbers & utilizing the tokens properly you’re still at the base level of PCI compliance - meaning you’re securing your website, endpoints, data store etc in the same manner you should be already. The JS package is really nifty and helpful though, we will be able to standup a one-off late payment page utilizing their checkout flow & one-time payments (server/client - couldn’t expose all the SKUs to folks so had to go that route instead of just client) but the fact we could use Stripe to send the emails with our branding & all we have to really do is pull the payment they owe & create a checkout session to hand-off to Stripe is pretty awesome.

pc 6y ago
Glad you're liking Radar! 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.
- brogrammernot 6y ago
  We are, indeed. As far as PCI compliance, I was just saying your comment about more work is true depending on your setup w/o using Stripe.js. In our business we already have our own proprietary fraud models and other PII we secure, so the level of effort to keep PCI compliance for the additional Stripe components is a wash whether or not we use Stripe.js I totally agree if you're going to use Stripe and you don't have to deal with PCI already in your normal course of business it's a complex area to navigate & using stripe.js is a much smoother path to take. Basically goes back to basic principles, don't add more stress or work for something outside your core competencies unless necessary & in many cases, I can see where companies should just leverage stripe.js plus the UI utilities as they're well done & save a lot of time. Big fans of Stripe, even if your ACH rates are significantly more than Wells Fargo or others :P
- 6y ago

drocer88 6y ago

"This data has never been, would never be, and will never be sold to advertisers or any other third parties. " Does this mean it "will not be shared with or rented to" advertisers?

pc 6y ago
Yes.
lotsofpulp 6y ago
“Will never be sold” is an unprovable claim. I assume if any company has a liquidity crisis, all assets are up for sale.

advaita 6y ago

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.

pc 6y ago
Not sure what verifiable stats could look like here, I'm afraid... but I can assure you that it is in fact true!
- gruez 6y ago
  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"?
  - pc 6y ago
    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.
    - cosmie 6y ago
      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)?
      - _Microft 6y ago
        The question was interesting. Too bad we did not get an answer here.

beervirus 6y ago

How long is this data retained, and what does it actually include? > This data has never been, would never be, and will never be sold/rented/etc. to advertisers. Unless Stripe goes bankrupt, in which case it'll be liquidated along with all the other assets.

pc 6y ago
I'll ask our legal team if we can somehow contractually preclude ourselves from sharing this data in the case of liquidation or otherwise bind ourselves in a useful fashion... 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.
- pilingual 6y ago
  If you get clarity on liquidation, please consider open sourcing it à la YC's startup documents. It's something I've long wanted to include in my projects.
- rkagerer 6y ago
  I hope the result has some teeth to it, and I'd like to see follow up once this item is complete. If I were negotiating for a vendor to collect such an invasive level of personal data about me or my customers, I would insist on accordingly strong protections. At a minimum there should be clause in your ToS making our consent expressly contingent on you upholding your protection commitments, particularly around what data is collected, who it's shared with, and when it is destroyed or 100% anonymized. It should insist you have contracts containing terms of equal strength in place with any of your vendors, subcontractors, partners, etc. who might conceivably gain access to the sensitive data. The clause should be written such that the liability follows along to any assigns, heirs, successors, etc, and it should be excluded from any loopholes in other portions of the contract (particularly any blanket ones which allow you to change the ToS without gaining fresh, explicit consent) and preferably free from any limitations of liability. I'm glad Stripe is taking a responsive approach to the matter and I hope you'll consider this feedback when you revisit your legal agreements.
- 6y ago

lrpublic 6y ago

And how much GDPR risk? Is it not the case that sites using this would have to explicitly gain consent from visitors to capture data in advance?

lmkg 6y ago
Under GDPR, no. Fraud detection is the canonical Legitimate Interest, and the only one mentioned by name in the text of the law. PECR is a different matter. That's more restrictive but I'm not sure about the exact contours of what's considered "essential."
- lrpublic 6y ago
  I don’t think recital 47 allows carte blanche data collection in the name of fraud detection, and at the very least I would think there is an obligation for disclosure of the data collection, a mechanism to access it (DSAR) and the ability to correct inaccuracies.
  - lmkg 6y ago
    You're correct about all of these points. GDPR still means that the principles of transparency, purpose limitation, data minimization, etc. are in play, as are data subject rights like access, rectification, and erasure. I was only addressing the specific issue of consent from your previous comment. Consent wouldn't be necessary if there's a different legal basis, and fraud detection qualifies as a Legitimate Interest. Note that collecting consent still doesn't give you carte blanche to collect all the datas. The principle of data minimization still restricts you to only the data you need for the purpose you state when gathering consent.
    - lrpublic 6y ago
      For the avoidance of doubt, the main point of my comment was the not insignificant risk (a maximum fine of 20 million euro or 4% of turnover if that is greater) if a data controller does not meet the obligations of the GDPR. Consent, as you point out, is only one aspect of this.

asclepi 6y ago

Here's hoping it also reduces the exorbitant amount of false positives we've been seeing with Stripe's fraud prevention services, which cost us a lot in lost legitimate sales.

pc 6y ago
I'm sorry to hear that! Feel free to email me (patrick@stripe.com) and I'll connect you with the team if you'd like us to do a deeper dive. 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_characteristic https://en.wikipedia.org/wiki/Receiver_operating_characteris...
- gmu3 6y ago
  A user shouldn't have to email a cofounder to get in touch with a team member. The last time I integrated stripe on a site as a final test before it went live I had my cousin make a purchase and the site got flag as potential money laundering because we had the same last name. At the time literally zero customer service. It took 8 years before stripe started doing any customer support. Cool launch pages but personally I'll never use stripe again
  - ryneandal 6y ago
    It isn't the only source for getting support for a particular issue, calmate.
  - globile 6y ago
    We have the opposite problem. People with 50 carding attempts and radar scores of 30 or so. There is no value in Radar if so many of these cases pop up because you can’t really tell the truth from the false. We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases. Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.

carapace 6y ago

FWIW, reading this I thought "Isn't that for fraud detection?" and then I got to the part where your agent says "it's for fraud detection"... I'm normally against this sort of thing (even though everybody does it, it seems like) but in this case, it's clear that this really is "works as intended" at least to me, FWIW.

skoskie 6y ago
My thoughts exactly as I was reading. Analytics gathering that’s not related to UI improvements wouldn’t bother to collect information on pointer movements. But it turns out to be a pretty good tool for bot detection. That’s why you can now just check a box to verify you’re human (Something about that sentence feels quite dystopian). I just don’t see the issue with Stripe’s practice here. They have a clear business model, and selling user data could severely undermine that model.
- amenod 6y ago
  Sure, but business models change. The main issue here is that this behavior is enabled by default and hidden. If API would be used like this, I would see no problem: ``` import { ensureUsersAreTrackedForFraudPrevention, loadStripe, } from '@stripe/stripe-js'; ensureUsersAreTrackedForFraudPrevention() ``` Of course, they will never do that, because then many developers would opt-out, and they need the masses to make fraud prevention work.
  - djur 6y ago
    If the API was used like that it could be disabled trivially by someone committing fraud.
  - hjnilsson 6y ago
    Likely many developers would opt-in when business sees the 5% surcharge for extra fraud. And regardless, stripe explicitly says in their documentation that you should include stripe.js on every page of your app, so they can do tracking of pointers movements for fraud detection. This has not been hidden in any way from devs.

ta1234567890 6y ago

> 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.

pc 6y ago
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.
- michaelsitver 6y ago
  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.
  - pc 6y ago
    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 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.)
    - michaelsitver 6y ago
      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.

im3w1l 6y ago

If it's recorded and transmitted it can be intercepted by intelligence agencies.

ddevault 6y ago

Hey pc, good to see you here on HN. Things like this bother me as a Stripe customer who advocates strongly for privacy. I've asked repeatedly for options which let me have more control over what exactly is happening on my page - or to have a JavaScript-free flow on Stripe.com that I can redirect users to in order to complete their card details. Another easy option would be to use subresource integrity so that I can audit each release of Stripe.js, but your team has turned this down, too. Of course, I could go full PCI, but PCI compliance is a big burden for small businesses. Do you have any plans for making Stripe more accomodating of users with privacy concerns?

pc 6y ago
Hi ddevault -- we would like to do this, and I'm very supportive in principle (and, per GP, we are perfectly fine with anyone not using Stripe.js), but our current product/engineering focus is on trying to build better tools for the businesses who are losing tens or hundreds of thousands of dollars to fraud. We think we have to first help the businesses who need help immediately. We'll probably then circle back to build products that explore more points on the [efficacy of fraud prevention] - [PCI burden] continuum.
- ddevault 6y ago
  Thanks for the info, pc! I'm worried that this is a dismissive answer, though. Stripe has been in business for 10 years, and fraud has been and will continue to be a constant battle for you. When can I expect to start seeing other problems like this prioritized?
  - pc 6y ago
    Definitely no dismissiveness intended -- apologies. While Stripe has been in business for 10 years, Radar (our fraud prevention tool) has only existed for 3.5. We've made a good deal of progress in that time and I would guess that it's 1-2 years away from being sufficiently complete that we can start to seriously focus on things other than fraud. (As it happens, I just had a conversation about this with the guy who leads it.)

meowface 6y ago

In my opinion, there's no moral issue with doing this. Fighting fraud and other kinds of cybercrime is an endless cat-and-mouse game. Although there are very bad associations with it, one simply does need to use fingerprinting and supercookies/"zombie cookies"/"evercookies" if they want even a fighting chance. I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though.

mtlynch 6y ago
> I think if it's being solely used for such security purposes, isn't shared with or sold to anyone else, and is carefully safeguarded, then it's okay. The main risk I see from it is mission creep leading to it eventually being used for other purposes, like advertising or tracking for "market research" reasons. I don't personally think it's likely Stripe would do this, though. Is this view conditional on the type of data Stripe is currently collecting or would it apply to any data Stripe collects? Would this be true if Stripe began recording every keystroke in the app and hooked every XHR request to my backend server and sent copies to Stripe? I agree that Stripe has a sensible reason for using this data. If I started seeing a high rate of chargebacks, I'd consider enabling Stripe on more parts of my site so that Stripe could consume user behavior earlier on to detect fraud. My issue is that if there's no agreement about what data Stripe is allowed to collect and what their retention policies are, then the implicit agreement is that Stripe can just collect anything it has access to and hold it forever. As JavaScript running on my page, Stripe.js has access to basically all user data in my app. There are certain types of user data I would not be comfortable sharing with Stripe, even if it improved fraud detection, so I'd like there to be clear limits on what they're gathering.
- meowface 6y ago
  Yes, I would say it's conditional. They should be more explicit about what data they're collecting from users. Opaque enough to not reveal all of the exact techniques, but clear enough so site owners can make an informed decision. (Someone dedicated and experienced enough could probably reverse engineer Stripe.js and figure out everything it's doing if they really wanted, but they're also probably updating it regularly.)

seanwilson 6y ago

> 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?

pc 6y ago
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-testing-by-fraudsters-is-up-200-percent-this-year/#235f6fbc19e4 https://www.forbes.com/sites/tomgroenfeldt/2017/05/02/card-t....
- seanwilson 6y ago
  > Credit card testing, a tactic used by fraudsters to test stolen credit card numbers with small incremental purchases before making large-dollar purchases on the card Testing for what? That the card hasn't been cancelled or has zero money on it? Can they test for how much money is on the card or anything else useful? And they need bots because they might have say 1000s of cards from a database hack and most of the cards won't be useful? What kind of large dollar purchases would someone try to make once a card has been confirmed? Why not let bots attempt lots of large dollar purchases?
  - kayfox 6y ago
    They test the cards so that they can sell the card list and promote such a sale with assertions about how much of it is good (100% tested, etc). These brokers don't want to get involved in any significant fraudulent charges for various reasons.
    - seanwilson 6y ago
      Once you have a stolen card though, what large purchases could you realistically get away with that won't leave an audit trail right back to you?

kristianc 6y ago

Having worked at an ML fraud prevention company, can confirm that this is a pretty standard part of a fraud prevention stack. It's essentially used to block credential stuffing. There's a high probability your bank also does this.

XelNika 6y ago
There's a difference between doing collecting data on your own site and doing it on third-party sites so banks are a bad example (unless your banks work differently than mine).
- kristianc 6y ago
  Banks only don’t do it on third party sites as they very rarely have third party endpoints. If they did, they would do it there too. If you want an example of another payment processor that does this - Authorize, PayPal, WorldPay will all do this too.

threepio 6y ago

Stripe customer here. The question raised is, more broadly, "Is Stripe collecting this data in a legal and ethical way?" This too can be readily answered in the negative. It doesn't matter whether "Stripe.js collects this data only for fraud prevention" or if it works in practice. Under CalOPPA [1], Stripe still has to disclose the collection of the data, and (among other things) allow customers to opt out of collection of this data, and allow customers to inspect the data collected. Stripe's privacy policy refers to opt-out and inspection rights about certain data, but AFAICT not this. [This is not legal advice] [1] http://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?lawCode=BPC&division=8.&title=&part=&chapter=22.&article= http://leginfo.legislature.ca.gov/faces/codes_displayText.xh... [2] https://stripe.com/privacy#your-rights-and-choices https://stripe.com/privacy#your-rights-and-choices

pc 6y ago
https://stripe.com/privacy https://stripe.com/privacy describes what we do in some detail (including disclosing that we use this kind of browsing data). 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.)
- jonny_eh 6y ago
  Why not address it here publicly? I don't think you want/expect everyone observing this discussion on HN to reach out to you.
  - deleted 6y ago
    [deleted]
  - pc 6y ago
    Oh, offer was made in case GP wants to have a deeper discussion/back-and-forth than is readily achievable with an online forum. Timing constraints notwithstanding, we work hard to answer questions on HN too.

lixtra 6y ago

>> Stripe records the full URL, including query parameters and URL fragments (e.g., /account?id=12345#name=michael), which some websites use to store sensitive information. Can you comment on this part as well? If you collect sensitive data unbeknownst to website owners and users you are most likely in for some trouble (i.e. gdpr)

jbverschoor 6y ago

Put your money where your mouth is, and put in the terms that this data will ever be sold/rented to advertisers. If it is, pay a penalty of $25 per datapoint. Also, if not advertisers, who will get this information? Make it any “third party”.

jbverschoor 6y ago
Woohoo bury mob

e_commerce 6y ago

Please reduce fees. Stop collecting fees on refunds.

rglover 6y ago

This goes without saying but I love it when Patrick jumps in to respond to stuff like this on here (and always thoughtfully, too).

mwcampbell 6y ago

> (CAPTCHAs use similar techniques but result in more UI friction.) Not only are they inconvenient, but they're often inaccessible for some users. So I just wanted to say thanks for not going that way, even if the cost we must pay is some theoretical compromise in privacy. Edit: On thinking about this some more, it occurred to me that by using a user's activities on a web page to determine whether they're a bot committing fraud, you might be inadvertently penalizing users that use assistive technologies, such as a screen reader, voice input, eye-tracking, etc. I haven't had a problem with this when doing a Stripe checkout with a screen reader, but I just wonder if this possible pitfall is something that your team has kept in mind.

abiogenesis 6y ago
If they are really in full compliance with the relevant California (and other) statutes as the co-founder claimed they must have also taken the accessibility aspect into account.

3xblah 6y ago

"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." The language of the revised ToS could go something like "Stripe shall only use the data for fraud prevention. Stripe shall not permit the data to be used for any other purpose, inlcuding, without limitation, any use that aims to increase customer acquisition or sales of products or services." The problem with statements like "We only use the data for X" is that this is not a limitation. It is perhaps a representation of what Stripe is doing as of the date of the ToS, however it does not mean Stripe does not have permission to use the data for any other purpose. Further, it only applies to Stripe. Another party could be using the data for some other purpose besides fraud prevention and the statement would still be true. Nothing requires that there be a sale or "rental" for another party to make use of the data. The problem with statements like "We will never sell/rent/etc. the data to Y" is that it does not prevent Stripe from using the data to help Stripe or other parties to sell products and services. Stripe does not need to sell or rent the data to provide that assistance. To recap, a ToS should limit how the data can be used. Stating how a company currently uses the data is not a limitation. Stating that a company will not sell or rent the data does not necessarily limit how the data can be used by that company or anyone else. Facebook does not sell or rent data but their collection of data ultimately results in more advertising on the web, and on Facebook-owned websites. How does that happen. The first problem is the collection of data above and beyond what is needed to fulfill a user's request, i.e., the purpose for which it was collected. Ideally we could stop the unnecessary collection of user data, e.g., through law and regulation, and this would reduce the amount of data we need to worry about. The second problem is that after users "agree" to the collection of data, there are no contractual obligations on the collector over how the data can be used, other than not sharing it.

dmit 6y ago

> The question raised ("Is Stripe collecting this data for advertising?") can be readily answered in the negative. Are Stripe co-founders paid by the word, or did that message get through about two dozen lawyers before being posted?

mhdhn 6y ago

It could be disclosed with a court order though, right?

woodandsteel 6y ago

>This data has never been, would never be, and will never be sold/rented/etc. to advertisers. Is there a reliable, independent way your customers can verify this statement is true? Or is it perhaps your position that there is no legitimate reason for people to want this? And let me add that "Nobody else does this" is not a suitable answer.

andrewstuart 6y ago

You're expecting people to trust Stripe. The problem is that there's not much reason left to trust tech companies by default.

jonplackett 6y ago

It's nice when you go into the comments expecting the worst, that Stripe are now one of the bad guys after all, only to find a perfectly reasonable explanation and a clarification from someone talking plain english. Nice.

samstave 6y ago

Can you please go into more detail about the exact method that “sophisticated fraud rings” use to attack? Like what specifically do they do, please ELI5

cosmotic 6y ago

Updating the TOS on the Stripe site doesn't really apply when the site executing the script is the site that consumes the API. The user of the consumer site never sees the Stripe TOS.

neop1x 6y ago

It's like installing anti-cheating rootkit to windows kernel. It's like recording your voice, taking retina scan, requiring you to take off your clothes and bugging a GPS device on you before swiping a card in a physical shop. How can it be possibly OK? For fraud prevention? Yes, if every customer were under 24/7 surveilence, there wouldn't be frauds (nor terrorists). Unless they were too smart to hack all the devices and fake the data. It is very wrong and there is no way it can be justified to monitor all URLs and mouse movements before the payment. Having javascript available doesn't mean you are allowed use it for spying on customers! Black Mirror in real life. It will get worse if people accept this and agree with this. Quite sad. :(

bobblywobbles 6y ago

Thanks for posting this explanation and making an effort to update your terms of service to call out this behavior. We appreciate that you are intent on fixing this, it helps us know that there are honest people working at Stripe and helps clear the fog that what seem to be a lot of us believing you are doing malicious things. I hope you and your family stay healthy during this pandemic.

EastSmith 6y ago

> 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 So, in order of Stripe to make more money (1.5% less fraud), you chose to track everybody. Probably me too. Thanks for that.

softwarejosh 6y ago

i worked for a company that made tools like this for diagnosing ui flow issues with machine learning, its possible and likely some companies use this for tracking their users, but it has some meritable uses as well.

rmrfrmrf 6y ago

> This data has never been, would never be, and will never be sold/rented/etc. to advertisers. I don't think first-order data access is really the problem here, but rather where that data is going in general and who is authorized to access it, for how long, etc., and the volume of data any one person has access to at one time.

SquishyPanda23 6y ago

> This data has never been, would never be, and will never be sold/rented/etc. to advertisers. This is kind of a straw man. These valuable data sets are typically kept by tech companies to keep a competitive edge. For example, not even Google sells or rents user data. The more relevant question is "is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?" My guess is that the answer to this is likely yes. Fraud prevention is the current product built on this data. But it would be shocking if the company never put the data set to additional uses.

pc 6y ago
> Is Stripe's valuation significantly predicated on revenue it can extract from the surveillance data it's collecting?" 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!
- SquishyPanda23 6y ago
  Okay thanks for the prompt response!
  - pc 6y ago
    Hey, that's not how arguments on the internet are supposed to go :-).
    - fb03 6y ago
      ^ What an insanely good interaction, right here.
    - SquishyPanda23 6y ago
      Haha :) I'll take this moment to say I appreciate how active you've been on HN responding to questions every time a Stripe article pops up. I realize this can't be very fun for you to have this as the top result for the last however many hours.

techntoke 6y ago

I recently was denied a credit application because I used Linux when I filed out the application. Not only that, but they still ran my credit. They even told me on the phone the reason they denied my application because I was using a suspicious browser (Chromium). Let's be honest here. Stripe.js may be about fraud prevention, but what that means is that you'll use every method available to gather data about that individual to build an identity. Then in 3 years when someone changes positions, that system will end up getting compromised, sold to the highest bidder, shared with some government agency, or used for nefarious purposes. This will be tied to all their IP, OS information, transactions, etc. Just like they are using facial recognition at several retail stores. They make you use a chip reader now for credit/debit transactions, but it has no use online. I'd rather see an open-source universal effort towards decentralized currency, voting, identity, etc.

djsumdog 6y ago
I'm running into more and more things that claim they don't support Firefox on Linux. We're headed to browser monoculture

juped 6y ago

There's many instances when someone from $company shows up in one of these threads on "$company is doing something nefarious" to do damage control... and I think this is the first one that doesn't reflect poorly on the $company in question. The reason for this is that Stripe did do something wrong, and it wasn't in the script - it was in the disclosures and communication surrounding the script. So rather than PR spin, this is actually addressing the real problem. To all other companies (and Stripe on some other day), this one thread is the exception that proves the rule that damage control in internet comments is a bad look.

masterfooo 6y ago

You got caught, spin it as much as you want. This has nothing to do with fraud. We know you got caught because of the speed of your response. This is called damage control, there is also a more scientific name for it called plausible deniability. I am disgusted with this form of surveillance. I will make sure that I won`t use Stripe in the future and force vendors to use something else.

yashap 6y ago

This seems like a pretty good reason to phone home with this data, but ... sending back urls WITH query params? It’s pretty common for sensitive data to be in query params, sometimes even things like bearer tokens. I can’t see how query params would be very useful for fraud detection, and sensitive data like this is something you really want to avoid collecting, IMO that’s low hanging fruit to remove.

unreal37 6y ago
That's just bad application design to have sensitive info in the URL.

xyst 6y ago

Since when do billionaire CEOs respond to these types of posts?

pulse7 6y ago

How can you say "...will never be sold/rented/etc. to advertisers"? Are you the fortune teller or a prophet? In case of a new CEO or changed ownership everything can change...

volgar1x 6y ago
Does that kind of data even have value for advertisers ? Beside the user tracking cookie I personally think the rest is fine if Stripe cannot tell some kind of buyer pattern (and sell it).

amelius 6y ago

Be careful with that. We have seen recently (see social distancing apps) that even public health does not justify invasion of privacy, so why should online fraud?

toasted_flakes 6y ago

This isn't Stripe's fault here, but if to make a payment online you need to track everyone just to make sure the transaction isn't fraud, then the system is broken. Why can't online payments use a use two-factor authentication by default?

unreal37 6y ago
Because, "business". That is, sales will drop for anyone who does this. That's friction that will reduce sales, and online sellers will move to a provider that does not do this. Stripe would go out of business if it made it more difficult to buy things.

philip1209 6y ago

It seems like sending users to the new Stripe-hosted Checkout would probably be better for everybody, too.

Frost1x 6y ago

>This data has never been, would never be, and will never be sold/rented/etc. to advertisers. I chortled a bit. Everything beyond has is questionable, though I believe there is sincerity about past actions and maybe even ethical business considerations. If location data can be used for supplemental revenue in a fashion that won't hurt revenue more than help revenue, it will, it's only a question of when. It may or may not be advertising, but it absolutely will be used for all sorts of functions beyond fraud detection (if it's not already), especially once Stripe is publicly traded and/or gobbled up by some other massive business.

cookiengineer 6y ago

Don't get me wrong, but a lot of CTOs said so in the past...including the one responsible for the infamous google PREF cookie that helped the NSA spy on literally the whole planet due to how google safe browing service has to be implemented. As long as there's no control, your statement is worth nothing. Even if you are acting morally correct with the data, your future replacement might not. PayPal were the good guys, too, until they were not. In my opinion these tracking mechanisms are not GDPR compliant, as there's no opt-out possibility.