LovingBro (woo-hc)

Hi @foykwalla,

Thank you for the detailed breakdown of everything you have already tested. You have clearly done extensive troubleshooting here, and the comparison between the fresh installation and the existing/live installation is especially helpful in narrowing this down.

Based on your findings, this does appear less likely to be a server or SMTP issue and more likely tied to the live site’s database, rewrite structure, account endpoint configuration, or possibly a theme/template level customization affecting the password reset flow.

The malformed URL you shared: /my-account/lost-password/?show-reset-form=true&action

does stand out, as WooCommerce normally generates reset links containing both the key and login parameters. That suggests something during the reset URL generation or redirect process may be stripping or altering the expected query arguments before validation occurs.

At this stage, I would recommend checking the following areas more closely:

1. Confirm whether the active theme or a child theme contains WooCommerce template overrides, especially: woocommerce/myaccount/form-lost-password.php or related account templates.
2. Check whether any custom code snippets exist in: functions.php custom plugins, Code Snippets plugin, or MU plugins, that modify: lostpassword_url retrieve_password woocommerce_get_endpoint_url or login/account redirects.
3. Since the fresh install works correctly, exporting and comparing the following database tables/options between both installs may help identify corruption or unexpected values: wp_options especially WooCommerce account endpoint settings.
4. Re-save WooCommerce account endpoints under: WooCommerce > Settings > Advanced

Then save permalinks again under: Settings > Permalinks

5. Verify whether any caching, security, CDN, or redirect rules at the server level may be stripping query arguments from reset URLs.

You can also temporarily test using the default Storefront theme: Storefront

Additionally, please share:

1. Your System Status Report via: https://pastebin.com or https://gist.github.com
2. A screenshot or screen recording showing: ,the exact reset email link generated ,the resulting redirected URL after clicking it ,and the invalid key message

You can share screenshots via: https://snipboard.io

That should help us determine whether the reset key itself is being generated incorrectly, or whether something later in the request flow is invalidating/removing it.

Hi @samdenishin,

There is currently no default setting within the WooCommerce Stripe Payment Gateway plugin to manually restrict iDEAL | Wero to only Dutch customers.

The plugin generally relies on Stripe’s own eligibility checks to determine when payment methods should appear at checkout, based on factors like customer country, currency, and checkout eligibility.

Could you clarify if you currently have the Optimized Checkout Suite enabled under WooCommerce > Settings > Payments > Stripe > Advanced Settings?

Also, are you using the classic checkout or the Checkout Block?

You can find more details about Stripe additional payment methods here:
WooCommerce Stripe Additional Payment Methods Documentation

Since you mentioned that custom code is already successfully hiding the method for non Dutch customers, that may currently be the best workaround while we narrow down whether this behavior is expected with your current setup.

Hi @miltonbenitez,

Thank you for sharing this feature request and for the kind words about WooCommerce 😊

A native zoom on hover option for product gallery images does sound like a useful enhancement, especially for stores that rely heavily on detailed product visuals. While I cannot confirm any current plans for this feature in upcoming WooCommerce releases, I agree it would be a valuable addition to the core product gallery experience.

For now, this functionality is usually achieved through themes or dedicated gallery/zoom extensions. If you’d like to submit this as an official feature request for the WooCommerce team to review further, you can do so here: https://woocommerce.com/feature-requests/

We appreciate you taking the time to suggest this.

Hi @avagp,

Thanks for sharing the screenshots and the code snippet, I can see what you are trying to achieve here. The shortcode itself appears to work correctly in normal product contexts, but the issue is that WooCommerce Blocks, especially inside upsell/product query blocks, do not process PHP shortcodes in the same way classic templates do, which is why [porcentaje_dto] is being displayed as plain text instead.

At the moment, there is no native WooCommerce block for displaying the sale percentage badge dynamically inside Product Collection, Upsell, or related product blocks. Your feature suggestion definitely makes sense, especially for block based stores.

For your current setup, you may need a more block compatible approach, such as:

1. Creating a custom WooCommerce Blocks extension/block
2. Using a filter hooked into the product price output
3. Overriding the product template for the specific block layout

You can also explore extending the sale badge output using this developer documentation: WooCommerce Developer Docs

Since this leans more into custom development and block extensibility, I would also recommend sharing the feature request directly with the WooCommerce team here: WooCommerce Feature Requests

Hopefully this points you in the right direction.

Hi @pawkat,

Thank you for reporting this. I tried checking the checkout flow on the page you shared, however I could not fully test the checkout because selecting the product redirects to a login prompt before reaching the payment step.

At the moment, I’m unable to directly reproduce the iframe height issue from my end, so a screenshot or screen recording showing the cut off payment fields on mobile would be very helpful for further investigation. You can share that using https://snipboard.io or a similar service.

Could you also share your site’s System Status Report? You can find it via WooCommerce > Status > Get system report, then paste it to https://pastebin.com, https://quickforget.com, or https://gist.github.com and share the link here.

Additionally, please let us know if this started after a recent WooPayments, WooCommerce, theme, or plugin update.

Hi @mreuterlu,

Thank you for chiming in and confirming that you are seeing the same behaviour on a fresh install with version 10.6.1 as well. I can understand how concerning this is, especially when the settings are not saving as expected.

To help us keep things properly tracked and avoid mixing different site setups in the same thread, could you please open a new support topic for your case here:

When creating the new thread, please include your System Status Report and any steps you are taking before the Apple Pay or Google Pay options re-enable themselves. That will help with reproducing and investigating this further.

Hi @tomklein10,

Thank you for the update. I’m glad to hear you were able to get things resolved on your end, and I also noticed you updated the thread title to resolved.

Could you also share what the initial issue was and what solution worked for you? That could be very helpful for other merchants who may come across this thread in the future.

Whenever you run into anything else, please feel free to open a new thread and we’ll be happy to help further.

If you have a moment, we’d also really appreciate a review of WooCommerce. Your feedback can go a long way in helping other merchants make informed decisions about using the plugin:
https://wordpress.org/support/plugin/woocommerce/reviews/#new-post