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

Hello

Thank you for the detailed write-up, that helps. Let me lay out what I think is going on, because there are several different things that can produce exactly the symptom you describe, and they need different fixes.

First, one thing I can rule out for you. Fixed prices on variations are supported and the code path for them is separate and correct: when the product is a variation, the plugin looks up the fixed price stored on that variation and returns it. So the problem is not that variations are unsupported. Something in your setup is preventing either the value from being stored the way you intended, or the plugin from knowing that ARS is the active currency at the moment the page is rendered.

Before anything else, please tell me which version of FOX you are running. That single fact rules one of the versions below in or out immediately.

Version one, and my main suspect: the page is being rendered by the server in the base currency.

You use WP Super Cache. If your Currency storage is set to Transient and the option "I am using cache plugin on my site" is enabled, the plugin identifies the visitor by a key held in the browser. That key travels with AJAX requests, but a plain page load carries nothing, so the server has no idea ARS was selected and renders the entire page in USD. The prices you see are then the untouched base prices, which is exactly why there is no currency label either, and why the amount that reached Mercado Pago was wrong: the order was created server side, in the base currency, before anything on the page had a chance to correct it.

Incognito windows do not test this. It is not browser caching, it is what the server produces.

The check takes ten seconds. Switch the currency to ARS, then open the raw page source with Ctrl+U, not the browser inspector. If the raw HTML contains the USD figures while the visible page shows something else, this is confirmed. Also tell me what your Currency storage setting is and whether that cache option is on.

Version two, specific to Argentine number formatting.

In Argentina the dot is the thousands separator. If you typed 745.920 into the fixed price field meaning seven hundred forty five thousand nine hundred twenty pesos, there is a real risk it was parsed as 745.92, because the field is parsed using the separator settings that are active at that moment. And 745.92 rounds to 746. Which is the number you saw, and which is also very close to your USD price, so it looks like the USD price was passed through untouched when in fact the fixed price was applied, just stored a thousand times too small.

The check: look at the post meta directly, on the variation IDs, not on the parent product. The key is _woocs_regular_price_ARS. If it contains 745.92, this is the cause. If it contains 745920, then version one is the answer instead. If you can read the database, this is the single most useful piece of information you can send me.

While you are there, try entering the value with no separator at all, just 745920, and save.

Version three, permissions.

Fixed prices are only written when the user saving the product has full administrator capability. If the product was saved by a Shop Manager account, the values are silently not stored, with no warning shown. The panel will still display whatever was stored before, so looking at the field is not proof that it saved. Please confirm you are saving as a full administrator.

Two settings to switch back off, by the way: "Payment rules" and "Force payment via GeoIP rules" have nothing to do with fixed prices and only add variables to the test. Please disable them again.

Now the part I would really like you to do, because it costs you nothing and it is the fastest way to a definite answer.

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

1. Deactivate every plugin except WooCommerce and FOX, and switch the theme to a default WordPress theme such as Twenty Twenty-Four. Clear every cache and disable the caching plugin entirely.
2. Open the product, check the fixed ARS price on the variations, and test the front end. Add to cart and go to checkout.
3. If it works correctly there, switch your own theme back on and test again. Themes very often carry their own currency integration, and that is a common source of this exact behaviour.
4. Then activate the remaining plugins one at a time, testing after each, starting with the ones most likely to touch prices, currency or checkout: the Mercado Pago gateway, WP Super Cache, and anything doing pricing, discounts or multi-currency work.

The moment the price goes wrong again, the last thing you switched on is your answer. Nothing is at risk, because none of this happens on the live site, and it will very likely find the conflict faster than I can guess at it from the outside.

Please send me: the FOX version, your Currency storage setting, whether the cache option is enabled, the raw value of _woocs_regular_price_ARS on one of the variations, and the result of the clone test. With those I can tell you exactly which of the three it is.

One note on timing, so you are not left waiting without knowing: our support team is on vacation from August 8 to September 3, so replies during that period will be irregular. Send the information anyway and I will get to it as soon as I can.

Kind regards