zlacker

>>mtlync+(OP)
Author here. Happy to answer any questions or hear feedback about this post.

>>mtlync+7
Have you tried sequestering the payment logistics to a separate domain or subdomain? If you had a pay._____.com that processed payments using Stripe.js, and that redirected back to app._____.com (which would not be using stripe.js), would tracking continue into your app pages?

EDIT: didn't expect this to be so controversial (6 downvotes!)

>>TAForO+md
That was one of the solutions I considered. I believe that would successfully limit Stripe's tracking, but it's just logistically complicated to stand up a whole second app just to serve one page and manage state between the payment app and my main app.

>>mtlync+kf
Could you simply use an iframe with a sandbox attribute? Idea being you dynamically create an iframe, fill it with content (styles, postmessage scripts, what have you), then dynamically set a semi-restrictive sandbox before loading Stripe's library. When you're done (i.e. have a payment token in the parent) just remove the iframe. This way everything Stripe related is sandboxed and the script is unloaded as soon as you're finished with it.

Good chance I'm missing something, or there's some kind of protections in place around this.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...