Should WooCommerce call the rate API for every product?

No. Fetch and cache one rate per currency pair, then reuse it. Calling the upstream provider for every product card is slower and wastes quota.

Should the converted estimate replace the WooCommerce checkout price?

Not unless the full store, tax, refund, and payment configuration intentionally uses that currency. For a simple integration, keep it as a clearly labelled reference estimate.

Guide/WooCommerce currency conversion

Currency Conversion API for WooCommerce

Fetch rates on the WordPress server, cache successful responses, and keep display estimates separate from the payment gateway total.

ERexchangerate.dev·Sep 20, 2026·8 min read

A WooCommerce currency integration should make one bounded server-side request, reuse the result, and fail back to the store currency. It should not call an upstream API once for every product card or expose a secret in browser JavaScript.

Key points

Use wp_remote_get on the server and keep the key in WordPress configuration.

Cache a successful response with a transient instead of fetching per product.

Return the original store currency when the upstream rate is unavailable.

Treat the converted display as indicative unless the payment gateway supplies the quote.

Create a cached server-side conversion helper

php · WordPress conversion helpercopy

function exr_convert_for_display($amount, $from, $to) {
    $from = strtoupper(sanitize_text_field($from));
    $to = strtoupper(sanitize_text_field($to));
    $cache_key = 'exr_' . md5($from . '_' . $to);
    $rate = get_transient($cache_key);

    if ($rate === false) {
        $url = sprintf('https://api.exchangerate.dev/v1/convert/%s/%s/1', $from, $to);
        $response = wp_remote_get($url, array(
            'timeout' => 5,
            'headers' => array('Authorization' => 'Bearer ' . EXCHANGERATE_API_KEY),
        ));
        if (is_wp_error($response) || wp_remote_retrieve_response_code($response) !== 200) {
            return null;
        }
        $body = json_decode(wp_remote_retrieve_body($response), true);
        $rate = isset($body['rate']) ? (string) $body['rate'] : null;
        if ($rate === null) return null;
        set_transient($cache_key, $rate, MINUTE_IN_SECONDS);
    }

    return (float) $amount * (float) $rate;
}

Use the result as a labelled reference display

Add the estimate beside the normal WooCommerce price instead of replacing the canonical store price. That keeps taxes, coupons, refunds, and gateway settlement attached to WooCommerce’s own money model.

php · display an estimatecopy

add_filter('woocommerce_get_price_html', function ($html, $product) {
    $estimate = exr_convert_for_display((float) $product->get_price(), 'USD', 'EUR');
    if ($estimate === null) return $html;
    return $html . '<small class="fx-estimate">Estimated ' .
        wp_kses_post(wc_price($estimate, array('currency' => 'EUR'))) . '</small>';
}, 10, 2);

Production checklist

Define EXCHANGERATE_API_KEY outside the theme and repository.
Validate the supported currency allowlist before building the upstream URL.
Cache by pair; multiply locally for catalogue display amounts.
Preserve the original store currency when the rate is unavailable.
Escape rendered output and make the “estimated” label visible.

Float is for the display example only

For booked orders, refunds, accounting, or settlement, use WooCommerce money primitives and decimal-safe arithmetic. Keep the full-precision rate beside the recorded amount.

exchangerate.dev

Practical integration guides for developers working with currency data.

Create a cached server-side conversion helper

Use the result as a labelled reference display

Production checklist

Keep reading