cee2025
Forum Replies Created
-
@serafinnyc
Additionally, the issue still persist even after adding the above CSP rule..
Here are the console logs after submitting the checkout form:js.stripe.com/v3/three-ds-2-fingerprint-...:1 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
js.stripe.com/v3/three-ds-2-fingerprint-...:1 [Report Only] Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
td-perfs_7.3.2.js:13 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
start @ td-perfs_7.3.2.js:13
(anonymous) @ td-perfs_7.3.2.js:7
start @ td-perfs_7.3.2.js:6
(anonymous) @ td-perfs_7.3.2.js:7
y @ td-perfs_7.3.2.js:35
r @ td-perfs_7.3.2.js:34
window.onload @ Ba01d001.js:4
td-perfs_7.3.2.js:13 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
start @ td-perfs_7.3.2.js:13
(anonymous) @ td-perfs_7.3.2.js:7
start @ td-perfs_7.3.2.js:6
(anonymous) @ td-perfs_7.3.2.js:7
y @ td-perfs_7.3.2.js:35
r @ td-perfs_7.3.2.js:34
window.onload @ Ba01d001.js:4Hi @serafinnyc
I am currently using Wordfence, but I have already turned it off after noticing that whitelisting some of Stripe’s domains allowed previously failing 3DS cards to display correctly. However, using the same card with higher amounts still causes it to fail.
I believe I can modify the CSP settings from my end. However, when I add a rule like this:
<IfModule mod_headers.c>
Header append Content-Security-Policy "style-src 'self' 'unsafe-inline' https://js.stripe.com;"
</IfModule>it ends up affecting other scripts that are also running on my page, such as:
-https://fonts.googleapis.com
-https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0/css/all.min.cssI’m wondering if this is the correct way to set the rules because, if I do it like this, it seems like I would need to manually add every single script source that is being used on my page. Is that how it’s supposed to work? Do you happen to have any sample code for this kind of setup?
We are based outside of the EU, but since our products are high-value, we want to ensure that payments are as secure as possible.
Hi @serafinnyc
I understand now that fixing the CSP might resolve the issue. However, how do I actually implement the suggestions you provided?
How can I allow CSP for Stripe without affecting other external scripts running on my page?
For now, we prefer not to disclose the logs publicly.. Would it be enough if I provide the console log (below) instead?
jquery-migrate.min.js?ver=3.4.1:2 JQMIGRATE: Migrate is installed, version 3.4.1
js.stripe.com/v3/three-ds-2-fingerprint-.....html#intentId= .... :1 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
js.stripe.com/v3/three-ds-2-fingerprint-.....html#intentId=...:1 [Report Only] Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
td-perfs_7.3.2.js:13 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
start @ td-perfs_7.3.2.js:13
(anonymous) @ td-perfs_7.3.2.js:7
start @ td-perfs_7.3.2.js:6
(anonymous) @ td-perfs_7.3.2.js:7
y @ td-perfs_7.3.2.js:35
r @ td-perfs_7.3.2.js:34
window.onload @ Ba01d001.js:4
td-perfs_7.3.2.js:13 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
start @ td-perfs_7.3.2.js:13
(anonymous) @ td-perfs_7.3.2.js:7
start @ td-perfs_7.3.2.js:6- This reply was modified 12 months ago by cee2025.
Hi @mosesmedh
Sure, but how can i send the WooCommerce System Status Report to you in private?
The 3DS flow inconsistency is not limited to one specific card—it happens across multiple cards, even from the same bank.
We have observed that some cards successfully trigger the 3DS challenge as expected. While other cards (sometimes even from the same bank) fail to display the 3DS popup, resulting in an error. Additionally, for some cards that work at lower transaction amounts, the 3DS challenge fails to display when attempting a higher amount.
We have verified this using real credit cards, not just test cards, and the behavior seems unpredictable.
We also checked WooCommerce logs and confirmed that Stripe is returning the three_ds_method_url and other parameters correctly, but the modal does not always render.
I have also mentioned in my previous reply that we are constantly getting a CSP error. I’ve included the console log. Could these be contributing to the inconsistencies we’re experiencing? If so, what would be the recommended approach to resolve them?
Hi @lovingbro
- I was able to locate the setting for the New Checkout Experience, as referenced in this link https://woocommerce.com/document/stripe/admin-experience/new-checkout-experience/#enabling
The setting is unchecked by default upon installation.
I have tested both states (checked and unchecked) during transactions, and the issue persisted in both cases. - and 3. Yes, here are the errors that are consistently appearing:
These CSP errors are also present during successful 3DS popups. Could these be contributing to the inconsistencies we’re experiencing? If so, what would be the recommended approach to resolve them?
jquery-migrate.min.js?ver=3.4.1:2 JQMIGRATE: Migrate is installed, version 3.4.1
js.stripe.com/v3/three-ds-2-fingerprint-.....html#intentId= .... :1 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.js.stripe.com/v3/three-ds-2-fingerprint-.....html#intentId=...:1 [Report Only] Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.td-perfs_7.3.2.js:13 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.start @ td-perfs_7.3.2.js:13
(anonymous) @ td-perfs_7.3.2.js:7
start @ td-perfs_7.3.2.js:6
(anonymous) @ td-perfs_7.3.2.js:7
y @ td-perfs_7.3.2.js:35
r @ td-perfs_7.3.2.js:34
window.onload @ Ba01d001.js:4
td-perfs_7.3.2.js:13 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
start @ td-perfs_7.3.2.js:13
(anonymous) @ td-perfs_7.3.2.js:7
start @ td-perfs_7.3.2.js:6
(anonymous) @ td-perfs_7.3.2.js:7
y @ td-perfs_7.3.2.js:35
r @ td-perfs_7.3.2.js:34
window.onload @ Ba01d001.js:4- I tested using the Twenty Twenty-Five theme, but the issue still persisted during checkout.
- This reply was modified 1 year ago by cee2025.
Hi @serafinnyc
We are currently using WooCommerce 6.8.1-ja, so I’m not entirely sure if the setting I found is the one you are referring to.
In our version, it is located under WooCommerce → Payments → Stripe → Manage → Manage tab, at the bottom of the page. The setting name is translated as “Legacy Checkout Experience.”
By default, it was unchecked. I also tried enabling it just in case it was a mistranslation of the setting name, but unfortunately, the issue persists.
I also tested using:
-The default template with [woocommerce_checkout].
-The default checkout page that came with the WooCommerce installation.Both methods still failed to display the 3D Secure (3DS) popup, even for cards that work fine on other platforms.
Hi @mahfuzurwp
We actually tried setting up a Radar rule with the condition to request 3D Secure for all transactions. However, even with that enabled, some cards still don’t display the 3DS popup. This is why we started thinking it might be an issue on the WordPress/WooCommerce side instead.
When I checked the logs for these transactions (both successful and failed ones), I noticed that in the Webhook body under next_action, there are fields like:
-three_ds_method_url
-certificatesThese fields are populated, which suggests the request is being made. But for some reason, the popup is not displayed for certain cards. This is really weird because the same cards work fine on other sites.
Hi @mosesmedh
Does this mean that the card issuer ultimately decides whether or not to trigger 3D Secure for a transaction, even if the card itself supports and has 3DS enabled?
We actually tested with two cards from the same provider, and one triggered the 3DS popup while the other did not. This makes me wonder—is the decision made on a per-card basis, even within the same issuer?
What’s even more confusing is that the card that did not work on our site successfully triggered 3D Secure on another website. This suggests that the card can trigger 3DS, but it’s just not doing it on our platform.
Could this be related to specific settings or configurations in WooCommerce, or is it entirely controlled by the card provider?
Hi @serafinnyc,
We did try using cards from the same provider—one worked fine with the 3D Secure popup, while the other failed to trigger it. This inconsistency is quite puzzling.
Yes, we’ve already tested with Stripe’s official 3DS test cards as you suggested, and everything works as expected in test mode. The issue only happens with real credit cards, where some consistently fail to display the 3DS popup even though they should.
You mentioned the Stripe Payment Element. I couldn’t locate this option under WooCommerce → Settings → Payments → Stripe. Is it supposed to be in the Stripe settings page within WooCommerce? I only see basic configurations, but nothing specifically labeled as Payment Element.
We also tried adding the Radar rule that would require 3ds.
However, the 3DS popup still doesn’t appear for certain cards, even with this rule enforced.Hello,
I am not using any third-party plugin to customize the email templates.
Thank you very much for informing me about this setting: “Enable modern email design for transactional emails”. It was the solution.
You may close this issue.
Thank you very much again!