Rate validation and failure behaviour

What happens when a rate source lies, breaks or disappears — and why the answer is always "keep yesterday's number".

Updated August 2, 2026

A wrong exchange rate is a direct financial loss. The plugin’s behaviour under failure follows from one rule: a rejected rate never reaches a price.

What gets rejected

A rate is discarded, and the last known good rate kept, when it is:

  • non-finite — NaN or infinity;
  • zero or negative;
  • outside the plugin’s accepted numeric range;
  • implausible relative to the rate currently stored, beyond the configured tolerance.

Rejection is not partial. An incomplete or malformed table is not merged with the existing one; it is refused wholesale, because a half-applied table would price part of the catalogue against today’s rate and part against last week’s.

Why “last known good” is the right default

Selling for a day at yesterday’s rate is recoverable. Selling at a corrupt rate is not. If a provider returns 0.0001 instead of 1.0834, applying it would zero your catalogue in a single pass and every order placed in the meantime would be real. Refusing to move is the conservative failure, and conservative is correct here.

What you see when it happens

  • The Sync tab shows the rate table’s age and its source.
  • A stale-rate warning appears once the last successful fetch is older than the Warn when rates are older than threshold.
  • Provider failures are counted and surfaced. Repeated failures are logged through the WooCommerce logger, with credentials redacted.
  • WooCommerce → Status carries a Price Anchor diagnostics section, which is the first thing to attach to a support request.

The free plugin observes; Pro intervenes

The free plugin’s Flag rate moves larger than setting records a suspicious jump in the log and still applies it. That is a deliberate boundary: the free plugin guarantees you never get a corrupt price, and tells you when something looks odd.

Pro’s Rate Guard is the feature that holds a large one-step or cumulative movement for human approval before it reaches the catalogue. Approving applies the exact table you reviewed, not a later refetch — otherwise a merchant who approves a 12% move could silently receive a 25% one, which is the precise failure the guard exists to prevent. Approval also keeps working while the provider is down, because it re-applies a table already on disk.

Prices never fall back to zero

There is no code path in which a missing or rejected rate produces a price of zero. A product whose source currency has no available rate keeps its last written price and is reported as unconverted in the editor. That is a visible, recoverable state rather than a catalogue-wide giveaway.