How to Audit PrestaShop Carrier Ranges Before Checkout Fails
A carrier can look perfectly healthy in the PrestaShop back office and still disappear for a real checkout. The name is visible, the carrier is enabled, and several ranges have prices. None of those facts proves that every intended cart value is covered. The safest way to review...
A carrier can look perfectly healthy in the PrestaShop back office and still disappear for a real checkout. The name is visible, the carrier is enabled, and several ranges have prices. None of those facts proves that every intended cart value is covered.
The safest way to review shipping is to treat it as a coverage problem. A checkout value enters a specific shop, customer group, shipping zone, and carrier range. If any link in that chain is missing, the carrier may not be eligible. A useful audit therefore checks the whole chain instead of looking at the carrier record alone.
Start with a precise scope
Choose one shop context before inspecting anything. In a multishop installation, a carrier can be enabled globally but absent from the current shop. Record the shop, enabled zones, configured customer groups, active carriers, and each carrier's price or weight calculation method.
Keep the audit free of order and customer records. Historical orders can help with a later business analysis, but they are unnecessary for proving whether the current configuration has structural gaps. Configuration tables are enough for the first pass.
Read ranges as intervals
Treat each PrestaShop range as a half-open interval: the lower boundary is included and the upper boundary is excluded. In compact notation, that is [from, to).
Suppose a price-based carrier has these ranges:
0 to 5050 to 100110 to 200
The first two ranges touch safely. A cart total of exactly 50 moves into the second range. The third range begins at 110, however, leaving totals from 100 up to but not including 110 uncovered. A visual review can miss that ten-unit hole because the rows still appear ordered.
Overlaps deserve equal attention. Ranges 0 to 5 and 4 to 10 both claim values from 4 up to 5. Even when PrestaShop resolves the selection consistently, the configuration is ambiguous for operators and fragile during later edits.
Verify delivery rows, not only range rows
A range definition does not guarantee that a price exists for every intended zone and shop. For each carrier range, verify that the associated delivery configuration has a row for the zone and current shop scope.
This is a common source of false confidence. The carrier has a zone assignment. The range exists. But the specific combination of carrier, range, zone, and shop has no delivery row. From the merchant's point of view, everything looks almost complete. From checkout's point of view, the combination is unusable.
Check what happens outside the configured range
PrestaShop carriers have an out-of-range behavior. In PrestaShop 9.1.4, range_behavior=true disables the carrier for an out-of-range cart, while range_behavior=false uses the highest configured range.
Neither choice is automatically wrong. The risk is failing to know which choice is active. If the carrier is disabled outside the range, test the exact maximum boundary and representative values above it. If the largest range is reused, verify that the fallback delivery row exists for every intended zone.
Also test values below the first range. A carrier that starts at 10 may be absent for a 9.99 cart even though all ordinary catalog examples happen to exceed that amount.
Use a small, deliberate probe set
You do not need thousands of random totals. A short deterministic set gives better diagnostic evidence:
- Zero and a small positive value.
- One value just below each boundary.
- The exact boundary.
- One value just above the boundary.
- The final upper boundary and a value above it.
Repeat the same pattern for weight-based carriers. The goal is not to reproduce PrestaShop's full checkout calculation. The goal is to prove that each representative value maps to an in-scope carrier range with a usable delivery row.
Review disabled and stale configuration
Disabled carriers can retain zone, group, shop, and range assignments. Those assignments do not provide live coverage. Flag them so nobody counts a paused carrier as the backup for an enabled zone.
Stale zones matter too. A carrier assigned to a disabled zone is not necessarily broken, but the assignment can mislead future maintenance. Make the difference between “configured” and “eligible now” explicit in the audit report.
Make the audit repeatable
A good report names the shop scope, interval semantics, representative probes, and every finding code. Exporting a bounded CSV can make review easier, but neutralize spreadsheet formula prefixes in any carrier or zone name before the file is opened.
Vamao PrestaShop Carrier Coverage OS automates this read-only configuration review. It reports gaps, overlaps, uncovered enabled zone/group pairs, per-range delivery-row omissions, free-carrier availability, disabled and out-of-range risks, and strict current-shop/group mismatches without creating carts or orders and without changing carrier settings.
Run the audit after carrier edits, zone changes, multishop expansion, and before a major promotion changes the totals customers are likely to reach. Shipping failures are much easier to fix in a configuration review than in a support ticket from checkout.
Discussion
Comments
Leave a comment
Comments are reviewed before they appear publicly.