WCML: custom prices in a secondary currency resolve correctly in only one language at a time
Site: vahana.fr
Date: 21 July 2026
Plugins involved: WPML 4.9.5, WooCommerce Multilingual & Multicurrency (WCML), WooCommerce — all on latest versions
Severity: Products publicly display, and Google indexes, a price that is neither the European price nor the intended US price.
Summary
On a variable product with manually set custom prices in a secondary currency (USD), the custom price is honoured on only one of the two language versions at a time, and which one depends on whether a custom sale price is set:
Custom USD prices on the variationsFrench URL (original)English URL (translation)Regular 499, no sale price$374.17 — wrong$499 — correctRegular 499, sale 498$499 / $498 — correct$374.17 — wrong
In both cases exactly one language is wrong, and the wrong value is always the same fallback figure: the EUR ex-VAT price passed through the configured exchange rate. Adding or removing the custom sale price flips which language is broken.
We have confirmed the French failure against an uncached render (see "Cache ruled out" below), so this is not a page-cache artefact.
Environment
Base currency: EUR (default)
Secondary currency: USD
Exchange rate: manually set, 1 EUR = 1 USD
Automatic exchange rates: disabled
Show currencies based on: Client Location
"Show only products with custom prices in secondary currencies": enabled
Languages: French (default/original) / English (secondary)
Prices entered in admin: excluding VAT. FR storefront displays incl. VAT (20%).
Product type: Variable products
Currency availability: EUR for EU/EEA/UK/CH/NO + French overseas territories; USD for all other countries
All USD prices are set manually per variation, on the French (original) product. We do not rely on automatic conversion for any product — the 1 EUR = 1 USD rate exists only because a value is required. The English translation does not display a USD price field in the admin, so we understand it inherits the custom prices from the French original.
Expected behaviour
A visitor from a USD country sees the manually entered USD price, without French VAT, on both the French and English URLs.
Actual behaviour
One language shows the manual USD price; the other shows EUR ex-VAT price × exchange rate.
Worked example
Product: FlyPad® (post ID 31277, French original), variable product, 10 colour variations.
EUR price entered in admin (ex-VAT): 374.17
EUR price displayed on the FR storefront to a European visitor (incl. 20% VAT): 449.00 €
Custom USD regular price on all 10 variations: 499
Custom USD sale price: not set
Displayed to a US visitor on the French URL:
$374.17
Which is exactly:
449.00 ÷ 1.20 = 374.17 (EUR price ex-VAT)
374.17 × 1.00 = 374.17 (exchange rate applied)
The $499 custom price is discarded. On the English URL, the same product correctly shows $499.
The wrong figure appears in the visible page price, in the twitter:data1 meta tag, and in the Product structured data — i.e. it originates in the product object, not in any single output layer.
Selecting a colour variation does not change the price. All ten variations display $374.17, so this is not a parent price-range aggregation issue.
Cache ruled out
The French URL was requested from a US IP with a cache-busting query string, which bypasses WP Rocket (confirmed by the generator meta tag changing from WP Rocket to WPML ver:4.9.5 on the uncached response):
hidden link
The uncached response still contains $374.17, both as the visible price and in twitter:data1. Caches (WooCommerce transients, product lookup tables, WP Rocket, Rocket.net, Cloudflare) were also fully cleared beforehand.
Reproduction
Test A — adding a custom sale price fixes French and breaks English
Product 31277 (FlyPad®), Variations tab. "Set prices in other currencies manually" is selected on every variation. Custom USD regular price = 499, sale price empty.
Set custom USD sale price = 498 (regular left at 499).
Save changes → Update product → clear transients → purge all caches.
Load both language URLs from a US IP.
Result: French now displays $499 struck through with $498 active — correct. English now displays $374.17 — wrong. The two swapped.
Test B — removing a custom sale price breaks a working product
Product 49610 (FlyPad® Poney), which was displaying correctly at $449 (custom USD regular 479, sale 449).
Delete the custom USD sale price, leaving the custom USD regular price 479.
Save changes → Update product → clear caches.
Load the French URL from a US IP.
Result: displays 357.50 / 332.50 — the EUR ex-VAT regular and sale figures passed through the 1 EUR = 1 USD rate. The custom USD regular price of 479 is discarded. Same failure signature as FlyPad®.
Correlation across the catalogue
Before any testing, five comparable variable products were configured identically apart from the presence of a custom USD sale price. Observed on the French URLs from a US IP:
ProductPost IDUSD regularUSD saleDisplayedCorrect?FlyPad® Poney49610479449$449yesFlyPad® Mini49528459439$439yesFlyPad® Aqua33756479449$449yesFlyPad® Aqua Poney49432459419$419yesFlyPad®31277499(none)$374.17no
Every product displaying correctly on the French URL has a custom USD sale price, and in every case it is the sale price that is displayed. No product is successfully displaying a custom USD regular price on the French URL.
Variation count is not a factor: FlyPad® Aqua has 1 variation and works, FlyPad® Aqua Poney has 2 and works, FlyPad® has 10 and fails.
What we have already ruled out
Not a caching artefact. Reproduced on an uncached render with WP Rocket bypassed, after clearing all cache layers.
Not a schema/SEO plugin issue. Rank Math generates the Product schema, but the wrong price is also in the visible page price and the twitter:data1 meta tag.
Not a parent/variation aggregation issue. Selecting a colour does not correct the price.
Not a variation-count issue. Products with 1 and 2 variations work; the failing product has 10.
Not a VAT/tax configuration issue. Products with a custom USD sale price display without VAT, correctly, under the same tax settings.
Not missing data. The custom USD regular price is present on all 10 variations (_custom_variation_regular_price[USD] = 499), with _wcml_custom_prices[] = 1 (manual mode) set on each.
Impact
A public product page shows US and Canadian customers a price matching neither the European price nor the intended US price.
The wrong price is emitted in the Product structured data and indexed by Google. We currently see EUR and USD prices for the same site side by side in one set of search results.
A mismatch between the on-page price and the Merchant Center feed price risks item disapproval.
Current position
We have reverted FlyPad® to a custom USD regular price of 499 with no sale price, because the English URL matters more to us for international sales. The French URL is therefore currently serving $374.17 to US visitors. We have no configuration that makes both languages correct simultaneously.
Questions for support
Why does the custom secondary-currency price resolve correctly on only one language version at a time, and why does adding a custom sale price invert which language is affected?
Is there a known defect in how WCML resolves a custom regular price in a secondary currency when no custom sale price is set?
Is there a supported configuration in which both the original and the translated product display the same manually set USD price?
Is the exchange rate consulted at all when manual custom prices are configured, and can that fallback be disabled so that a missing custom price fails visibly rather than silently producing a converted figure?
Given that "Show only products with custom prices in secondary currencies" is enabled, why is a product whose custom price is evidently not being read still shown in the secondary currency rather than hidden?
