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".
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.