Quote from Alex Dev on August 7, 2026, 11:50

Hello

Let me go through this properly, because I think I know what is happening, and it explains both of your reports at once.

First, the analysis.

The Stripe parameters are the important clue. Inside the plugin, the function that answers WooCommerce's question "what currency are we in" simply returns the currency currently selected. So if Stripe receives USD, then on that request the plugin genuinely believed the currency was USD. That is not Stripe misreading anything and it is not a display bug.

Now, why would the plugin believe that, while your product page and cart show the secondary currency correctly?

Because those are two different code paths, and which one runs depends on a single setting: "Is multiple allowed".

When that setting is really active, the plugin hooks into WooCommerce's actual product price functions. Prices, cart, checkout and the amount handed to the gateway all move to the selected currency, and per-product fixed prices are applied.

When that setting is not active, the plugin falls back to an older display-only conversion. The shop shows converted prices, but WooCommerce internally stays in the base currency, the order is created in the base currency, and the gateway is charged in the base currency. Fixed prices are not applied at all in this mode, because they live inside the same block of code.

Read that second paragraph again and compare it to what you described. It matches exactly: correct display, wrong amount at the gateway, fixed prices ignored, and no change no matter which storage type or cache setting you try. None of those settings can affect this, which is why you have been testing for two days without moving.

So my version is that on your site "Is multiple allowed" is not actually stored as enabled, even though the checkbox shows as enabled when you look at the settings page.

Which brings me to the second thing, and this is where I think your server comes in.

You wrote that you enabled "Payment rules" and that no additional configuration options appeared after saving. That detail is more useful than you realise. Those configuration options are rendered only when the plugin reads that option back as enabled. They did not appear, which means that setting did not save either.

Two settings that visibly do not save is not a coincidence. It is the signature of a PHP limit called max_input_vars. The FOX settings form posts one block of fields for every currency you have configured, plus all the general options. When the number of posted fields exceeds max_input_vars, PHP silently discards everything past the limit. No error, no warning, nothing in the log. The page reloads and looks saved. Whatever sat in the discarded tail of the form keeps its old value.

This is a known pattern with this plugin and it has been the answer several times before.

Here is how to confirm and fix it, in order.

1. Check the actual stored value, not the checkbox. In your database, table wp_options, look at the row where option_name is woocs_is_multiple_allowed. Also look at woocs_payments_rule_enabled. If they are 0 or missing while the settings page shows them enabled, the diagnosis is confirmed. If you prefer not to touch the database, any snippet plugin can print get_option('woocs_is_multiple_allowed') for you.
2. Raise the limit. In php.ini set max_input_vars to 5000. If you have no access to php.ini, ask your host, or add this to .htaccess on Apache: php_value max_input_vars 5000. Many hosts also expose it in the control panel.
3. Then open the FOX settings, set "Is multiple allowed" to Yes, save, and check that database value again. It must be 1.
4. While you are there, switch "Payment rules" and "Force payment via GeoIP rules" back off. They do not control the checkout currency at all, they only remove payment gateways from the list, so all they have done so far is add variables to your testing.
5. Then test a purchase again and look at the Stripe parameters. If the currency there has changed, this was it.

On the fixed price values themselves, there is one more thing to check, and it is specific to Argentine number formatting. In Argentina the dot is the thousands separator. If you typed a value like 745.920 into the fixed price field, there is a real risk it was stored as 745.92, because that field is parsed using separator settings rather than treated as a raw number. Please look at the post meta of one of the variations, at the key _woocs_regular_price_ARS, and tell me the exact value stored there. If it is a small number rather than the amount you intended, retype it with no separators at all, just the digits.

Finally, the test I would really like you to run, because it costs you nothing and settles everything I cannot see from here.

Make a clone of your site on a staging domain. Not the live shop. Then, on the clone:

Deactivate every plugin except WooCommerce and FOX. Switch the theme to a default WordPress theme such as Twenty Twenty-Four. Disable the caching plugin completely, not just clear it. Now check the fixed prices on the variations and place a test order all the way to the gateway.

If that works, switch your own theme back on and test again. Themes frequently ship their own currency integration, and that is a common source of exactly this behaviour.

If it still works, activate the remaining plugins one at a time and test after each one, starting with the payment gateways, the caching plugin, and anything that touches prices, discounts or multi-currency.

The moment the amount goes wrong again, the last thing you switched on is your answer. Nothing on the live site is at risk, and this usually finds a conflict faster than I can guess at one from the outside.

One note on timing so you are not left waiting in silence. Our support team is on vacation from August 8 to September 3, so replies in that period will be irregular and there is no urgent handling available during it. Please send the information anyway and I will pick it up as soon as I can. Steps one to four above you can do today without me, and if the max_input_vars diagnosis is correct they will fix the problem on their own.

For any private files or info use please private area of this ticket:

https://share.pluginus.net/image/i20230222134241.png
https://share.pluginus.net/image/i20230222134615.png

Kind regards