What Is orderValue in ShippingConditions?

orderValue is a MonetaryAmount that limits a ShippingConditions rule to orders within a specified minimum and maximum cart-value range.

It can distinguish paid shipping below a threshold, free shipping above it, or special service availability within a bounded cart band. The property controls when a condition applies; it is not the product price and does not itself state the shipping charge.

A $50 free-shipping threshold requires a clearly defined eligible-cart calculation and currency. The markup should follow the same subtotal logic as checkout, including treatment of discounts, taxes, gift cards, excluded products, and shipping fees.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Model the eligible cart value.
• Set clear boundaries.
• Include the correct currency.

Use the free backlink checker to identify linked pages before changing free-shipping promises.

Primary specification: Schema.org definition for orderValue.

orderValue is accurate when its monetary range selects exactly the carts that receive the shipping condition.

orderValue belongs on ShippingConditions and expects a MonetaryAmount value that defines the cart range for that condition.

It should not be attached directly to Product, Offer, ShippingService, OfferShippingDetails, or ShippingRateSettings as a substitute for the supported condition path. ShippingService reaches it through shippingConditions.

The parent matters because orderValue joins destination, origin, weight, item count, dimensions, season, rate, and transit time in one complete match. Moving it to an unrelated entity can imply a product price rather than a shipping threshold.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Start from the shipping service.
2. Create the applicable condition.
3. Add MonetaryAmount orderValue.
4. Attach rate and destination.
5. Validate the entity graph.

Review ShippingConditions and MonetaryAmount.

Correct placement makes cart value one explicit constraint inside a complete shipping rule.

minValue and maxValue define the lower and upper monetary boundaries for which an orderValue condition applies.

A lower-only tier can express orders at or above a free-shipping threshold. A bounded tier can express a paid rate from $35 through $49.99. An upper-only tier can cover carts below a boundary, provided its exact inclusion logic matches checkout.

Document whether endpoints are included and avoid accidental gaps or overlaps between adjacent tiers. Test values immediately below, exactly at, and immediately above each threshold using the store's currency precision.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Define eligible subtotal.
• Set monetary precision.
• Document endpoint behavior.
• Test three points per boundary.

A cart tier is reliable when every boundary value maps to one and only one shipping outcome.

Model free shipping with an orderValue condition whose eligible cart range begins at the actual threshold and whose matched shippingRate is zero in the same currency and destination context.

A common two-tier policy charges a standard rate below $50 and offers free standard shipping from $50 upward. Both tiers need compatible destinations, product eligibility, and service definitions. Express delivery can remain paid even when standard shipping is free.

The threshold shown in banners, product pages, cart messages, markup, and checkout must agree. If discounts reduce the qualifying subtotal, the condition should use the post-discount value when that is what checkout applies.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Name the qualifying subtotal.
2. Create paid and free tiers.
3. Keep service levels separate.
4. Test discounts and excluded items.
5. Match visible messaging.

Free-shipping markup is truthful when the same cart qualifies at every customer-visible and machine-readable surface.

The amount counted toward orderValue should match the authoritative eligible-cart subtotal used by checkout, including explicit rules for discounts, taxes, gift cards, shipping charges, and excluded items.

Schema does not decide the merchant's commercial formula. One store may qualify on merchandise after discounts but before tax, while another excludes oversized items. The published threshold must not imply a different formula from the live cart.

Document the calculation in policy data and generate both customer messaging and structured conditions from that source. Test carts where coupons, gift cards, tax, subscriptions, bundles, and excluded products move the amount across the boundary.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Identify every cart component.
• Classify included and excluded amounts.
• Apply currency precision.
• Test threshold-crossing combinations.

orderValue remains honest when its calculation uses the same components and sequence as checkout.

Currency should identify the monetary context of every orderValue range and align with the cart, shipping rate, destination market, and checkout conversion logic.

A threshold of 50 is meaningless without knowing whether it represents USD, CAD, EUR, or another currency. Do not copy a US dollar threshold into Canadian or international conditions unless the operational policy genuinely uses that amount and currency.

If checkout converts dynamically, publish stable market-specific thresholds only when they can remain synchronized. Currency conversion rates change; markup should not freeze a temporary conversion as a permanent shipping rule.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Match cart and condition currency.
2. Separate market thresholds.
3. Avoid stale conversion snapshots.
4. Test localized checkout.

A monetary threshold is interpretable only when its currency and market context remain explicit and consistent.

Overlapping orderValue tiers should resolve through explicit, deterministic rules so one cart cannot receive contradictory rates, times, or availability outcomes.

A cart of $75 might match a broad paid tier from $0 to $100 and a free tier from $50 upward. If both share the same destination and service, the model is ambiguous unless specificity or separate service options explain the difference.

Use non-overlapping adjacent tiers for mutually exclusive outcomes, or preserve overlap only when each condition represents a distinct selectable service. Test boundary cents and combined destination, weight, product, and seasonal constraints.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• List all conditions matching one cart.
• Separate services from tiers.
• Remove unintended overlaps.
• Test complete rule intersections.

Use shippingDestination to keep geographic tiers distinct.

Order-value tiers are coherent when each cart and service resolve to one intentional outcome.

Common mistakes include omitting currency, confusing cart value with product price, reversing minValue and maxValue, leaving gaps or overlaps, using the wrong subtotal formula, and publishing stale thresholds.

Other defects include making every service free when only standard qualifies, ignoring product exclusions, copying one threshold across currencies, and treating syntax validation as proof of checkout behavior. A correct MonetaryAmount can still encode a false commercial rule.

Threshold defects often affect many product pages because one shared policy generates the markup. Repair the authoritative cart and shipping configuration, then regenerate and test the affected cohorts.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Extract every tier and service.
2. Validate currency and ordering.
3. Find gaps and overlaps.
4. Compare checkout carts.
5. Repair the authority.

orderValue defects require monetary, cart-calculation, service, geographic, and checkout validation together.