How to use this page

Shipping should not be seen only as a technical configuration. It is part of the commercial experience, because a wrong calculation, an inconsistent rule, or an unexpected cost can prevent the purchase from being completed even when the rest of checkout is working properly.

Shipping rules
Shipping types
Edge cases

1

Main shipping list

Existing delivery rules

Shipping list in Studio CMS E-commerce
The list gathers the different configured shipping rules, showing name, type, status, and management actions for each delivery rule.

This is the view where the team can quickly understand which shipping logics exist in the store, which ones are active, and what kinds of calculations are currently affecting the order total at checkout.

2

Available shipping types

Possible calculation logics

Available shipping types in Studio CMS E-commerce
Studio lets the team choose different calculation logics such as weight, order value, manual request, or distance.

Main types

  • weightrange for calculation by weight ranges.
  • pricerange for calculation based on order value.
  • onrequest for scenarios that require manual validation.
  • googledistance for calculations dependent on distance.

When to use each type

  • Use weight-based calculation when logistics cost depends on physical load.
  • Use price-based calculation when you work with order value tiers.
  • Use manual request when the cost cannot be closed automatically.
  • Use distance when transport depends on the real location of the destination.
Useful reading: the shipping type is not a minor technical detail. It defines the calculation logic that will directly affect the cost shown to the user at checkout.
3

How to configure a shipping rule

Shipping rule structure

Shipping rule configuration in Studio CMS E-commerce
A shipping rule combines identification, calculation type, intervals, cost, and geographic context to define the final rule applied to the order.

When configuring a shipping rule, the team defines not only the name of the rule, but also the logic that determines when it becomes active and how much should be charged in each scenario.

Base fields

  • Name and ERP code identify the rule.
  • Type defines the calculation logic.
  • Profiles help segment the application when needed.

Calculation rules

  • Intervals define minimums, maximums, and associated cost.
  • Country list helps contextualise the destination.
  • VAT rate completes the shipping tax context.
4

What to validate before closing the rule

Calculation and checkout risks

  • Confirm that there are no overlapping intervals between minimum and maximum values.
  • Make sure there are no gaps between ranges that leave scenarios uncovered.
  • Validate whether countries, costs, and VAT are consistent with the defined rule.
  • Test edge cases in checkout before considering the configuration closed.
Attention: a poorly designed rule can cause unexpected costs, missing shipping options, or inconsistent behaviour at checkout. Edge cases should always be tested.
5

Configuration good practices

Direct impact on conversion

  • Give shipping rules clear names so the team can identify them easily.
  • Choose the calculation type that best matches the real delivery objective.
  • Always test edge cases before publishing the rule.
  • Confirm that countries and tax context are correct.
  • Validate the impact of shipping on the final order total and on user perception.
Good practice: treat shipping as part of the commercial experience, not just as a backoffice configuration. A poorly defined delivery cost can directly compromise conversion.
6

Explore also

Areas related to checkout and operations