MageSentinel

When shipping rates fail silently

Live shipping rates look like a feature of your store. They are really a call to a carrier’s API, made on every checkout, with your customer waiting on the answer.

All posts1 min read

A plain cardboard box

How it fails

The carrier’s API is slow, down, or rejects the request: an expired API key, a changed account number, a new required field, a product with no weight set. The checkout gets no rates back.

The customer sees “No shipping options available” or an empty list, and cannot continue. Nothing in the store logs looks like a crash. From the outside it looks like the customer just left.

Why it is only some customers

Rate failures are often partial: one country, one postcode format, one heavy product, one carrier out of three. Your own test order, to your own address, goes through perfectly.

That is what makes them slow to notice. Orders do not stop — they thin out, in a way that is easy to blame on a quiet week.

Guarding against it

Set up a flat-rate or table-rate fallback that appears when live rates fail, so a customer can always finish the order, even at a less precise price. Make sure every product has a weight.

Check the shipping step from outside with a realistic address and cart, and consider a second check to another country you sell to. An empty rates list should be an alert, not a mystery. Related: checkouts that fail in only one country and the checklist before a sale.

Check your own store now, free: the WooCommerce checkout checker or the Magento checkout test walks the checkout in a real browser and shows the step where it stops.

When totals or shipping do not refresh, see WooCommerce update_checkout not working.

Common questions

Why are no shipping methods shown at checkout?

The address matches no shipping zone, a carrier API timed out or rejected the request, or product weights and dimensions are missing.

Why does it fail only for some customers?

Zones, postcodes, weights and cart totals differ per order, so only some combinations hit the broken rule or API.

How do I guard against carrier API failures?

Keep a flat-rate fallback method, log carrier errors, and test checkout with addresses from each zone.