What Is freeShippingThreshold in ShippingRateSettings?

freeShippingThreshold is the monetary value at or above which a ShippingRateSettings rate becomes free.

Its value can be MonetaryAmount or DeliveryChargeSpecification. The threshold is inclusive: a cart exactly at the qualifying amount belongs to the free tier. The property does not define which subtotal components count or which services, destinations, or products qualify by itself.

A $50 USD threshold should match the same eligible-cart calculation used by checkout. Standard shipping may become free while express, freight, oversized products, or excluded regions remain paid.

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.

• Treat the threshold as inclusive.
• Include currency.
• Scope the qualifying service and region.

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

Primary specification: Schema.org definition for freeShippingThreshold.

freeShippingThreshold is accurate when every cart at or above the boundary receives the same qualifying zero rate at checkout.

freeShippingThreshold belongs on ShippingRateSettings and is intended to govern the rate settings matched to an OfferShippingDetails context.

It should not be attached directly to Product, Offer, ShippingConditions, or OfferShippingDetails. The settings node carries the threshold alongside destination, rate formula, label or fallback context, and exclusions.

The vocabulary's historical cross-reference pattern used shippingSettingsLink and shippingLabel, but those linking terms are now retired. Existing implementations need a measured compatibility review, and new implementations should avoid building an unverified dependency on retired terms.

• 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. Place threshold on settings.
2. Identify the Offer cohort.
3. Audit retired cross-references.
4. Validate the rendered graph.

Review ShippingRateSettings and OfferShippingDetails.

Correct placement keeps the free boundary inside a rate policy while treating retired linking terms with explicit migration caution.

Use MonetaryAmount for a direct currency threshold and DeliveryChargeSpecification when the source model genuinely needs its delivery-charge and eligible-transaction structure.

A simple free-at-$50 rule is naturally represented by a MonetaryAmount with value and currency. DeliveryChargeSpecification can carry richer pricing eligibility context, but additional complexity is useful only if it mirrors the merchant's authoritative policy.

Do not select a type because it appears more advanced. Choose the smallest model that expresses the real threshold without losing currency, eligibility, or service scope.

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.

• Start from the policy source.
• Choose direct or rich representation.
• Preserve currency and eligibility.
• Test the full threshold path.

The best threshold value type is the simplest one that reproduces the live free-shipping rule.

Above or at means the threshold is inclusive, so a qualifying subtotal exactly equal to the monetary boundary receives free shipping.

For a $50.00 rule, $49.99 remains below the boundary, $50.00 qualifies, and $50.01 remains qualified. Floating-point arithmetic, currency precision, and discount ordering can create off-by-cent errors if the implementation does not use money-safe calculations.

Test before, exactly at, and after the boundary in each supported currency. Also test equality after coupons, credits, and item exclusions are applied in the same sequence as checkout.

• 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. Use decimal money logic.
2. Document calculation order.
3. Test the exact boundary.
4. Repeat after discounts.

An inclusive threshold works when exact-boundary carts are classified consistently on every surface.

The qualifying amount should use the same eligible subtotal as checkout, with explicit rules for discounts, taxes, gift cards, credits, shipping charges, excluded items, and seller splits.

The property does not determine the subtotal formula. A merchant may qualify on merchandise after discounts but before tax, exclude oversized products, or calculate per seller. Structured data and visible cart messaging must follow the live rule.

Generate threshold messaging and markup from one policy source. Test coupons, bundles, subscriptions, digital items, gift-card purchases, returns credits, and mixed eligible and excluded products.

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 every cart component.
• Classify included items.
• Define seller and shipment scope.
• Test threshold-crossing carts.

The free boundary remains honest when its qualifying subtotal is identical to checkout's calculation.

freeShippingThreshold should zero only the qualifying shipping service, destinations, Offers, and product cohorts represented by the matched ShippingRateSettings.

Free standard shipping in the contiguous US does not imply free express, Alaska, Hawaii, international, freight, or oversized delivery. Vendor-direct and regulated products can also require separate conditions.

Build an exception matrix and make precedence deterministic. A broad free threshold must not erase a more specific paid or unavailable rule for a destination or product.

• 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. Identify qualifying service.
2. List destination exclusions.
3. List product exceptions.
4. Test broad and narrow matches.

Use shippingDestination and doesNotShip for precise geographic outcomes.

A free threshold is scoped correctly when adjacent services, regions, and products retain their intended rates.

The free threshold should override the qualifying calculated shipping charge at or above the boundary while leaving nonqualifying services and mandatory exceptions intact.

Below the threshold, a base rate, orderPercentage, or weightPercentage formula may apply. At the threshold, the qualified standard rate becomes zero. The exact override order must mirror checkout.

Do not calculate the percentage component after zeroing the rate or double-apply free logic in both ShippingConditions and ShippingRateSettings. Use one authoritative decision sequence.

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.

• Compute eligible subtotal.
• Resolve service and exceptions.
• Evaluate threshold.
• Apply zero or calculated rate.
• Compare checkout.

Compare orderPercentage, weightPercentage, and shippingRate.

Threshold and calculated rates are coherent when one documented order resolves the final shipping charge.

Common mistakes include treating the boundary as exclusive, omitting currency, using the wrong subtotal, making every service free, ignoring region and product exceptions, conflicting with calculated rates, and leaving stale promotions.

Other defects include attaching the property to the wrong parent, relying blindly on retired linking terms, mixing market currencies, using floating-point comparisons, and treating syntax validation as proof of checkout behavior.

Threshold defects commonly originate in shared promotion or rate settings. Repair the authoritative policy, regenerate markup, and preserve exception rules.

• 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 threshold and parent.
2. Validate type and currency.
3. Test boundary and exceptions.
4. Audit retired cross-references.
5. Repair the source.

Time-bound campaigns need an effective start, an effective end, and a rollback state in the same policy source. Test carts immediately before activation, during the offer, and after expiration. Membership benefits also need an authenticated cohort test because a threshold available only to members must not appear as a universal promise. Preserve a change record that identifies the approved amount, currency, markets, services, exclusions, and owner so stale thresholds can be traced and removed without weakening permanent shipping rules.

freeShippingThreshold defects require monetary, subtotal, service, region, linking, and checkout validation together.