#bdanforth

1 messages · Page 1 of 1 (latest)

reef juniperBOT
clear kiln
#

A few more related questions:

  • If we are just loading Stripe.js on a lead page, are we required to display a cookie consent banner on those lead page websites?
  • Once these different lead page websites that link to our checkout page add Stripe.js, how do we know that it's working? How do we know they added the script correctly for fraud protection?
    • I can see the same cookies on the lead page versus our checkout page with the same values, and I see POSTs to m.stripe.com with the same IDs as in cookie storage, so I guess that's one way to know?
warm sparrow
#

Hello đź‘‹
Sorry the server is running a bit busy so I haven't had a chance to look

#

Let me pull in a collegue

clear kiln
#

Okay thanks! No worries.

blazing walrus
#

Hi there

#

Okay so overall no, you can't unbundle the script like you want. We mostly talk about this in our docs here: https://stripe.com/docs/disputes/prevention/advanced-fraud-detection but you could load the "pure" version and turn off certain pieces of fraud protection but you don't really want to do that. There is no way to separate out the library at this time.

If we are just loading Stripe.js on a lead page, are we required to display a cookie consent banner on those lead page websites?
That likely depends on your jurisdiction and not something we can advise on as we can't provide legal advice.

Once these different lead page websites that link to our checkout page add Stripe.js, how do we know that it's working? How do we know they added the script correctly for fraud protection?
Yep the m.stripe.com requests is a good way to tell -- those are the requests to our fraud engine.

clear kiln
#

Thanks; so loading the script is sufficient for fraud protection purposes? I.e. we don't need to provide these lead page teams with Stripe API key(s).

#

I know one alternative way to load the script is with an ESM import which requires a call to loadStripe IIUC

blazing walrus
#

Yep that's correct.

clear kiln
#

I tried it locally, so I know what it currently does now, but that doesn't give me assurances for the future for example.

blazing walrus
clear kiln
#

Okay thanks for the information. Last question for you: does Stripe.js need access to the top level page's storage to work for fraud protection?

#

(I know you said the m.stripe.com requests are a good sign, so maybe that's sufficient evidence that this isn't a problem.)

blazing walrus
#

I am not aware of it needing top level storage.

#

You are just seeing warnings and no error correct?

#

What is the exact warning you see?

clear kiln
#

Yeah it's a warning in the console; sure one sec

# 
Partitioned cookie or storage access was provided to “https://js.stripe.com/v3/m-outer-93afeeb17bc37e711759584dbfc50d47.html#url=http%3A%2F%2Flocalhost%3A8080%2F&title=123done%20%2B%20Do%20Stuff&referrer=&muid=58c2847d-3d82-4b91-ab3d-3b16c9d102537160ea&sid=NA&version=6&preview=false” because it is loaded in the third-party context and dynamic state partitioning is enabled.

Partitioned cookie or storage access was provided to “https://m.stripe.network/inner.html#url=http%3A%2F%2Flocalhost%3A8080%2F&title=123done%20%2B%20Do%20Stuff&referrer=&muid=58c2847d-3d82-4b91-ab3d-3b16c9d102537160ea&sid=NA&version=6&preview=false” because it is loaded in the third-party context and dynamic state partitioning is enabled.
blazing walrus
#

Yeah pretty sure that warning isn't coming from us and not familiar with this being any issue.

#

If you are seeing successful requests to m.stripe then you should be good to go

clear kiln
#

It's definitely coming from Firefox; it's an anti-tracking feature that's enabled by default IIUC

blazing walrus
#

Yeah, I just did a quick search internally and not seeing this referenced as an issue anywhere.

#

I think you are safe to ignore.

clear kiln
#

Okay thanks a lot for answering all my questions. Trying to help out some other teams we're asking to add Stripe.js to their pages.