How to Set Up Shipping Zones and Delivery Rates

Turn the places you can serve into a small set of clear delivery choices, then price each choice against its real cost. This guide shows how to plan destination groups, calculate margin, translate the plan into manual shipping settings, and test the address-to-order path before launch.

All guides

Shipping setup guide

Published 31 August 2026

On this page

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. Bring the approved rates, destination rules, and required delivery methods into onboarding, then verify the customer-facing result in the deployed 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. Bring any conditional rate logic your launch requires into onboarding and test every boundary in checkout.

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. Map that commercial plan to the store’s shipping configuration during onboarding, 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.

An original 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 a 1.43 PLN contribution before any costs omitted from the assumptions. It is not automatically profitable: check the provider quote, packing labor, surcharge frequency, and applicable tax treatment with current primary records.

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.

Destination	Net revenue	Expected cost	Shipping contribution
Country B	34.00	29.00	+5.00
Country C	34.00	33.00	+1.00
Country D	34.00	43.00	-9.00

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

Use onboarding to map each approved row to the store’s shipping configuration, then check the resulting checkout behavior:

Give it a customer-facing display name, such as “Domestic courier” or “Local pickup.” Avoid an unverified carrier name or delivery-time promise.
Match it to the intended delivery service and destination group.
Enter the approved customer price using one consistent currency and tax basis. The merchant remains responsible for the correct tax treatment.
Test an eligible address, an ineligible address, and every price boundary before publication.
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. The merchant still owns the rate, destination decisions, tax treatment, truthful wording, and tests. Review how shipping appears before payment in the shopping-cart UX guide and test it alongside the Stripe checkout flow.

If the launch depends on carrier-specific automation, bring that requirement into onboarding before choosing the operating model. The team can give a direct answer for the current product and planned store instead of leaving the merchant to infer behavior from a generic guide.

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.

Test	Expected result	Evidence to record
Eligible domestic address	Correct configured choices appear	Country, method names, prices, cart/checkout total
Eligible cross-border address	Only the approved cross-border method appears	Country, method, price, tax display, total
Unsupported country	No order can proceed on an unavailable promise	Address used and exact customer message
Address correction	Eligibility and totals update correctly	Before/after address and totals
Completed order	Chosen method and amount reach a paid Setka order	Order reference, method, currency, and totals

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 fulfilment.

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.