---
title: "Rate validation and failure behaviour"
description: "What happens when a rate source lies, breaks or disappears — and why the answer is always \"keep yesterday's number\"."
url: "https://maksut.net/price-anchor/docs/rate-safety/"
language: "en-US"
datePublished: "2026-08-02T00:35:16+00:00"
dateModified: "2026-10-10T08:40:00+00:00"
---

# Rate validation and failure behaviour

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.