A merchant emails their theme developer: "can we hide prices until someone logs in?" Two days later there is a Liquid snippet in price.liquid, the prices are gone from the collection grid, and everyone is happy. Three weeks later a competitor emails a screenshot of the wholesale price list, pulled straight out of a URL ending in .js.
This happens constantly, and it is not because anyone did anything stupid. It happens because Shopify exposes product data in several places and the theme is only one of them. Before you buy anything, it is worth being precise about what Shopify already gives you.
What Shopify supports natively
1. The store password page
Online Store → Preferences → Restrict store access. This puts a single shared password in front of the entire storefront. Nothing renders, no product JSON is served, no page is indexable. It is free, it takes ten seconds, and it is genuinely secure.
Its limitation is that it is all or nothing. You cannot open the homepage and lock the trade catalog. You cannot give one password to retailers and another to press. And while it is on, Google sees a 401-style wall and your store does not accumulate any organic footprint.
2. Customer accounts
Shopify gives you accounts, login, and a customer object in Liquid. In a theme you can branch on {% if customer %} and render different markup for logged-in visitors. That is real and it works, for display. What it does not do is stop anything. The customer object is a rendering condition, not a permission.
3. Native B2B (Plus only)
On Shopify Plus you get companies, company locations, price lists and catalogs. A catalog can be published only to specific companies, and products outside a buyer's catalog genuinely are not purchasable by them. This is server-side and it is enforced. If you are on Plus and your buyers map cleanly onto companies with locations, this is the correct tool and you should use it.
It is also Plus-only, it models B2B as accounts rather than tags, and it does not cover the case where you simply want a page hidden from the public.
What is not built in
- Hiding prices for one collection while the rest of the store trades normally.
- Gating by customer tag on any plan below Plus.
- An application form, an approval queue, and an auto-tag on approval.
- A scheduled opening: locked until Friday 09:00, open after.
- Per-recipient access links for buyers or press who will not create an account.
Every one of those is a legitimate, common requirement, and every one of them sits in the gap between the password page and Plus.
The three places a price leaks
This is the part that catches people. Removing a price from the theme removes it from one surface out of three. Open your own store and check all three in the next ten minutes.
The rendered theme
The obvious one: the product page, the collection grid, search results, cart drawer, related products, and any section that renders a money value. Note how many places that actually is. A snippet edit in price.liquid usually catches most of them and misses the cart drawer.
The product JSON endpoint
https://your-store.myshopify.com/products/wool-throw.js
https://your-store.myshopify.com/products/wool-throw.json
https://your-store.myshopify.com/collections/trade/products.jsonThese are core storefront endpoints. Your theme's own AJAX cart depends on them. They return variant IDs and prices in cents regardless of what the theme rendered, and they cannot be turned off by editing Liquid. The collection endpoint will happily paginate your entire trade catalog into a spreadsheet.
Structured data and feeds
Most themes emit Product JSON-LD with an offers.price field, and the Google & YouTube channel pushes price into the Shopping feed. If you hide the price in the theme but leave the schema intact, Google will still show a price in the SERP that a visitor cannot find on the page. That is both a cloaking risk and, if you sell brands with MAP agreements, a commercial problem.
Hiding is not the same as blocking
Even if you closed all three leaks, you have hidden information, not prevented a purchase. A cart permalink of the form /cart/44192837465:1 adds a variant to the cart without ever touching the product page. Nothing in the theme is involved, so nothing in the theme can stop it. That deserves its own article, and it has one.
The dividing line is server-side enforcement. Shopify Functions (specifically cart and checkout validation) run on Shopify's servers on every plan, including Basic. A validation function can reject a checkout that contains a restricted variant, and there is no client-side trick that gets around it. That is the only layer where "blocked" means blocked.
So which should you use
| Your requirement | Use this | Why |
|---|---|---|
| Store is not launched yet | Shopify's store password | Free, instant, airtight. Nothing renders and nothing is indexed. |
| Plus merchant, buyers are companies with locations and terms | Native B2B catalogs | Server-side, first-party, handles price lists and payment terms. |
| Part of the store public, part restricted by segment | An access-control app | Not expressible with the password page; needs per-resource rules. |
| Prices hidden until login or approval, on a standard plan | An access-control app with checkout enforcement | Tag-based gating below Plus does not exist natively. |
| You only need a soft nudge, not a real barrier | A theme snippet | Honest answer: if the data is not sensitive, cosmetic is fine. |
Prime Lock exists for rows three and four. It sets rules on collections, products, pages and URLs, keeps the pages indexable while withholding the price, and backs every rule with a Shopify Function so a cart permalink fails at checkout rather than succeeding quietly.
If your requirement is row one or row two, use what Shopify gives you. It is better, cheaper and already there.
What changes on new customer accounts
One platform detail reshapes this decision and catches merchants out regularly. Shopify now offers two account systems: classic accounts, where the login and registration forms are rendered by your theme, and new customer accounts, where Shopify hosts the entire login flow at a URL you do not control and cannot template.
On classic accounts, the registration form is a theme file, so it was always possible to bolt extra fields onto it. Those fields could only be written as note attributes, which meant no validation, no file uploads and no approval step, but the form was yours to edit. On new customer accounts, it is not. The page is hosted by Shopify, apps cannot inject fields into it, and no amount of Liquid will change that.
The practical consequence is that any wholesale flow which depends on customising Shopify's own registration form is building on ground that has already shifted. The approach that survives is to keep Shopify's login exactly as it ships, collect applications on a separate form, and make access depend on a customer tag rather than on anything about how the account was created. Tag-based access behaves identically under both account systems, which is why it is worth preferring even if you are still on classic accounts today.
A short checklist before you choose
Most of the wrong decisions in this area come from answering the wrong question first. These four, in order, settle it faster than comparing feature lists.
- 1Is any part of the store meant to be public right now? If no, stop there: use the store password and revisit this at launch.
- 2Would you be unhappy if someone outside your trade channel bought at the trade price? If no, a theme snippet or a display-only app is genuinely enough and you can stop reading comparison tables.
- 3Are you on Plus with buyers who are companies rather than individuals? If yes, native B2B catalogs will do this better than any app, and they are enforced server-side already.
- 4Do you need to vet applicants before access opens? If yes, you need a registration and approval workflow as well as a lock, and those are separate capabilities that not every app in this category publishes.
Answer those four honestly and the shortlist usually has one or two apps on it rather than a dozen. The category is crowded, but most of the crowding is at the display layer, and the questions that actually narrow the field are about enforcement and about vetting.