3D Secure Not Triggering Properly on Checkout – popup is not displayed

Resolved cee2025
(@cee2025)

1 year, 1 month ago
I am currently experiencing an issue with 3D Secure (3DS) not being triggered properly during the checkout process on my WooCommerce site.

When I attempt to complete a purchase with certain credit cards(with 3D Secure authentication enabled), the 3D Secure popup does not appear, resulting in a failed transaction with the error:

payment_intent_authentication_failure
The provided PaymentMethod has failed authentication. You can provide payment_method_data or a new PaymentMethod to attempt to fulfill this PaymentIntent again.

I have verified this behavior by testing with multiple cards:
For some cards(3D Secure authentication enabled), the 3D Secure modal shows up correctly, and the transaction completes successfully.
For other cards(also 3D Secure authentication enabled), the popup never appears, and the payment fails with requires_payment_method.

My Setup:
WooCommerce Plugins: Only WooCommerce and WooCommerce Stripe Gateway.
Theme: A custom theme, but it is simple and does not interfere with WooCommerce’s payment flow.
No other WooCommerce-related plugins are installed.
WordPress: 6.8.1, Woocommerce: 9.8.5, WooCommerce Stripe: 9.5.0

Is this a known issue with WooCommerce or the Stripe plugin?

I noticed that there are lots of similar threads created here. Is this the same problem?

Should I stop troubleshooting and wait for a fix if it’s already recognized?

Is there a workaround for ensuring the 3DS prompt always appears, even for cards that currently fail?

Are there specific bin ranges or card types where this is more common?
- This topic was modified 1 year, 1 month ago by cee2025.

Viewing 15 replies - 1 through 15 (of 23 total)

1 2 →

Stef
(@serafinnyc)

1 year, 1 month ago

Hey @cee2025

Yeah, this comes up a lot, it’s not really a Woo bug though.

Here’s what’s probably happening:
• Stripe decides when 3D Secure pops up.
• Some cards show the modal and work fine.
• Others should trigger 3DS but fail silently, usually bank-related.

What I’d try:
1. Use Stripe’s official 3DS test cards to see if your setup’s even the issue:
https://stripe.com/docs/testing#three-d-secure-authentication
2. Make sure you’ve got the Stripe “Payment Element” enabled in the Stripe settings, it handles 3DS way better.
3. If you really want to force 3DS every time, you can add a Radar rule like:
request_three_d_secure = always
(Just know some cards might fail more.)

No need to stop troubleshooting, but it’s not really something you can fully fix. Stripe and the banks kinda run the show here.

Moses M. (woo-hc)
(@mosesmedh)

1 year, 1 month ago

Hi @cee2025,

Thanks for sharing the details. What you’re seeing can happen because 3D Secure is controlled by the card issuer. Even if a card supports 3DS, it’s ultimately the issuer that decides whether to trigger the challenge or not during a transaction.

This means it’s normal for some cards to prompt for 3DS while others don’t. You can still check your Stripe logs for more insight, and feel free to test with Stripe’s 3DS test cards if needed.

You can also view some raised issues related to this here: https://github.com/woocommerce/woocommerce-gateway-stripe/issues?q=3d+secure

Let me know if you’d like help checking anything else.

Thread Starter cee2025
(@cee2025)

1 year, 1 month ago

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.

Thread Starter cee2025
(@cee2025)

1 year, 1 month ago

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?
Mahfuzur Rahman
(@mahfuzurwp)

1 year, 1 month ago
Hi @cee2025,

Thanks for the great question, 3D Secure (3DS) behavior can definitely be a bit confusing!

To clarify: yes, the card issuer ultimately decides whether or not to trigger 3D Secure, even if the card supports 3DS. This decision can vary based on risk analysis, transaction amount, and cardholder history, and it can differ between cards from the same issuer.

That said, your platform can influence this behavior. The WooCommerce Stripe plugin uses Stripe’s default logic, which dynamically requests 3DS when required or recommended based on risk. You can also choose to enforce 3DS for all payments by enabling the “Request 3D Secure” option in your Stripe dashboard’s Radar rules.

Since the same card triggered 3DS on another site, it’s likely that the other site either:
- Enforced 3DS through Stripe Radar rules, or
- Met conditions that prompted the issuer to require it.
You can learn more about this here: https://docs.stripe.com/radar/rules#request-3d-secure
Stef
(@serafinnyc)

1 year, 1 month ago

Hey @cee2025

Quick check here, can you confirm whether you’re using the legacy Card Elements or the newer Payment Element? I only ask because I reread your post and didn’t see any mention of it.

In Stripe go to settings WooCommerce > Payments > Stripe > Manage), there should be an option like “Enable new checkout experience” or something similar.

If that’s NOT checked, you’re likely still using the legacy flow, which is known to cause weird 3DS issues like this.

Would be good to rule that out before digging deeper.

Thread Starter cee2025
(@cee2025)

1 year, 1 month ago

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
-certificates

These 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.

Thread Starter cee2025
(@cee2025)

1 year, 1 month ago

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.

LovingBro (woo-hc)
(@lovingbro)

1 year, 1 month ago

Hi @cee2025,

Thanks for the detailed follow-up and for testing across different templates, checkout flows, and Radar configurations. I understand how frustrating this must be, especially when you’ve verified that the same cards trigger 3DS on other platforms but not consistently on your site.

From everything you’ve shared, it sounds like Stripe is preparing the 3DS challenge (as seen in the webhook payload with three_ds_method_url and other fields populated), but something is interfering with the actual display of the modal on your checkout page.

Since you’ve already:
• Tried the Radar rule to enforce 3DS
• Verified it’s not tied to the legacy checkout experience
• Switched between default templates and checkout pages
• Confirmed the issue only happens with real cards, not test cards

There are a few things I recommend looking into next:
1. Confirm you’re using Stripe’s Payment Element (not legacy Elements): On the WooCommerce → Settings → Payments → Stripe → Manage screen, ensure the “Enable new checkout experience” is enabled (not just unchecked). If the label appears mistranslated or unclear, you can verify this in the Stripe settings by checking for references to “Payment Element” in the Stripe dashboard logs or by cross-referencing with this doc: https://woocommerce.com/document/stripe/#customer-experience
2. Check for console or JavaScript errors during checkout: Use your browser’s Developer Tools > Console tab during the failed 3DS flow to see if any errors appear. Even a silent JS error can block modals from loading.
3. Check for content security policies (CSP) or iframe restrictions: If your theme or server adds CSP headers or limits third-party scripts or iframes, the Stripe 3DS modal might be blocked. You can use browser tools like the Network tab or Security tab in Developer Tools to check for blocked resources.
4. Temporarily test with the Storefront theme and no custom CSS or JS: Since you’re using a custom theme, testing again with the default Storefront theme (even briefly) can help confirm if something in your theme’s layout or JS is preventing the modal from rendering.

If none of these help, you might want to share a console/network log of the checkout attempt (feel free to use https://snipboard.io/ or Loom to record), and we’d be happy to take a closer look with you.
Thread Starter cee2025
(@cee2025)

1 year, 1 month ago
Hi @lovingbro
1. 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.
2. 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
```
1. I tested using the Twenty Twenty-Five theme, but the issue still persisted during checkout.
- This reply was modified 1 year, 1 month ago by cee2025.
Moses M. (woo-hc)
(@mosesmedh)

1 year, 1 month ago
Hi @cee2025,

I get that 3D Secure behavior can be quite confusing—especially when it seems unpredictable. Based on what you’ve described, here’s what’s likely happening:

Even though you’ve created a Stripe Radar rule to request 3D Secure for all transactions, it’s important to understand that the final decision to display the 3DS challenge (the popup) rests with the card issuer. A card may support 3DS, and the request might be correctly made, but the issuer can still decide to skip the challenge if the transaction appears low-risk. This is known as a “frictionless flow.”

However, if the 3DS popup doesn’t appear at all—even though fields like three_ds_method_url show up in the next_action webhook data—there might be a front-end issue at play. This could stem from the browser, your WooCommerce setup, Stripe integration, or a plugin conflict.

Since some cards do trigger the popup in your current setup, it suggests that Stripe is working as expected. This points more toward possible browser settings or site-side restrictions. For example, if you’re running browser extensions or site plugins that block scripts or modals, they could occasionally interfere with the 3DS flow. Common Reasons Why the 3DS Popup Might Not Appear:
- The card issuer chose a frictionless authentication, so no challenge was shown.
- JavaScript errors, caching plugins, or script conflicts might be preventing the popup from rendering properly.
- Since your test cards work fine, the issue might be browser-specific. Try checking the browser console for any related errors.
To help troubleshoot further, could you share a link to your site and your site’s WooCommerce System Status Report (you can paste it on pastebin.com)? This will give more insight into what might be affecting the 3DS flow.

Also is the 3DS flow not showing consistently on your site for one specific card or this issues comes and go with multiple cards?
Thread Starter cee2025
(@cee2025)

1 year, 1 month ago

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?

Stef
(@serafinnyc)

1 year, 1 month ago

Hey @cee2025

Ah, the CSP error you mentioned might be the smoking gun.

If your site has a Content Security Policy blocking certain inline scripts or external sources (like Stripe’s iframe or JS files), that could break the 3DS modal. Stripe may still return the correct parameters like three_ds_method_url, but the modal won’t render on the frontend.

What to check:
• Look in your browser console for errors like:
Refused to load because it violates the following Content Security Policy…
• If you’re using a strict CSP (via your host, server, or a security plugin), make sure you allow:
• https://.stripe.com • https://.stripe.network
• Inline scripts (or unsafe-inline if needed)
• frame-src and script-src rules that include Stripe

Why this matters: Stripe uses iframes and JavaScript to render the 3DS challenge. If your CSP blocks those, the modal won’t show even though everything looks fine in the logs.

As for your question about sending the System Status Report, you don’t need to do it privately. People post those on the forum all the time. There’s nothing sensitive in there like API keys or passwords. If you’re worried, just redact out any custom paths or domain names.

Have you dropped your CSP console error here? If you haven’t, please do and I’ll try to help you.
Thread Starter cee2025
(@cee2025)

1 year, 1 month ago
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 1 year, 1 month ago by cee2025.
Stef
(@serafinnyc)

1 year, 1 month ago
Where are you hosted @cee2025 and (sorry if I’m repeating any questions, I’m on my phone), what security plugins are you running?

I’m trying to pinpoint where your CSP is being applied. If it’s coming from your host, and it usually is, you’ll need to request a more lenient rule like:
```
style-src 'self' 'unsafe-inline' https://js.stripe.com;
```
Also just curious, are you based in the EU? I’m guessing so with how much effort you’re putting into getting 3DS working, since it’s required there now.

Viewing 15 replies - 1 through 15 (of 23 total)

1 2 →

The topic ‘3D Secure Not Triggering Properly on Checkout – popup is not displayed’ is closed to new replies.