Your customer is at checkout, ready to pay, and the shop tells them there is no way to ship the order. They leave. You never hear about it, and nothing in your admin records that it happened.
Most errors are annoying. This one is a sale you already paid to acquire, lost at the last step, silently. There is no order, no email and no log entry: the customer simply cannot proceed, and almost nobody writes in to tell you.
If your rates come live from a print on demand supplier, the cause is usually not the customer's address, despite what the message says.
Live rates are an HTTP call made while the customer waits. If that call times out or errors, the integration returns no rates, and WooCommerce shows exactly this message. One integration we looked at gives that call a 10 second budget, which a slow response blows through easily.
The fix that matters: add a flat rate method to the same shipping zone as a fallback. When live rates answer, they win. When they fail, the customer still sees a way to pay. Without it, every supplier hiccup is a lost sale.
Zones are matched by country, then by state or postcode. A zone that looks like it covers everywhere often does not: "Rest of the world" has to exist as its own zone, it is not implied.
How to check: WooCommerce, Settings, Shipping. Read the zones as a list of rules evaluated top to bottom, and confirm the customer's country appears in one of them.
Rate APIs need to know what is being shipped. A product with no weight, no dimensions, or with a variation that was never fully synced, produces a quote request the supplier rejects. The error that comes back is often about the product, not the address.
How to check: if it fails for one product and works for others, this is it.
If the variation in the cart does not exist at the supplier, or lost its link during a sync, the rate request has nothing to price. Shops running for years hit this after bulk edits, CSV imports or product duplication, all of which can wipe the identifiers that connect the two sides.
WooCommerce caches shipping rates per session and per cart contents. A failed lookup can be cached and then served to that customer repeatedly, long after the underlying problem is gone.
How to check: try in a private window with a fresh session. If the fresh session works, you were looking at a cached failure.
Whatever the cause turns out to be, put a flat rate in every zone that has live rates. It costs nothing when the supplier is healthy, and it is the difference between a lost checkout and a sale that ships slightly wrong. Treat live rates as an optimisation, never as your only way to be paid.
You cannot count the checkouts that failed, because they left no record. What you can count is the other half of the same problem: paid orders that never reached your supplier. Those are in your own database, and if the supplier's connection has been unreliable enough to break checkout, it has usually been unreliable enough to strand orders too.
OrderGuard is a free diagnostic plugin. It runs six checks against your own site and tells you, in plain language, which of these causes is yours. It asks for no API keys, contacts no external service, and writes nothing to your products or orders.
It also names the paid orders your supplier never collected, and adds up the money sitting in them. That one runs entirely on your own database.
Get the free pluginBecause that is WooCommerce's generic wording for "no shipping method matched this package". It is the correct message for a wrong postcode, and the same message when a live rate API failed, which is why it sends so many shop owners looking in the wrong place.
No. When live rates return, both appear and the customer chooses; you can hide the flat rate with a cost rule if you prefer. The point is that something exists when the live call fails.
The failed call is theirs. The absence of a fallback is a setting on your side, and it is the part you control. That is why the fallback is the first thing to fix, before diagnosing whose API misbehaved.