A postal address can be real while matching no WooCommerce shipping zone or failing a carrier’s service rules. The issue may also be missing product weight, an invalid origin, an API outage or a package split that leaves one group without rates.
Do not add unrestricted free shipping as a temporary fix. It can create orders the store cannot deliver profitably.
Preserve the exact calculation inputs
Use a controlled address in the affected area and record country, state, postcode, cart products, quantities, currency and customer state. Do not retain a real customer’s full address in shared logs.
Compare with one working address while changing one field at a time. Note whether rates vanish in Cart, Checkout or only after address recalculation.
Inspect the checkout response for customer-safe error text and HTTP status.
Confirm zone selection
WooCommerce applies the first matching shipping zone. Review zone order, locations and postcode patterns, followed by the “locations not covered” fallback.
Check:
country and region codes
postcode spacing and leading zeros
wildcards/ranges
enabled method instances
zone order from specific to broad
A broad country zone placed above a postcode-specific zone can capture the address with no suitable method.
Inspect every package
Extensions can split a cart by warehouse, vendor, shipping class or product type. Checkout needs a valid rate for each package.
Remove products one at a time in a controlled test. If rates return, inspect the failing product’s virtual flag, shipping class, dimensions, weight and warehouse mapping.
Do not assume the visible cart is one shipment merely because WooCommerce shows one total.
Review method conditions
Flat rate, local pickup and free shipping have instance-specific rules. Minimum spend, coupons and shipping classes can change availability or price.
Check internal method and instance IDs. Rebuilding zones can create new IDs while custom code still references old ones.
Provide an intentional fallback message for unsupported regions rather than letting checkout fail silently.
Trace live carrier APIs
Enable the carrier extension’s protected debug logging briefly and reproduce with test data. Look for authentication, account-service, origin, packaging, rate-limit or timeout errors.
Safe carrier evidence:
provider request ID
service requested
HTTP/error code
response time
redacted destination region
Never log credentials or full customer addresses.
Check units and product data
A carrier may reject zero weight, impossible dimensions or units converted incorrectly after migration. Verify WooCommerce’s weight and dimension units match the extension’s expectations.
Large or hazardous products may need freight services not enabled on the provider account. Confirm operational requirements with the shipping team.
Avoid inventing dimensions solely to make an API return a rate; displayed prices would be unreliable.
Check whether the carrier rounds each package weight upward, because a cart close to a service limit can become ineligible after rounding.
Rule out stale cache and sessions
Cart and checkout rate calculations must not be shared page cache. Inspect Cloudflare, host and WordPress response headers.
Test in a fresh private session, but preserve the failing session for comparison. Clear only controlled shipping transients if the extension documents that action.
Currency and language changes can rebuild packages; include them if the store supports those paths.
Repair and validate fulfilment
Correct the zone, postcode pattern, method instance, product data, package rule or carrier configuration demonstrated by evidence.
Complete a controlled order for the repaired address and verify the chosen service, tax, total, payment and stored shipping line. Test an intentionally unsupported address to confirm a clear message remains.
Recurring care should check representative postcodes and carrier API health after product imports, zone changes and extension updates.