Stripe.js生产环境加载异常求助：本地正常JS已下载

Hey there, let's work through this tricky issue—totally annoying when something runs smooth locally but throws errors once deployed to HTTPS production, right? Since you've confirmed Stripe.js is downloading successfully, here are the most likely culprits to check:

1. Verify Stripe Initialization Timing #

Even if the file downloads, your code might be trying to initialize Stripe before the library is fully loaded and attached to the global window object. Local environments often load resources faster, so this race condition might not show up there.

Fix this by wrapping your Stripe initialization code in a load handler for the script tag:

<script src="https://js.stripe.com/v3/" onload="initializeStripe()"></script>
<script>
function initializeStripe() {
  // Wait until Stripe is available on window
  if (window.Stripe) {
    const stripe = window.Stripe('your-publishable-api-key');
    // Proceed with your payment flow logic here
  }
}
</script>

Alternatively, use DOMContentLoaded to ensure the entire page (including external scripts) is ready before running your code.

2. Check Content Security Policy (CSP) Restrictions #

HTTPS production environments almost always enforce a Content Security Policy, which might be blocking Stripe.js from executing properly even after downloading. Stripe requires specific CSP directives to work:

• Open your browser's Security tab in DevTools and look for CSP violation errors (they’re easy to miss in the main console).
• Update your CSP configuration to include these rules:

script-src 'self' https://js.stripe.com;
connect-src 'self' https://api.stripe.com;
frame-src https://js.stripe.com https://hooks.stripe.com;
style-src 'self' 'unsafe-inline' https://js.stripe.com;

The unsafe-inline for styles is needed temporarily if you’re using Stripe’s pre-built UI components (like Elements), though Stripe recommends using nonce-based CSP for better security long-term.

3. Resolve Webpack/Bundler Conflicts #

Your error stack mentions webpackJsonp, so your project is using Webpack. It’s possible the bundler is interfering with Stripe’s global window.Stripe variable:

• Add Stripe as an external dependency in your Webpack config so it doesn’t get bundled with your code (it should use the globally loaded version instead):

module.exports = {
  // ... other Webpack settings
  externals: {
    stripe: 'Stripe'
  }
};

• Then import Stripe in your code like this:

import Stripe from 'stripe';
const stripe = Stripe('your-publishable-api-key');

This ensures Webpack references the global Stripe instance loaded from the external script, not a bundled version.

4. Rule Out CDN/Proxy Caching or Tampering #

Production CDNs or reverse proxies sometimes cache outdated versions of external scripts or modify their content accidentally:

• In DevTools’ Network tab, check the response headers for https://js.stripe.com/v3/:
  • Confirm Content-Type is application/javascript
  • Verify the file content matches the official Stripe.js (you can compare it by opening the URL directly in your browser)
• Force a cache purge for your production CDN to ensure it pulls the latest, unmodified version of Stripe.js.

If none of these steps fix the issue, share a bit more about your production setup (like which CDN you use, your full CSP rules, or how you’re triggering Stripe initialization) and we can dig deeper!

内容的提问来源于stack exchange，提问作者Benco