If you searched shipping policy Shopify because you assumed there was a single toggle that both writes the legal text and configures the actual shipping rates, there isn’t — Shopify treats them as two unrelated systems, and that gap is where most published shipping policies go wrong. This guide covers where the policy lives, what it has to say, a usable template, and the reconciliation step that catches the mismatch before a customer does.
Shipping Policy Shopify Setup: Where It Actually Lives
A Shopify shipping policy is a text document stored under Settings > Policies, alongside your refund, privacy and terms-of-service policies. It is not a shipping setting — it configures nothing. It is prose that Shopify renders in two fixed places: at checkout, in a link near the shipping method selector, and in the storefront footer, where most themes place a link automatically once the policy has content.
Because it renders automatically once populated, an empty or half-written shipping policy is visible to every visitor who reaches checkout, not just the ones who go looking for it. A blank policy field and a wrong one produce different problems — a blank field reads as a store with nothing to hide behind, and a wrong one reads as a store that will not honour what it published. Neither is a good place to be found for a brand doing $3M–$30M, where the checkout experience is under more scrutiny than a smaller store’s ever gets.
Shopify offers a Create from template option inside Settings > Policies that generates a starting document from your store name, address and locale. It is a reasonable first draft. It is not a finished policy, because it has no knowledge of your actual carriers, rate logic or fulfilment locations — it fills in placeholder language that reads correctly and describes nothing real.
What the policy has to say
A shipping policy earns its place at checkout by answering the five questions a buyer is actually asking before they commit to a purchase. Each needs to be answered with specifics, not with a category name.
Carriers and services. Name the actual carriers — UPS, USPS, FedEx, a regional carrier, a 3PL’s contracted network — rather than “a trusted shipping partner”. A buyer checking whether a carrier reaches a rural address cannot act on a vague sentence.
Processing time versus transit time. These are two different clocks and the policy has to separate them. Processing time is how long an order sits before it ships; transit time is how long the carrier takes once it has the package. A policy that only states “delivery in 5–7 days” and omits processing time understates the real wait by however long fulfilment takes to pick and pack.
Cost logic. State the actual rule — flat rate, weight-based, a free-shipping threshold, carrier-calculated rates passed through at checkout — in the same terms your rate settings use. The cost-logic clause is the one most likely to drift from reality, because it is the only clause tied to a rate setting that changes independently of the policy text; the reconciliation check under “The mismatch teams get wrong” is written specifically for this clause.
International handling. State which countries you ship to, who is the importer of record, and whether duties and taxes are collected at checkout (Shopify Managed Markets or a duty-calculation app) or on delivery. A buyer outside your home country who is surprised by a duty bill at the door is a chargeback risk and a support ticket, not just a bad experience.
Delivery exceptions. Cover what happens on a failed delivery attempt, a wrong address entered at checkout, and a package marked delivered that the customer says never arrived. Each of these needs a stated process, because without one, support handles them case by case and inconsistently.
A shipping policy template you can adapt
The following is a structural template — fill every bracket with your real settings, never leave a placeholder in a published policy. Sections and their order are shown as a table so you can check the policy you already have against what an operator-facing policy needs to cover.
| Section | What it must state | Common gap |
|---|---|---|
| Processing time | Business days before an order ships, and whether weekends/holidays count | Stated as calendar days when it’s really business days |
| Carriers and transit | Named carrier(s), service level, transit-time range per zone | Generic “standard shipping” with no carrier named |
| Cost and free-shipping threshold | The exact rule — flat rate, weight tier, or a dollar threshold — matching Settings > Shipping and delivery | Threshold in the policy text no longer matches the live rate condition |
| International | Countries served, duties/taxes handling, customs delay language | Silent on duties, leaving the buyer to discover them at the door |
| Delivery exceptions | Process for failed delivery, wrong address, “delivered” disputes | No process stated; each case handled ad hoc by support |
| Damaged or lost in transit | Who files the carrier claim, replacement or refund timeline | Left entirely to the refund policy, which buyers won’t find at checkout |
| Return-to-sender | What happens to the order and the refund when a carrier returns an undeliverable package | Omitted — RTS volume becomes a support backlog with no documented process |
Read this table left to right for what to write, and use the right column as your gap check against a policy that already exists — those are the specific clauses that go missing or go stale first.
The mismatch teams get wrong: policy text versus live rate settings
The proprietary problem in a Shopify shipping policy isn’t the writing — it’s that the policy and the rate engine are two independent systems, and Shopify never checks one against the other. Settings > Policies holds a block of text. Settings > Shipping and delivery holds the shipping profiles, zones and rate conditions that actually calculate the number a customer pays at checkout. Nothing in the admin flags it when these two disagree, and they disagree more often than teams expect, for one recurring reason: the rate settings get edited after the policy is written, and the policy is never revisited.
A concrete version of this: a policy states “free shipping on orders over $75,” written when that was the storewide rule. Months later, ops sets up a second shipping profile for a new product line with different weight and dimension rules — heavier catalogue items, a separate warehouse, a 3PL with its own rate card — and that profile has no free-shipping condition at all, or a different threshold. The published policy still says $75 storewide. A customer in the second profile hits $80 in cart, expects free shipping at checkout per the policy, and sees a shipping charge instead. That is a checkout abandonment and, if they complete the order anyway and then read the policy again, a chargeback risk and a support ticket that starts from “your policy says.”
The fix is a reconciliation pass, not a rewrite: open Settings > Shipping and delivery, and go through every shipping profile — not just the default one — checking its actual rate conditions, zones and thresholds against every dollar figure and rule stated in the policy. Do this whenever a shipping profile changes, a new product line ships from a different location, or a carrier contract changes rates, not only when the policy is first written. A store running more than one shipping profile — which is common past the $3M mark, once a brand has multiple product lines or a 3PL relationship — is the highest-risk case, because the policy is written once against “the” rate rule and the store quietly stops having just one.
The rate-condition side of this problem is covered in more depth in our guide to Shopify shipping rates, which walks through how rate conditions, zones and profiles are actually configured — read it alongside this one if the reconciliation check turns up a mismatch you need to fix at the settings level, not just the policy level.
How to verify the policy is live and correct
After publishing, check three things rather than assuming the save worked as expected.
Checkout placement. Go through a test checkout — a real cart, not the admin preview — and confirm the policy link appears at the shipping method step and that clicking it opens the current version, not a cached one.
Footer placement. Most Shopify themes pull the policy links into the footer automatically once Settings > Policies has content, but theme customisation can override this. Check the live storefront footer, not just the admin.
Content accuracy against rates. Go through every shipping profile in Settings > Shipping and delivery and check its live rate conditions against the dollar figures and rules stated in the policy. That profile-by-profile check catches the drift no admin warning will surface, and it is the one most teams skip because nothing in the interface prompts them to run it.
Who should not spend more time on this
A store running a single shipping profile, one flat rate or one free-shipping threshold storewide, with no immediate plans to add a second profile, a 3PL relationship or an international zone, carries low reconciliation risk — write the policy once, carefully, and revisit it only when the rate settings actually change. The reconciliation discipline in this guide matters most once a store has outgrown a single, simple rate rule, which is the point at which shipping-policy drift starts costing real support time and real chargebacks rather than being a theoretical risk.
A mismatch caught once, by chance, is a bad checkout experience corrected late. The same mismatch recurring across every shipping-settings change nobody remembers to check against the published policy is an operations problem — one more manual step that depends on someone remembering to run it, with no system enforcing it. Our ops automation work is built to close exactly that gap: turning a manual cross-check like this one into a process that runs itself instead of one more thing the ops team has to remember on top of everything else.
Sources
No external figures are quoted; this article is written from how Shopify’s Settings > Policies and Settings > Shipping and delivery are configured and operated.