stripe-js: Failed to load Stripe.js

For anyone who may still be coming across this error, we were mystified by this ourselves, and witnessing it only affecting Safari and Mobile Safari users. It turns out the errors were not adversely affecting our users at all — what was happening was, we use auth0 for our identity provider, and lean on the loginWithRedirect() method from their useAuth0 React hook, and what was happening was a user was being redirected before the stripe.js asset had completed loading, which was triggering the event listener here to fire. I can easily reproduce this by selecting “Clear History…” in Safari and visiting our site, and each time I do it the error is fired.

cc @hofman-stripe, this may be of interest to you.

Why is this issue closed when there are many people experiencing the same problem? @hofman-stripe

I’m seeing a large number of these errors but all on iOS / macOS safari 13.0.5

I found a way to reproduce this problem in dev:

First, make sure you load Stripe using the pure variant, and then have a retry wrapper that will call loadStripe again if it fails:

import { loadStripe } from '@stripe/stripe-js/pure';

const stripePromise = (async () => {
  for (;;) {
    try {
      // This sleep here makes it easier to reproduce locally, we're delaying the loading of Stripe
      await new Promise((r) => setTimeout(r, 20000));

      return await loadStripe('API_KEY');
    } catch (err) {
      console.error(err);
      await new Promise((r) => setTimeout(r, 5000));
    }
  }
})();

Now to reproduce:

1. Load your webapp in your browser in dev
2. Within 20 sec, go to devtools and under network throttling, set it to “Offline”
3. Wait and observe that it logs Error: Failed to load Stripe.js
4. Now go back into devtools, and turn off throttling
5. Wait and see that it tries to call loadStripe again, but it keeps on failing with the same error every 5 seconds

This means retry doesn’t work and once you have received the error Error: Failed to load Stripe.js, the only thing that helps is to reload the whole page:

const stripePromise = (async () => {
  try {
    return await loadStripe('API_KEY');
  } catch (err) {
    console.error(err);
    window.location.reload();
  }
})();

I see this happening a lot in the wild in production environments, so it’s not just in dev.

I definitely think this is a bug in Stripe.js and should be fixed, as I think it will lead to horrible UX, as it will make the Stripe Elements hang forever when the customer wants to pay…

We are seeing this issue on @stripe/stripe-js 1.5.0 and our CSP looks fine.

There is something going on weird in Sentry where it thinks the OS is usually Windows but that the device is usually an iPhone…

@esetnik If you’re seeing a consistent errors related to loading Stripe.js with this package, please open a new issue and share details such as:

• Exact code & error message(s)
• Package version you’re using
• Ideally a minimal reproduction or live example we can inspect

We are seeing this issue on @stripe/stripe-js 1.5.0 and our CSP looks fine.

FYI, we had a similar thing and the problem was solved by editing https://js.stripe.com/v3/ in our CSP - removing the /v3/, and just having the protocol and domain there fixed it. maybe the same issue, maybe not. But might be useful for someone else in the future.

We inject the script on every page for fraud detection, as mentioned in the Readme here and in the documentation.

However I realize now that the unhandled rejection will be triggered even when you don’t call loadStripe, which we’ll look into fixing.

Hey folks, I/we have been keeping an eye on this as more examples roll in. While this is currently expected behaviour (not a bug), it’s also not ideal. @mifi 's clear repro/example earlier this year prompted me to press the team to see about improving this.

As you can see in the above-linked PR, we’re working on revising this to allow for programmatic retries without getting the cached failure.

Ha yeah CSP needs to allow js.stripe.com for script-src.

Please see the Content Security Policy section of the security guide.

@hofman-stripe According to our Sentry it looks like it’s going through the error listener and not the load one.

Still seeing this error as well

Getting lots of these too.

This error is raised if the script failed to load (e.g. network error), or loaded but didn’t execute properly (didn’t register Stripe on the global).

Do you have any CSP that might interfere with loading of the Stripe.js script? Maybe those customers have extensions installed blocking some 3rd party scripts? Do you have metrics on how often this happens? Are most Firefox users able to load without errors?

Unless you can gather more details from an impacted user, I’m not sure we’d be able to track down the cause.

Still experiencing this with this tech stack:

React v18 RTK Chakra UI hosted via AWS Amplify Auth0 was our auth provider Sentry as our monitoring provider

Over 130 events of this in the last 30 days. Luckily our dashboard isn’t used to heavily, but it’s still annoying for our oncall rotation. Luckily I found this thread, so I’ll link it to our Jira ticket(s) so we can monitor the situation.

I can’t believe there’s still no fix for this, it’s the most common error we have in Sentry. Reloading entire page sounds like a UX nightmare 😬

@vincentaudebert I got the same issue. It’s because Stripe will be loaded whenever loadStripe is imported regardless loadStripe(process.env.STRIPE_KEY) is executed or not.

import { loadStripe } from '@stripe/stripe-js';

That’s why your pages still load Stripe regarless you tried to call loadStripe(process.env.STRIPE_KEY) inside useEffect.

To solve the issue, there are 2 steps

1. Defer loading Stripe.js // Stripe.js will not be loaded until `loadStripe` is called import { loadStripe } from '@stripe/stripe-js/pure';

2. Only execute loadStripe() when render needed pages

let stripePromise;
const getStripe = () => {
  if (!stripePromise) {
    stripePromise = loadStripe(process.env.REACT_APP_STRIPE_PUBLISHABLE_KEY);
  }
  return stripePromise;
};

const CheckoutPage = () => (
  <Elements stripe={getStripe()}>
    <CheckoutForm />
  </Elements>
);

Useful tutorial: https://dev.to/stripe/importing-stripe-js-as-an-es-module-1ni

Also to avoid sentry spam, I’d recommend handling the rejection of loadStripe() and maybe disable your payment forms with a message asking the user to add an exception in their ad blocker or firewall?

@vincentaudebert unfortunately an absolute number doesn’t really tell me much about the frequency of this problem compared to successful loads. However that is a fairly high number. It would be great to see if you can find a correlation between them.

I’d still recommend you keep using loadStripe(). Maybe we can tweak the error messages to differentiate between a missing Stripe global and a script load error.

It happened around 370 times to about 180 different users in 7 days.

I will try to load stripe script only when required and use window.Stripe directly instead of loadStripe() to see what happens. Will post here if it fixes the problem.

I’m suspecting extenstions too though 😕