Comment by inertial | Hacker News Reader

Comment by inertial | Hacker News Reader

Slightly OT : With Stripe elements, we noticed an error in about 5% of the requests, something like "Stripe is not defined". Some of these errors were traced to older browsers with JS issues that couldn't execute "https://js.stripe.com/v3/". But some remain unexplained. Unfortunately, it's hard to debug a client side error unless a client reports it.

Just thinking out load about possible issues that could cause this failure:

1) Extension blocking Stripe (as @Artemis2 mentioned below)

2) An older browser that's unable to execute Stripe JS (but uses a fake user agent that confuses us into thinking that a modern browser might be failing).

3) Unreliable internet client connection that is unable to load Stripe script intermittently.

Stripe elements is beautiful & flexible and the team is super helpful. We'd love to use it, but with the above problem, it's a bit scary to lose customers silently. For now, we are sticking with the Checkout flow.

We'd appreciate any tips on how to catch/fix an error like this ?

It could be because tracker-blocking plugins (I use Ghostery) have started blocking Stripe.js. This is because they are now recommending to include it on every page of your site for fraud protection, which is a use case of user tracking: https://stripe.com/docs/stripe.js#including-stripejs.

Thanks for the tip. It seems that ghostery's issue was fixed in August [1]. The latest version of ghostery does not block Stripe elements. Preventing an extension update isn't straight forward so we are left wondering if there's some other extension that's blocking Stripe.

https://twitter.com/stripe/status/899812679447187456

True, didn’t realize they had pulled the block. Would be interesting to know how the decision was made with respect to user privacy (vs. breaking sites). I don’t know which other extensions may block Stripe.js unfortunately!

I can imagine there's other similar addons that use the same list, but don't update it as frequently.

Stripe could/should offer a self-hosted version of the .js file for just this case, as a fallback to the official .js file; enabling basic payments, but with a notice that an addon is blocking the official stripe.js file and fraud protection is not enabled. Maybe even charge a slightly higher fee to the end-user? Probably not the right thing to do. Offer a fallback that survives external JS blockers.

We used to experience this exactly with stripe.js V2, our conclusion was it was some sort of connection issue and using this code to include stripe.js on both the checkout page but also our basket helped to ensure it has been loaded by the browser before it was needed. It massively reduced the instances of the error.

  <script src="https://js.stripe.com/v3/"></script>
  <script>window.Stripe || document.write('<script src="https://js.stripe.com/v3/"><\/script>')</script>
  <script>window.Stripe || document.write('<script src="https://js.stripe.com/v3/"><\/script>')</script>

That's quite interesting. Was the issue specific to any particular browser/platform/country combination ?

Stripe's server log might record/report failures in loading scripts. Perhaps someone from Stripe can chime in on the issue.

I can't remember exactly what browsers were affected but I think it was fairly broad. Certainly, mobile browsers and maybe people on a VPN but it was mostly random from memory which is why we concluded it was just a temporary connection problem.

As an aside we also saw similar errors loading jQuery from a CDN and so used similar code to load it from our own server if it wasn't loaded from the CDN first. You cant do that with Stripe though.

A client side error capture script like Sentry helps with debugging these sorts of errors. We have been using it successfully for some time now.

We are able to capture the error / stack with vanilla JS. Tried sentry too. Wondering how would it help in debugging. What we have is the error message and the user agent but unable to reproduce the same problem unless we no more about the extensions installed or if the user agent is fake.

I was wondering if it's possible for e.g. Sentry to list installed extensions, but that'd give websites another means to do fingerprinting, probably not a good idea for browser manufacturers to have implemented.

Reply on news.ycombinator.com