Platform guide
Does Smart Add-Ons multi-currency pricing actually convert with a currency switcher?
Partially, and the split matters. The currency symbol shown always follows WooCommerce's currently active currency, and percentage-based add-on pricing scales correctly because it's calculated as a percentage of the base product price — which a multi-currency plugin has typically already converted by the time it reaches this calculation. Fixed-amount add-on prices and literal numbers inside a pricing formula are raw admin-entered figures with no currency-conversion hook applied to them, so they stay in whatever currency they were entered in regardless of what the shopper is viewing.
Smart Add-Ons multi-currency pricing behavior isn’t documented as a single yes-or-no feature, because the real answer depends on which pricing type a specific add-on field uses — read directly from PriceCalculator::calculate() and calculateRulePrice(), this is the actual arithmetic for each type.
What actually adapts: the currency symbol
Every price the plugin displays is formatted with whatever WooCommerce currently reports as the active currency symbol:
public function currencySymbol(): string {
return html_entity_decode( (string) get_woocommerce_currency_symbol() );
}That call reads WooCommerce’s own live setting, so if a currency-switcher plugin has changed the active currency for this request, the symbol shown for an add-on’s price is always correct. The symbol is never the problem — the number next to it sometimes is.
Smart Add-Ons multi-currency pricing: percentage rules convert automatically
A percentage-type pricing rule computes its amount as a share of the base product price passed into the calculator:
if ( $pricing_type === 'percentage' ) {
return round( $base_price * ( $price / 100 ), 2 );
}Because $base_price is whatever the calling code resolved from the product — typically already run through WooCommerce’s own price-display pipeline, which is exactly where a multi-currency plugin applies its conversion — a 15% add-on rule correctly comes out to 15% of the converted price in whatever currency the shopper is viewing. This one is automatically correct with no special handling needed.
What doesn’t convert: fixed amounts
A fixed-type pricing rule returns exactly the number an admin typed into the field, with no arithmetic against the base price at all:
$price = (float) ( $rule['price'] ?? 0 );
// ...
return $price; // no conversion appliedIf a store’s base currency is USD and an admin set a gift-wrap add-on to a fixed 5, that 5 is what gets added to the total for every shopper, in every currency — a shopper viewing the store in EUR still gets 5 added, not a converted equivalent, while the base product price around it correctly reflects the EUR conversion. The two numbers end up mixed: one converted, one not. That’s a genuinely easy thing to miss during setup, because the storefront still looks completely normal — a price, a currency symbol, a total that adds up arithmetically. Nothing about the page signals that one component of that total didn’t go through the same conversion step as the rest.
Common questions
Does this affect single-currency stores?
No — this only becomes visible when a store actually runs multiple currencies through a currency-switcher plugin. A single-currency store never has a base-price conversion happening in the first place, so fixed and percentage pricing behave identically in practice, and Smart Add-Ons multi-currency pricing simply isn’t a relevant question until a second currency is actually in play.
Is there a workaround for fixed-price add-ons on a multi-currency store?
Percentage-based pricing is the one built-in pricing type that already handles this correctly, so switching a fixed-amount add-on to an equivalent percentage of the base price is the most direct existing option. There’s no currency-conversion hook for fixed amounts today beyond that — a store running several currencies with genuinely fixed add-on costs (a flat shipping-insurance fee, for example, rather than something proportional to the product) doesn’t have a built-in way to vary that number by currency automatically.
For how formula pricing itself avoids eval() while doing this arithmetic, see the safe formula evaluation guide, and WooCommerce’s own get_woocommerce_currency_symbol() reference (opens in new tab) for the function this plugin reads the active currency from.
Does this apply to custom-price and formula fields the same way?
A custom-price field where the shopper types their own amount is entered directly in whatever currency they’re currently viewing, so there’s nothing to convert — the number came from the live page, not a stored admin value. A formula field follows the same split Smart Add-Ons multi-currency pricing applies everywhere else: the {base} placeholder resolves to an already-converted number, while a bare literal typed directly into the formula string does not.
Comments