Why Weight and Price Range Gaps Hide Carriers at Checkout

When a shipping carrier disappears at checkout, the visible symptom is simple: the customer has fewer delivery choices. The underlying configuration can be surprisingly specific. A total or weight falls into a hole between two ranges, lands exactly on an exclusive upper boundary, or matches a range that has no delivery row for the customer's zone and shop.

Understanding the interval model makes these failures easier to predict.

A carrier range is not just two labels

PrestaShop price and weight ranges describe intervals. For auditing, read them as [from, to): include the lower value and exclude the upper value.

Consider two price ranges:

• Range A: 0 to 50
• Range B: 50 to 100

A total of 49.99 matches Range A. A total of exactly 50 does not match Range A, but it does match Range B because 50 is B's lower boundary. The ranges touch without leaving a gap.

Now change Range B to 50.01 to 100. A total of 50 is no longer covered. The missing interval may be tiny, but checkout does not care whether the hole was intentional. If no other carrier covers that total, the shipping choice disappears.

Weight ranges fail the same way

Weight ranges use the same boundary logic. Suppose a carrier has 0 to 5 kg and 5.5 to 20 kg. A parcel at 5.2 kg falls into the gap.

This can be hard to reproduce manually because product weights, quantities, and unit conversions combine into the final cart weight. A deterministic audit avoids those distractions by probing the configured weight intervals directly. It can test 5, a value inside the gap, 5.5, and the final upper boundary without reading a cart or creating an order.

Overlaps are a maintenance risk

An overlap occurs when the next range begins before the previous range ends. For example, 0 to 5 and 4 to 10 both cover values from 4 up to 5.

An overlap may not immediately hide a carrier, but it creates ambiguity. Which delivery price did the merchant intend? What happens when one row is edited or removed later? A configuration audit should report overlaps alongside gaps so the range plan remains unambiguous.

Delivery configuration completes the chain

Finding a matching interval is only part of the answer. The carrier also needs delivery configuration for that range, zone, and shop.

Imagine a carrier assigned to Europe with three continuous price ranges. The first and third ranges have Europe delivery rows, but the middle range does not. A total in the middle interval matches a range structurally, yet there is no delivery price for the relevant combination. To an operator, this can look like a mysterious checkout bug. In the data, it is a missing association.

This is why range analysis and zone coverage analysis should run together.

Shop and group scope can mimic a range gap

The same total may show a carrier in one shop and hide it in another. Likewise, an administrator account may see a carrier under a test context while an intended customer group cannot.

A proper diagnostic first filters carriers by the current shop, then evaluates each current-shop customer group independently. Only then should it test zone and range eligibility. Otherwise, a Visitor-only or different-shop carrier can be incorrectly counted as Customer or VIP coverage.

This structural check does not require customer records. The carrier's configured group assignments are enough to identify empty or non-overlapping scope.

Out-of-range behavior decides the edge case

When no configured range matches, a carrier can be configured to disappear or to use its largest range. In PrestaShop 9.1.4, range_behavior=true disables the carrier and range_behavior=false uses the highest range. The final upper boundary is therefore one of the most important values to test.

If the final range ends at 100, the value 100 is outside that half-open interval. With disable behavior, the carrier is hidden. With largest-range behavior, the carrier can remain eligible using the fallback range, provided the necessary delivery row exists.

The audit report should label fallback separately from an ordinary range match. “Covered by a configured interval” and “available only because of out-of-range fallback” have different operational meaning.

Use boundary-focused probes

Random totals are poor at finding narrow gaps. Build a small probe set around the configuration:

• The first lower boundary.
• A normal value inside each range.
• Each exact upper boundary.
• The next lower boundary.
• A value inside every detected gap.
• A value above the final range.

Run the same pattern for weights. Keep the number of probes bounded so the output remains easy to review and export.

Treat the result as a configuration diagnosis

A range audit is not a full checkout promise. Taxes, discounts, addresses, product restrictions, dimensions, stock rules, and third-party carrier integrations can influence the final choice. The audit answers a narrower question: does the existing carrier configuration provide a usable path for this shop, group, zone, and representative price or weight?

That narrow answer is valuable because it isolates one failure class without touching customer data or live orders.

Vamao PrestaShop Carrier Coverage OS performs this read-only diagnosis in the back office. It detects half-open boundary gaps, overlaps, missing delivery rows for individual ranges, disabled and out-of-range risks, and scope mismatches. The group-specific matrix shows free, ordinary coverage, largest-range fallback, and hidden cases as separate outcomes, making the next configuration decision much clearer.