vinzmendoza123

Hi,

I’m not sure what to do with the information in the API response. I get that there are two separate currencies SGD (main currency in UPS) and USD (currency used in the WooCommerce WordPress store). Additionally, when the customer’s shipping zone is in Singapore, the store currency will use SGD as the store’s currency resulting to a debug message saying “UPS Live Rates: Multi currency is supported by Flexible Shipping UPS Pro version only!”

In any case, would there be anything I can do to fix the issues without getting the PRO version of the plugin or would having a PRO version of the plugin solve all the issues we’re experiencing right now? Like the UPS shipping options not showing on the checkout page, having different currencies being used, and the debug messages saying “No rates added from…”.

As a follow up detail, is there any conflict if we’re using a different currency other than USD in the UPS account? Let’s say the UPS account uses SGD as the main currency, will that affect anything?

As I understand the theme you were using and that has the issue is Divi, right?

No, I think Divi is not the issue as my local test site is using Divi but the input fields work properly.

Also, on the test site, do you have all the plugins you also have on the live site or do you only have WooCommerce and Stripe?

Yes, the local test site has the same plugins as the live site activated but the local test site works properly.

I also tried to deactivate all plugins except WooCommerce and WooCommerce Stripe Gateway on the local test site. Sure enough it still works on the test site.

To clarify, when switching themes, were the card detail input fields showing as expected at all times, or otherwise?

Yes, no issues whatsoever when switching themes.

That sounds like an issue with how caching might be configured at the live server. Feel free to reach out to the site’s hosting provider about this, and/or the support channel of any caching/performance plugins that might be installed.

I’ll probably have to need more time to get information on this.

I wanted to give more information that I found. It seems there’s an error in the console that shows in the live website but not in the local test site. Refer to the image attached. I think it is something related to the checkout since it is referring to checkout.js and something about rocket-loader.min.js, but correct me if I’m wrong. You can visit the live website checkout page here. Though you might need to add a product to the cart to see the checkout page.

Feel free to create a local test site, from a backup, while enabling test mode for the Stripe plugin — as detailed here, in its documentation.

While testing locally, you could switch to a default theme, like TT3, and see if the issue persists without having any of the Divi functionality activated.

I did enable the test mode for Stripe on a local test site. It seems to be working properly and the fields are accessible.

I also switched themes and it works fine as well.

One thing I noticed was that in my local test site, when I load the Checkout page, it loads for a bit then after the load it goes to the normal state (See attached image for reference). The Checkout page on the live website is not doing any loading state upon visiting the page.

I’m thinking if this is the one causing the fields to not work. As I mentioned before when changing a billing address, the loading will happen and the fields can now be accessible. I’m not sure what’s causing the checkout page to not do the loading state upon visiting. Maybe there’s a way to force the loading state upon visiting the page?

Appreciate your patience and help.

Hi @anastas10s

Apologies for the late response.

To clarify, did you already have a chance to test whether the same issue persists across?classic?and?block?checkout fields, or otherwise?

I haven’t tried this one yet. Going over the links of these two, I’m confused on recreating the steps to this as I can’t find the options being mentioned. The website is using Divi as the theme. I assume this using block theme but can’t figure out how to recreate the steps mentioned.

When did this started happening? Was there a backup available at that point in time? Did you already have a chance to revert to it, and see what has changed? (theme/plugins added/updated, for example)

Unfortunately, I don’t recall when this happened exactly. The only way for me to try was to run a separate backup locally to test but the issue is the payment fields won’t show locally since I assume this requires SSL or it just won’t show locally for security reasons. I don’t think deactivating all plugins at once is an option since the website is live.

Could you please elaborate further on how exactly are the customers directed to change country?

It’s not that a customer is directed to change country but more of a workaround I found while testing. For example a customer is on the checkout page, initially the customer won’t be able to add their payment information on the respective Credit Card section fields for Stripe. But say, I update my billing address to a different one, somehow the payment details reloads and the Credit Card section fields goes back to normal and the customer can type in the fields. But I feel this is more of a hacky alternative rather than a solution.

Hi,

I am also having a similar problem where the input fields are there (see attached image) but can’t input anything or interact with the input field. I checked any console errors but no errors related with Stripe. I’m using WooCommerce Stripe Gateway and is at version 8.0.0. I tried to rollback to 7.3.2 but the problem is still there.

One solution I found was having the user change country. After that, the input fields turned back to normal and you can input again.

Is there any fix to this? I haven’t added new plugins before but it worked.

• This reply was modified 8 months, 3 weeks ago by vinzmendoza123.

Hello @dominikl65,

Yes, I set the sender email in ShopMagic settings and also the Settings -> General email but whenever I send a test email it is still using the noreply email address.

Does the test email use noreply email as sender or should the settings override it regardless whether it is a test email or not?