What Is orderPercentage in ShippingRateSettings?

orderPercentage is a Number representing the fraction of total order value charged as shipping cost.

A value of 0.10 means the shipping component is ten percent of the defined order value. The property belongs to ShippingRateSettings and participates in a calculated rate; it does not define whether a cart qualifies for a condition or free-shipping tier.

The formula needs an authoritative cart-value definition, currency, base-rate context, discounts and exclusions policy, and rounding behavior. Without these inputs, the fraction cannot reproduce checkout.

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 0.10 as ten percent.
• Define the order-value base.
• Match checkout currency and rounding.

Use the free backlink checker to identify linked commerce pages before changing percentage-based rates.

Primary specification: Schema.org definition for orderPercentage.

orderPercentage is accurate when its fraction produces the same cart-based shipping component shown at checkout.

orderPercentage belongs only on ShippingRateSettings and should not be attached directly to ShippingConditions, Product, Offer, or OfferShippingDetails.

ShippingConditions or OfferShippingDetails can use shippingRate whose value is ShippingRateSettings. That settings node contains the fraction and any base monetary rate, destination, free threshold, label, or fallback configuration.

Correct nesting separates the order amount used as a formula input from the percentage that prices it. A Product price is not automatically the total order value.

• 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 rate rule.
2. Attach ShippingRateSettings.
3. Add the numeric fraction.
4. Add monetary and geographic context.
5. Validate the graph.

Review ShippingRateSettings for the parent model.

Correct placement keeps cart value and its shipping-price fraction as separate, related facts.

orderPercentage calculates a shipping-price component from cart value, while orderValue limits which ShippingConditions apply to a cart-value range.

A merchant can charge ten percent of order value using orderPercentage. Separately, it can offer free shipping from $100 upward or use a special tier from $50 to $99.99 through orderValue or freeShippingThreshold logic.

Do not place 100 in orderPercentage to mean a $100 threshold, and do not place 0.10 in orderValue to mean ten percent. One is a fraction; the other is a MonetaryAmount range.

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 formula versus eligibility.
• Use Number for fraction.
• Use MonetaryAmount for threshold.
• Test both together.

Compare orderValue in ShippingConditions.

The two properties remain clear when orderPercentage prices the cart and orderValue selects the cart tier.

Calculate an order-based rate by resolving the eligible order value, multiplying it by orderPercentage, combining authorized base or other components, and rounding exactly as checkout does.

A $100 eligible subtotal multiplied by 0.10 produces a $10 component. If a $4 base shippingRate also applies, the operational formula may produce $14 before other charges. Publish only the combination that checkout uses.

Document whether the input is merchandise subtotal before or after discounts, tax, gift cards, credits, or excluded products. Recompute representative carts independently.

• 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. Resolve eligible cart value.
2. Apply fraction.
3. Combine authorized components.
4. Round in checkout order.
5. Compare final total.

An order-based rate is reproducible when cart base, fraction, components, and rounding are explicit.

The formula should use the same eligible order value used by checkout, with explicit treatment of discounts, taxes, gift cards, shipping, credits, subscriptions, and excluded products.

The schema property does not decide the merchant's subtotal policy. One store may calculate from merchandise after discounts but before tax; another may exclude oversized items or marketplace sellers. The structured rate must follow the live commercial rule.

Generate customer messaging and markup from the same source. Test cases where coupons, gift cards, returns credits, bundles, and mixed seller carts change the calculation base.

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 inclusion and exclusion.
• Document calculation order.
• Test threshold-crossing carts.

orderPercentage remains truthful when its calculation base matches the exact subtotal used by checkout.

Currency and rounding should follow the order market, cart precision, component sequence, minimum or maximum charge, and final displayed shipping amount.

The fraction is currency-neutral, but its input and result are not. Ten percent of $100 USD is $10 USD, while ten percent of 100 CAD is 10 CAD. Converted markets need separate stable rules if checkout does not calculate directly in local currency.

Percentage multiplication can create fractions of a cent. Document whether checkout rounds the percentage component before adding a base or rounds only the final total.

• 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 order currency.
2. Use numeric cart values.
3. Document rounding sequence.
4. Test fractional results.

A percentage-based rate is interpretable when currency, precision, and rounding reproduce checkout exactly.

orderPercentage can combine with a base rate and must remain scoped to the destination, service, free threshold, product, and other settings that checkout applies.

A domestic service might charge $4 plus five percent of the order, become free at $150, and use a different formula for Alaska. Express may retain its calculated charge when standard becomes free.

Build a decision matrix across market, destination, service, cart value, product, and promotion dates. Apply freeShippingThreshold only where it truly overrides the calculated rate.

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 and service.
• Resolve eligible subtotal.
• Apply base and fraction.
• Evaluate free threshold.
• Test full intersections.

Review shippingRate and shippingDestination.

Calculated rates are coherent when base, percentage, threshold, and destination resolve in a documented order.

Common mistakes include entering 10 instead of 0.10, using product price instead of cart value, including the wrong subtotal components, omitting currency context, double-counting a base rate, and rounding differently from checkout.

Other defects include confusing the property with orderValue, applying free thresholds to all services, copying one market formula globally, ignoring caps or minimums, and publishing an approximation for a dynamic carrier quote.

Formula defects often originate in shared pricing configuration. Repair the authoritative rate source and regenerate markup instead of patching each Offer.

• 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 fraction and parent.
2. Recompute known carts.
3. Validate subtotal and currency.
4. Find duplicate components.
5. Repair the source.

orderPercentage defects require fraction, cart-base, monetary, formula-order, service, and checkout validation together.