A shopper finds a product, adds it to the cart and enters a postal code. The store then reports that no carriers are available. That message identifies where the purchase stopped, but it does not identify the cause. The destination may genuinely be outside the service area, or product data and store rules may be filtering out a service that should be available. Before changing rates or enabling every carrier, establish which combination triggers the result.
Start with a scenario someone else can reproduce
Create a cart without customer information and record the product reference, selected variant, quantity and destination postal code. Note the time and the checkout step where the message appears. Keep a comparable case in which delivery is available. These two examples help distinguish a general outage from a specific condition. A screenshot of the warning rarely captures the difference that explains it.
Change one variable at a time. Keep the product and change the destination; then keep that destination and change the product. For products with variants, use the same variant throughout each comparison. One failed cart is not evidence that an entire city is unavailable. The product, quantity and destination must remain part of the record.
Distinguish actual coverage from a store restriction
Confirm whether the carrier serves the shipment origin and destination. If the carrier offers a quotation tool, an equivalent external quote can provide a useful comparison. Use the same parcel details, not just the same postal code. A rate on a carrier website does not automatically mean that an integration must return it: contracts, enabled services and parcel assembly may differ.
In PrestaShop, review the carrier’s delivery zones and relevant associations. Check customer-group or shop restrictions if your installation uses them. Field names depend on the version and shipping module. Follow the rule applied to the shopper rather than expanding the business’s delivery coverage as a shortcut to fixing a configuration issue.
Check the product data and the parcel being quoted
One lightweight item may fit a service that will not accept several units in the same cart. Review weight, dimensions and applicable limits. Establish whether the integration submits individual products or preassembled parcels. Do not replace real measurements with invented values merely to make a service appear: the resulting quote may not match the shipment you can actually dispatch.
For a provider-specific example, the Brazilian shipping platform Melhor Envio documents dimensions in centimetres and weight in kilograms. Its Brazilian postal code is called a CEP. These requirements do not apply automatically to other providers. Verify the units expected by your module and API, paying particular attention to conversions and the values supplied for product variants.
Look for gaps in ranges and conditions
If a carrier uses ranges, compare the cart total with the configured intervals and the out-of-range behaviour. Values close to a price or weight boundary deserve a separate check. Record what the store’s approved rules should produce. Do not invent a new rate to fill a gap without confirming that the business can honour it.
A small diagnostic matrix can include product A with a supported destination, product A with the failing destination, product B with that same destination, and product A at a higher quantity. Record the services shown in each case. This is a suggested investigation method, not a universal test suite; adapt it to the store’s catalogue and important delivery regions.
Follow an integrated quote through to its response
With technical support, establish whether the store sent a request and what the provider returned. Separate an unavailable service from rejected input, authentication failure and a temporary outage. Keep the error code and timestamp without copying tokens, credentials or full customer addresses into shared notes. The investigation needs enough evidence to trace the issue, not an unnecessary copy of customer data.
A valid provider response must also reach the storefront. If a service is present in the response but absent from checkout, inspect how the result is processed and filtered. If no request was sent, start with the condition that prevented it. Changing several settings at once removes useful evidence and makes the eventual fix harder to explain.
Fix the cause and repeat the comparison cases
Once the cause is established, make the smallest necessary change and record the before-and-after results. Repeat the failing cart and the cases that previously worked. Check the service, price and delivery estimate shown to the shopper. If the repair concerned a range, the appearance of just any carrier is not enough to confirm the expected outcome.
This check can usually stop before an order is created. Tests involving purchases, payments, shipping labels or customer notifications need an appropriate environment and authorisation. Avoid real side effects while diagnosing a live store. Equally, a test-mode integration does not by itself prove that a real shipment has been booked.
Keep a useful record for the next incident
Save the scenario reference, observation period, expected result and confirmed cause. Keep hypotheses separate from findings. “No range covered this weight” is more useful than “shipping works again”. If the cause remains unknown, record the recovery you observed and the investigation that is still outstanding rather than calling the problem permanently fixed.
Choose a few important scenarios to revisit after relevant changes and during campaigns. The aim is to notice when a combination stops offering delivery without turning each check into a real order. Coverage should reflect the catalogue and shipping areas, with known exceptions and external-provider limitations documented.
Start with a reproducible cart before making a store-wide change. If your store needs help investigating shipping calculations or module behaviour, contact AGTI at agti.eng.br. Bring an example without personal information and explain the expected result so the technical discussion can begin with a clear, testable scenario.