shamanua

Hello, @tahaamin

I hope you’re OK.

Is there any update on the bug? It really blocks us.

I found the way to do that.
I reused the get_european_union_countries_with_vat of Alg_WC_EU_VAT_Countries_VAT_Rates_Tool class.

Hi @tahaamin.

I thought I was pretty clear that currently plugin doesn’t work as expected. Let me try to explain it again.

When a user’s Country/Region in their profile differs from the store’s base country, but at checkout, the user selects the store’s base country as the billing country (Slovakia, in this case) and enters a valid VAT for that country, the VAT is subtracted from the order despite the “Keep VAT in selected countries” setting being configured to retain VAT in the country.

It’s an obvious bug.

• This reply was modified 4 days, 18 hours ago by shamanua.
• This reply was modified 4 days, 18 hours ago by shamanua.

Expected behavior for us is to keep VAT if user selects Slovakia as Billing country and enters valid Slovakian VAT number.

@tahaamin, the option to keep VAT if shipping country is different from billing country is not good for us.

We don’t use shipping country at all so user cannot change it. So if in profile of the user country is France and on checkout user selects Belgium and enters valid Belgium VAT, keeping the VAT is not ok.

And answering your questions:
We are using 4.3.1 version of the plugin and 4.2.3 version of Pro one.
Block Based option (Checkout block field one) is enabled in Advanced tab

Hi @tahaamin
Thank you for the response!

I found that if user’s shipping and billing country set to Slovakia, the functionality works as expected. But if user has other European country (France, for example) in shipping and billing country, VAT is subtracted even if user selects Slovakia instead of France on checkout.

Hi @mosesmedh
Currently we are putting the issue on pause as it is not a first priority right now and it’s taking way too much time to resolve.

I’m not closing the ticket as the issue is not resolved and we are going to get back to it relatively soon.

@mosesmedh, one more update.

I noticed, that in environments where the buttons are not present, there is a warning in the console:
controller-5dedb68c7eda1ca1ace3eb0bd02ae0bb.js:1 [Stripe.js] Unrecognized elements.create('payment') parameter: terms.link is not a recognized parameter. This may cause issues with your integration in the future.

What can be causes of the warning?

Hi @mosesmedh
Unfortunately, neither disabling the webhook nor disabling both the drop-in and must-use plugins worked. The buttons are still missing. The fatal logs still do not have any new records.

It is also worth mentioning that both the drop-in and must-use plugins are present on our soon-to-be-live site, where the buttons are visible.

What else can we try to fix the issue?

@mosesmedh, hello.

Here is a full list of the environments we have with the more or less the same configurations.
1. Soon-to-be live site. Here was done just a basic setup of theme, Woocommerce and plugins, including Stripe. No issues with the buttons now, but the issue was present earlier. It disappeared after switching the theme to default one and then switching back to our custom theme. Stripe is connected but webhook is disabled.

2. Dev site. It’s where we developing the site. When we finish it, it will fully replace the “Soon-to-be live site”. We never seen the express checkout buttons here. This one need to be fixed as it will be fully cloned to 1 and 1 will became live. Stripe is connected here and webhook is enabled.

3. Staging branch of dev site. We don’t use it for development. I made it by cloning the dev site and disabling all plugins only for purposes to test the minimal configuration you suggested earlier. Never seen the express checkout buttons here as well,

4. Local site. Was cloned from dev site couple of weeks ago. Buttons are present here. Stripe is not connected, webhook is disabled.

@mosesmedh, and there is nothing related to the plugin in the fatal logs. Also, the last record in the fatal logs is from a week ago. So I think it’s not relevant to the issue.

Hello @mosesmedh.

Regarding caching as a possible cause of the issue, that doesn’t seem likely.
We are experienced developers, and purging all caches is our first step in investigating any issue.
WP Rocket and Cloudflare are included by default with our Rocket.net hosting. We can disable WP Rocket, but we have no control over Cloudflare settings except for purging the cache.

Moreover, on our soon-to-be-live site, we have almost the same configuration for Stripe, the theme, WooCommerce, etc., and the buttons are present there.

Currently, we are experiencing an issue with missing buttons on our dev site, which will be fully cloned to the live site once development is complete.

To be absolutely sure that the issue persists on a site with the minimum number of installed plugins, I created a staging branch from our dev site and disabled all plugins except WooCommerce and WooCommerce Stripe Gateway. The buttons were still missing even after switching to the Twenty Twenty-Four theme. To fully follow your instructions, I additionally installed and activated the Storefront theme. Still, no buttons appeared. Cache was purged after every step and checked on multiple browsers in incognito mode.
Here is the link to our staging branch: https://vb0v5zzmr4-staging.onrocket.site/

I mentioned earlier that the Stripe settings between the instances are almost identical, and here is the only difference: on our soon-to-be-live site, the webhook is disabled, whereas on the dev site, it is enabled. That’s it.

It’s also worth mentioning that Stripe is in test mode on both environments.

Currently, we don’t have direct access to the Stripe dashboard, but we are working on deleting the webhook to confirm whether the issue is related to it.

The Woocommerce status report (staging branch of our dev site) you asked for is here:
https://pastebin.com/xQff95Wn

@moon0326 , thank you for answer.

Here is what I found.
Setting theme to “Twenty Twenty-Four” one haven’t work. Still no buttons present.

I’ve tried to do the same thing on our future live site, with the same theme but where Stripe gateway just basically connected and the buttons weren’t present either. On this site after switching to “Twenty Twenty-Four” theme the buttons finally appeared. Moreover, after switching back to our actual theme the buttons are still present.

But on dev the buttons are still absent even on default “Twenty Twenty-Four” theme.

In Stripe settings only difference between live and dev sites is that on dev Webhook is enabled and on live it is disabled. On my local instance where the buttons are working, Webhook is also disabled. I tried to fully disconnect Stripe on dev and then enable it in test mode. But after that the webhook is still enabled and buttons are still absent.

Could you please tell me where we can disable the webhook (nobody here remembers where it was set)? I want to test if this setting breaks the buttons or not.

Hello @moon0326 ,
Both “Stripe Enabled” and “Should show checkout button” have 1 status. Still no buttons on checkout.