Is your wholesale price list really hidden? A 10-minute check for trade websites

Many trade websites hide prices in the page, not on the server. How to check whether yours hands your wholesale list to anyone who asks, and what a portal that cannot leak looks like.

By Vakkas Celik, Salix Limited · · 7 minute read

Your wholesale list took years of negotiation to build, and it is exactly what a competitor who is also a customer would like to read. So your trade site shows products to everyone and prices only to approved accounts. The question is whether it actually does, or only looks that way.

You can find out in about ten minutes with a normal web browser and a price you know by heart. You do not need to be technical, though it is a fair job to hand to whoever in the family is good with computers. Do it on your own site, or one you have written permission to test: the point is to see your site the way a stranger would.

Hidden is not the same as never sent

A web page is two things. There is what your browser receives from the server, and there is what it shows you. They are not always the same.

Some trade sites send the full product record to every visitor, price included, and then use the page’s styling or a script to hide the price unless you are logged in. On screen the price is gone. In the data your browser downloaded, it is sitting right there, for anyone who looks underneath the page and for any program that downloads pages automatically.

A price that is never sent is different. The server checks who is asking first, and a logged-out visitor’s browser never receives a price at all. That is the only kind of hidden that counts, and the checks below are ways of telling the two apart.

The ten-minute check

Pick two or three products and write down their trade prices. Note the plain forms too: $12.50 might be stored as 12.5, 12.50 or 1250 (in cents). Then open a private or incognito window (Ctrl+Shift+N in Chrome and Edge, Ctrl+Shift+P in Firefox), which starts with no login.

1. Search the page source

In the private window, open one of your chosen product pages. Right-click an empty part of the page and choose View page source, or press Ctrl+U (Cmd+Option+U on a Mac). That is the raw page your server sent. Press Ctrl+F and search for each form of the price you wrote down.

Also search for the word price. Many sites add hidden product details for search engines, often with a price field nobody remembers adding. If your trade price is anywhere in the source, the page is only hiding it.

2. Watch the Network tab

Modern sites often load products separately, after the page appears. Those requests do not show up in the page source, so check them directly. Press F12 to open the browser’s developer tools and click the Network tab. Choose the filter labelled Fetch/XHR and reload the page.

Click each request and look at its Response or Preview. Many will be product data in a format called JSON. Look for a field called price, cost or rate, and for your numbers. In Chrome and Edge, Ctrl+F inside the Network tab searches every response at once. Repeat on a category page and your search results, which often use different requests.

3. Open those addresses on their own

If one of those requests has a clear address (something like /api/products/1234), right-click it, copy the address, and paste it into a fresh private window. If it returns product data with a price and you are not logged in, that address is open to anyone. Try removing the number from the end, too. An address that returns your whole range at once is the ordinary way a wholesale list leaves a trade site: not a clever attack, just a data address nobody thought to lock.

4. Check search, the sitemap and any product feeds

Search your own site while logged out, checking the drop-down suggestions as well as the results page. Visit /sitemap.xml on your domain and open a few product links. Then ask whoever set up your site whether it publishes a product feed for shopping services or social media catalogues. Feeds are built to carry prices, and can carry trade prices without anyone deciding they should.

5. Ask Google

Search Google for site:yourdomain.co.nz "12.50", using your own domain and one of your trade prices. Try the product name plus the word price too. If Google shows your trade price in its results, it has read it from your pages, and it is not the only thing on the internet that reads pages that way.

6. Look at what leaves by email

Order confirmations, quotes and price notices carry prices, and no login rule applies to an email once it is sent. Make sure a sign-up that has not been approved yet is not emailed a price list.

What your results mean

No price found is a good sign, not a guarantee. You tested the pages you thought of, on one day. Leaks tend to arrive later, with a small change nobody connected to prices: a new add-on, a faster search box, a feed for a new sales channel.

If you did find a price, write down exactly where and send it to whoever looks after the site. Closing one open address is often a small job. The harder question is why it was open, because whatever allowed it once will allow it again.

What a portal that cannot leak looks like

The safe design starts from a simple idea: the part of the system that serves public pages should not have prices, so no mistake on a public page can reveal one. When Salix builds a trade portal, that idea is held in four separate places.

  • The public product table has no price column. Asking it for a price is an error when the code is built, not a leak in production.
  • The prices live somewhere the public data service does not publish. A request for them gets a “not found”, not an empty list.
  • Access is removed at the database, not filtered. A careless future change fails closed instead of open.
  • Public pages send no database key to the browser at all. There is nothing in the page to point at the data.

On top of that, approval is checked on every request, so suspending an account stops its prices on the next page it loads. The browser never sends a price when an order is placed; every amount is worked out again on the server. And the heart of the check above is automated: a test suite crawls every public address with no login and searches what comes back for anything that looks like money, on every change and again each night. Every email template is rendered and searched the same way. Grand Bazaar in Auckland runs on a portal built this way, and its case study goes through each layer.

Whoever builds yours, those are fair questions to ask them. Where do the prices live? What does a logged-out request for them return? What checks for a leak after the site goes live, and how often?

When you do not need to replace your site

Plenty of trade sites do not need rebuilding. If your checks came back clean and whoever looks after the site can explain why prices are never sent, keep it and repeat this check after every significant change. If you found one open address that can be closed, close it.

If your customers order by phone or WhatsApp and are happy doing so, you may not need a portal yet. Replacing a site makes most sense when prices keep turning up where they should not, when nobody can say where they are stored, or when the site and your accounts disagree about what things cost.

If you would like a second pair of eyes

Salix offers a fixed-price, three-day Catalogue & Pricing Audit called The Ledger, for $1,500. It reads your price list and its tiers properly, counts what your catalogue actually contains, and writes down what your current site exposes today. You keep the written scope whether or not you go ahead, and “you do not need to replace this yet” is a legitimate result. If you do go ahead, the $1,500 is credited in full against the build. There is no GST on any of it, because Salix Limited is not GST-registered.

The full portal, the packages and how it works with Xero are on the Salix Trade page.

More guides