What Is shippingRate in ShippingConditions?

shippingRate states the shipping cost for a matched destination and condition using MonetaryAmount or ShippingRateSettings.

A simple flat or zero rate can use MonetaryAmount. A calculated rule can use ShippingRateSettings for fixed components, weight-based amounts, order-based percentages, or free-shipping thresholds. The surrounding ShippingConditions controls which route, cart, product, weight, quantity, dimension, or season receives that rate.

The amount must match checkout for the same service and inputs. A rate is not a tax, duty, product price, or total delivery promise, and it should not silently omit mandatory shipping surcharges.

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.

• Choose flat or calculated representation.
• Include currency.
• Test the complete matched condition.

Use the free backlink checker to identify linked commerce pages before changing shipping prices.

Primary specification: Schema.org definition for shippingRate.

shippingRate is accurate when the same customer inputs produce the same shipping charge in markup and checkout.

shippingRate can appear on ShippingConditions and OfferShippingDetails, and ShippingRateSettings can also contain a nested monetary shippingRate used by its calculation.

Parent context determines scope. ShippingConditions attaches the cost to a reusable service rule. OfferShippingDetails attaches it to an Offer-specific shipping detail. A ShippingRateSettings node can combine the monetary base with percentage components and destination scope.

Do not attach shippingRate directly to Product, Offer, ShippingService, or Organization without the supported path. The parent must explain which service, geography, product, and cart receive the amount.

• 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 rate scope.
2. Choose the supported parent.
3. Add amount or settings.
4. Connect destination and service.
5. Validate the graph.

Compare ShippingConditions and OfferShippingDetails.

Correct placement binds each shipping charge to the exact policy or Offer it prices.

Use MonetaryAmount when the matched shipping charge is a simple flat, zero, maximum, or bounded monetary value that does not require a calculation formula.

A $7.95 standard rate or $0 free rate is straightforward. Include currency and use numeric money fields. In ShippingConditions, the published amount should represent the cost customers actually see for the matched destination, cart, and service.

Do not use a flat amount when checkout adds unavoidable per-pound, percentage, remote-area, or item-count components. If the final rate varies, use ShippingRateSettings or create separate conditions that express the actual tiers.

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.

• Confirm the final charge is flat.
• Set numeric value.
• Add currency.
• Test checkout totals.

Review MonetaryAmount in shipping schema.

MonetaryAmount is the right choice when one matched rule resolves to one stable monetary shipping cost.

Use ShippingRateSettings when the shipping cost is calculated from fixed charges, shipment weight, order value, destination, or free-shipping thresholds.

A rule can combine a base monetary shippingRate with weightPercentage or orderPercentage logic and other rate settings. The model must mirror the actual checkout formula rather than approximate it for markup.

Calculated settings require clear units, currency, qualifying cart amount, and destination scope. If the rate engine has carrier-live pricing that cannot be represented stably, do not publish a fabricated fixed approximation.

• 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. Document the checkout formula.
2. Map each component.
3. Set currency and units.
4. Test representative carts.
5. Avoid unsupported approximations.

See ShippingRateSettings for the full calculated model.

ShippingRateSettings is useful when every published component reproduces the live rate calculation.

Free shipping should use an explicit zero monetary rate for the qualifying service and condition rather than omitting shippingRate or labeling every service free.

A cart may receive free standard shipping above $50 while express remains paid. The zero rate must share the same destination, orderValue, product eligibility, quantity, weight, and season used by checkout.

Visible banners, cart progress messages, product pages, structured data, and checkout must use one qualifying subtotal formula. If discounts remove eligibility, the matched condition should change accordingly.

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.

• Represent zero explicitly.
• Separate service levels.
• Define threshold calculation.
• Test discounts and exclusions.

Use orderValue for cart thresholds.

Free shipping is truthful when only the qualifying service, cart, destination, and product receive an explicit zero rate.

Currency and rounding should match the checkout market, monetary precision, component order, and final displayed shipping amount.

A rate of 10 without currency is ambiguous. USD, CAD, and EUR tiers need independent context. Percentage and weight components can produce fractions of a cent, so rounding before or after summing components can change the customer charge.

Document whether checkout rounds each component or only the final rate. Do not freeze a converted threshold or rate from one day as a permanent value for another market.

• 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 currency.
2. Use numeric money fields.
3. Document rounding sequence.
4. Test fractional components.
5. Validate localized markets.

A shipping rate is interpretable when currency, precision, and rounding reproduce the amount shown at checkout.

Rate tiers should combine destination, service, order value, quantity, weight, dimensions, and product scope so one cart receives one rate per eligible shipping option.

A California cart below $50 may pay $7.95, while a Hawaii cart pays $15 and an order above $50 receives free standard shipping only in qualifying regions. Heavy or oversized products may require separate rates despite the same subtotal.

Build a decision matrix and test intersections. Broad country rules and narrow state or ZIP rules need deterministic specificity, while standard and express remain separate selectable services.

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.

• Resolve destination.
• Resolve product and cart constraints.
• Select service level.
• Apply one rate.
• Test intersections.

Use shippingDestination to scope geographic pricing.

Rate tiers are coherent when each cart resolves to one price for every distinct eligible service.

Common mistakes include missing currency, treating an omitted rate as free, using a flat amount for a variable formula, excluding mandatory surcharges, mixing service levels, overlapping tiers, and publishing stale prices.

Other defects include copying one market's rate to another, using product price as shipping cost, ignoring rounding, applying one Offer exception to the catalog, and treating syntax validation as proof of checkout parity.

Shared rate defects can affect an entire catalog. Repair the authoritative pricing configuration and regenerate markup rather than patching pages individually.

• 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 rate and parent.
2. Validate type and currency.
3. Find overlaps and omitted components.
4. Compare checkout carts.
5. Repair the source.

shippingRate defects require monetary, formula, service, geography, tier, and checkout validation together.