Your Shopify Markets settings can look correct — while a customer still can’t buy the product

I’ve been testing Shopify Markets setups and there’s one QA problem I keep coming back to:

We tend to verify things separately — currency, market assignment, product availability, shipping, localization.

But the customer doesn’t experience them separately.

They experience one path:

Country → product → correct price/currency → availability → cart → checkout

And one break anywhere in that path can make an otherwise correctly configured market useless for that product.

For example, imagine:

  • The market itself is active
  • The storefront loads correctly
  • Currency changes correctly
  • Most products look fine

…but one important product or variant isn’t actually available to that market, or the buying path behaves differently for that customer context.

That seems much easier to miss than a completely broken store.

So I’m curious how merchants and agencies handle this today:

When you launch or modify a Shopify Market, do you actually test individual product buying paths for each important market — or mostly verify the configuration in Shopify Admin?

And if you’ve had a Markets-related issue reach customers, what was the failure that surprised you most?

Disclosure: I’m building Drishq MarketCheck, a Shopify Markets QA tool focused on checking these customer-facing product/market paths. I’m specifically trying to understand which real-world failures are worth catching automatically, rather than building another generic store audit tool.

The part that makes this hard to catch is what Shopify actually does when a product isn’t in the market’s catalog. It doesn’t 404 and it doesn’t show an unavailable message. The docs say a customer who opens a product page for a product that isn’t available in their market gets redirected to your store’s homepage. So the broken state and a person who simply landed on your homepage look the same in analytics. Nothing errors anywhere.

Two things that caught me out on this.

Draft orders ignore market publishing completely. The catalogs doc is explicit that product publishing rules don’t apply to draft orders, so any QA pass built on “spin up a draft order and check the price” will come back green for a product no customer in that market can reach.

Catalog inheritance isn’t a plain override either. Catalogs from a parent market and a submarket of the same type combine rather than replace, and if the same product sits in two applicable catalogs at different prices with neither being more specific, the lower price is the one shown. That is how a market can look correct on every settings screen and still sell at a number nobody chose.

The cheapest check I know is View as on the Products page. Pick the market and the list redraws in that currency, shows which catalogs each product belongs to, and marks excluded products as Unpublished. You get the whole catalogue in one screen instead of walking the path product by product. It only covers availability and pricing, not shipping or payment, but availability is where the silent version of this lives.

How many markets are you on, and are submarkets involved? The combine versus override behaviour only starts hurting once submarkets exist.

That homepage redirect is exactly the kind of silent failure I’m
worried about — especially because analytics can make it look
completely normal.

The draft-order point is also important. I’m deliberately testing
storefront context rather than using draft orders as proof of customer
availability, but the parent/submarket catalog behavior is a much
nastier edge case than a simple publish/unpublish check.

For a QA result, would you treat the “same product in overlapping
applicable catalogs at different prices” case as something that should
always be flagged, even if Shopify deterministically chooses the lower
price? My instinct is yes, because the merchant may never have
intended that effective price.

If you’ve seen a real store where this happened, I’d be interested in
the exact setup that produced it.

Atif

I checked Shopify’s current docs after your comment and they confirm
three separate silent-failure cases:

  1. If a product isn’t available in a customer’s market, opening the
    product page can redirect them to the store homepage rather than show
    a clean error.
  2. Draft orders don’t obey market product-publishing restrictions, so
    they can’t be treated as proof that a storefront customer can actually
    reach the product.
  3. If multiple applicable catalogs of the same priority contain the
    same product at different prices, Shopify can surface the lower price.

That combination is exactly why I think “Admin looks correct” isn’t
enough as a QA standard.

The test I’m now using is:

market context → product reachable → effective price/currency →
purchase control → evidence captured

I’m building that into Drishq MarketCheck as a free Shopify QA check,
but the useful part for me is identifying which of these silent states
merchants actually get caught by in production.

If anyone here has seen one of these reach customers, I’d especially
like to know whether it was caused by product publishing, overlapping
catalogs, or a submarket inheritance issue.

Atif

One extra safeguard I’d add is a “market purchase probe” for a representative SKU/variant, not just an Admin or “View as” check. Run the storefront in the customer’s country context and capture, with a timestamp: market/currency → product and variant availability → effective price → shipping quote → cart → checkout entry. Stop before payment; the goal is to prove the customer-facing path, not to test a processor’s internal step.

For prioritization, start with the highest-traffic SKU, a low-stock/market-restricted variant, and any product with complex shipping. In reporting, segment market-specific product view → add to cart → checkout entry → purchase and flag unexpected home redirects or zero-rate transitions. That separates a catalog publishing issue from a checkout or delivery issue.

That distinction is useful: Admin/catalog QA can tell you what Shopify
is configured to do, but the stronger proof is whether a real
customer-context path actually reaches the product, price, shipping
and checkout entry as expected.

The representative-SKU idea also makes sense because testing every
product/market combination can get expensive quickly.

If you could automate only one failure first, which would be most
valuable to catch reliably: wrong product availability, wrong
effective price, no shipping rate, or failure to reach checkout?

Atif