Shipping cost becomes 0 with Hungarian Pickup Points plugin + currency switcher
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday. If you have problems with registration ask help on contact us page pleaseIf you not got email within 24~36 business hours, firstly check your spam box, and if no any email from the support there - back to the forum and read answer here. DO NOT ANSWER ON EMAILS [noreply@pluginus.net] FROM THE FORUM!! Emails are just for your info, all answers should be published only here.
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday.
Hello,
I’m using your plugin together with:
Hungarian Pickup Points & Shipping Labels for WooCommerce
and FOX – WooCommerce Currency Switcher (PRO)
My base currency in WooCommerce is HUF.
I’ve found a critical issue:
When the pickup shipping method is selected, the shipping price becomes 0 in HUF, even though the price is correctly configured. In another currency (EUR) the same method works and shows the correct cost.
I added debug logging to WooCommerce shipping rates and confirmed:
the pickup method initially has the correct cost
after currency conversion runs, the cost becomes 0.00
checkout then displays free shipping
If I disable the currency switcher, the shipping price works correctly in HUF.
So it seems the shipping method is not fully compatible with WooCommerce currency conversion hooks, especially when HUF is the base currency.
Please investigate why the shipping rate cost is lost during conversion and how to make it compatible with multi-currency setups. This is affecting live checkout totals.
If you need debug logs or test access, I can provide it.
Thank you.
Hello,
I’ve continued debugging after my previous message and I believe I’ve identified the root cause.
The problem happens when the base/default currency is changed and a currency rate is accidentally set to 0. After switching back to HUF as the base currency, the HUF rate field becomes locked (as expected for the base currency), but internally a 0 rate state can persist and this causes the shipping conversion to return 0.00.
From that point, the pickup shipping method keeps becoming free on checkout even though the configured price is correct. There is no clear warning in the UI that a currency rate is invalid or zero, and because the base currency field is locked, it’s not possible to fix it directly from the interface.
This edge case cost me several hours to diagnose.
Please consider adding protection against currency rates being saved as 0, or at least a validation/error message if a rate becomes zero.
This would prevent shipping totals from silently breaking in live stores.
Thank you.
Hello Gabriel
I just did testing and when you set HUF (Forint) as the base currency, it correctly sets the rate to 1.
However, the real issue is different: not all currency aggregators support cross-rates when HUF is the base currency. This is a limitation of the aggregator services themselves.
Here's what you need to understand:
- You manually set the base currency in WOOCS settings
- When you change the base currency, all rates are recalculated
- There are NO intermediate conversions or old cached rates involved in the process
- The rate conversion happens directly through the aggregator
My recommendations:
- Choose one stable base currency for your store and stick with it - don't keep switching back and forth
- Monitor that other currency rates update correctly after changing the base currency
- Try different aggregators from the WOOCS settings (Yahoo, Open Exchange Rates, etc.) - some may have better HUF support than others
- If nothing helps, this is a limitation of the aggregator service itself - they simply don't provide reliable HUF cross-rates
Best solution: Keep EUR as your base currency instead of HUF. Euro is widely supported by all aggregators, and you'll avoid these cross-rate issues entirely.