How to set up shipping zones and delivery rates

Set up shipping in this order: decide which countries you can serve, group destinations that can share one price and promise, calculate the cost of each group, configure the eligible methods in Setka, and test representative addresses through checkout. Enter the approved rates and destination rules in Setka’s shipping settings, then verify the customer-facing result in the published store. Do not publish a destination merely because a carrier website appears to cover it; first prove that your products, service, costs, and operating process work there.

Start with product and destination constraints

A shipping plan begins with the parcel, not a map. Record the packed weight, outer dimensions, packaging cost, handling time, replacement value, and any restrictions for a representative order. A ceramic set, chilled food, perfume, lithium battery, and rolled print do not share the same service options even when the delivery address is identical.

For each intended country, confirm four things in the records and services your business uses:

• the provider accepts the product and packed parcel;
• the service actually covers the intended destination and address type;
• your business can complete the required tax, customs, product, and consumer obligations;
• your team can pack, dispatch, communicate, and handle exceptions consistently.

Keep unsupported destinations out of checkout. “We will solve it after the order arrives” transfers an unresolved operating problem to the customer. If a launch depends on temperature control, dangerous-goods handling, remote-area surcharges, cross-border paperwork, or another specialist service, resolve that requirement before configuring the country.

Build a one-row parcel profile for the order you expect most often, then add rows for realistic extremes: the smallest order, a mixed order, and the largest order you are prepared to dispatch. Record packed measurements rather than product measurements. If those parcels do not fit the same provider price, a single customer rate must either absorb the difference or be reconsidered. Setka’s shipping rules can set rates by order value, not by weight yet. Configure any order-value rate in Setka and test every boundary in checkout; if your launch needs weight-based pricing, tell us at [email protected]: requests go straight to the people building Setka.

Shipping is one dependency in the wider online-store build sequence. Product facts, payment configuration, delivery eligibility, and the order workflow need to agree before publication.

Plan zones as country groups

A shipping zone is useful here as a planning term: a group of destinations that can honestly share the same available method, customer price, and delivery language. Enter that plan as shipping rules in Setka, then verify the result with representative addresses.

Start with the smallest useful structure. One domestic group plus one nearby-country group is often easier to price and test than a worldwide launch. Split a group whenever one of these changes materially:

• provider or service availability;
• your expected parcel cost;
• tax treatment of the shipping charge;
• delivery wording or operational process;
• a surcharge or exception you cannot safely absorb.

A planning diagram might look like this:

                         DESTINATIONS YOU CAN SERVE
                                      |
                 +--------------------+--------------------+
                 |                                         |
          Group A: Home country                    Group B: Nearby countries
          PL                                      DE, CZ, SK
                 |                                         |
        +--------+--------+                       +---------+---------+
        |                 |                       |                   |
  Method A          Method B                Method C           No second method
  18.00 PLN         12.00 PLN               42.00 PLN          unless verified
        |                 |                       |
  Home-country rule Home-country rule        Nearby-country rule

Every number in that diagram is fictional. Its purpose is to show the mapping: one commercial group may need multiple customer choices, each with a clear eligibility rule. Do not create overlapping rules unless you intend customers in the overlap to see multiple choices.

Build the real cost before choosing the customer rate

The carrier invoice is only one part of shipping cost. Build an expected cost per dispatched order from:

provider charge
+ packaging materials
+ pick-and-pack labor
+ expected surcharges
+ allowance for failed delivery, loss, or reshipment
= expected delivery cost

Then compare that cost with the amount the customer pays. Use amounts on a consistent tax basis. If your customer-facing rate includes tax, do not compare it directly with net costs; first derive the net shipping revenue using the tax treatment confirmed for your store and jurisdiction.

Example 1: domestic courier, fully charged

Fictional assumptions: customer pays 18.00 PLN gross; assumed shipping tax rate is 23%; expected net delivery cost is 13.20 PLN.

Net shipping revenue = 18.00 / 1.23 = 14.63 PLN
Shipping contribution = 14.63 - 13.20 = 1.43 PLN

This rate leaves 1.43 PLN before costs the assumptions omit.

Example 2: pickup price subsidized by product margin

Fictional assumptions: customer pays 10.00 PLN gross; assumed shipping tax rate is 23%; expected net delivery cost is 11.60 PLN; product contribution before shipping subsidy is 32.00 PLN.

Net shipping revenue = 10.00 / 1.23 = 8.13 PLN
Shipping contribution = 8.13 - 11.60 = -3.47 PLN
Contribution after subsidy = 32.00 - 3.47 = 28.53 PLN

The merchant is deliberately absorbing 3.47 PLN. That may be acceptable, but only if the order contribution can carry it. If a discount can apply to the same order, model the combination using the discount-and-margin guide rather than approving each incentive separately.

Example 3: a nearby-country average hides a loss

Fictional assumptions, all net: customer shipping revenue is 34.00 PLN. Expected cost is 29.00 PLN to Country B, 33.00 PLN to Country C, and 43.00 PLN to Country D.

If orders are evenly distributed, the group averages a 1.00 loss per shipment. More importantly, every Country D order loses 9.00. Split Country D into a separate method or choose a rate that the complete group can support. An average should not conceal a predictable destination-level exception.

Add a sensitivity check before approving the rate. Recalculate each example with a higher provider charge, one extra unit of packaging, and a plausible failed-delivery allowance. The point is not to predict every invoice exactly; it is to learn which assumption can turn a tolerable subsidy into an unacceptable loss. Write down the date and source of every supplier input so the rate can be reviewed when a quote changes.

Decide whether to subsidize shipping

A delivery rate can recover the expected cost, recover only part of it, or include a buffer for variability. Make the choice deliberately. A low displayed rate is not “free”; the difference is funded by product margin or the rest of the business.

You may also model an order-value threshold as a commercial planning scenario. For example, under fictional assumptions, compare contribution on a 120 order paying 12 for delivery with contribution on a 180 order where the merchant absorbs a 12 delivery cost. Include product cost, discounts, payment cost, packaging, and expected shipping cost in both cases.

Setka supports free or discounted shipping and spend-and-save offers. Model the threshold economics first, configure the chosen rule, and test baskets below, at, and above the boundary before advertising it.

Configure the approved plan in Setka

Enter each approved row as a shipping rule in Setka, then check the resulting checkout behavior:

1. Give it a customer-facing display name, such as “Domestic courier” or “Local pickup.” Avoid an unverified carrier name or delivery-time promise.
2. Match it to the intended delivery service and destination group.
3. Enter the approved customer price using one consistent currency and tax basis. The merchant remains responsible for the correct tax treatment.
4. Test an eligible address, an ineligible address, and every price boundary in the published store before launch.
5. Inspect the method in the customer checkout path rather than treating an admin record as proof that the rule works.

This is where Setka is practical for a focused launch: manual shipping configuration sits inside the same commerce platform as the cart, checkout, payment, and order. You do not need to translate the shipping plan into a separate storefront theme. Review how shipping appears before payment in the shopping-cart UX guide and test it alongside the Stripe checkout flow.

Setka doesn’t create carrier labels yet; you book shipments with your carrier. If your launch depends on label automation, tell us at [email protected]: requests go straight to the people building Setka.

Test addresses, totals, and language

Create a compact test matrix with at least one address inside every allowed group, one country just outside it, and a boundary case that could trigger special handling. Use fictional customer data reserved for testing.

Check the full amount after every address or method change: items, discount, shipping, tax, and final total. After payment succeeds, confirm that Setka created the expected paid order. The first-order workflow begins from that order and covers fulfillment.

Delivery language should promise only what you control. “Fixed courier delivery — 18 PLN” names a method and price. “Arrives Tuesday” claims a timing outcome that may depend on cutoffs, carrier acceptance, destination, disruption, and successful delivery. If you publish an estimate, document its basis, scope, cutoff, and exception wording first; do not turn an internal best case into a guarantee.

For unsupported destinations, write a useful stop state: explain that delivery is not currently available to the selected country, invite the shopper to choose an eligible address if appropriate, and provide a genuine support route only if your team can answer exceptions. Never invite the customer to pay first and negotiate shipping later.

Configure one region, then prove it

Choose the destination group that represents your main launch demand. Confirm the parcel constraints and real provider costs, configure the smallest honest set of supported methods, and test an eligible address, an ineligible address, every displayed total, and the resulting order record. Start with one main delivery region and make it reliable before adding another. Then follow your first paid order from checkout to parcel.