Your reps take orders on WhatsApp. Your prices live in a spreadsheet with four customer tiers in it, and the copy on somebody's laptop is not the current one. And the trade site you already have may be one badly-guarded endpoint away from handing your whole wholesale list to a competitor. We build the catalogue, the account-gated ordering portal and the office side behind it, and we make the price leak structurally impossible rather than merely unlikely.
For food and beverage importers, hospitality and building suppliers, packaging and auto-parts distributors across Aotearoa: anyone whose price depends on who is asking.
A trade portal is an operational system a business takes orders on, not a brochure with a login bolted to the side. These are the four parts, and the first one decides the shape of the other three.
Not hidden in the page: absent from it. The public catalogue table carries no price column at all, so asking it for a price is a build error rather than an incident, and the schema that does hold prices is not published to the API, so a request for it returns 404 rather than an empty list. An empty list would mean a single policy was the only thing standing there.
The basket is the order, in draft: one per account, not per person, so an owner and a manager at the same customer are placing one delivery rather than two. Minimum order quantities are applied on the server, every amount is recomputed there, and the browser never sends a price. Quantity changes are ordinary form posts, so it still works on the locked-down counter PC that is the machine this is actually for.
Whether an account may see prices is read from the database on every single query, never stamped into a login token. Suspend a customer and the prices stop on their next request, not in an hour when a token happens to expire. Sign-in is a link sent to an address you already hold, and the form answers identically whether or not that address exists, so nobody can use it to find out who buys from you.
A queue of live orders with a status machine that refuses illegal moves rather than trusting a button to be disabled, short supply that can only reduce a quantity and only with a reason the buyer is told, dispatch stamped once and never re-stamped, and every move written to an audit log. Over a credit limit flags an order for review; it does not refuse it.
Not every customer will use a portal, and the ones who text a list at 6am are often the best ones. Staff paste the message, or a photograph of a handwritten list, and a model reads it into lines. The format it answers in has no price field, so there is nowhere for an invented price to land. Each line is then matched to your catalogue by a filter, not a similarity score: an exact match is filled in, anything ambiguous is offered as a choice, and nothing is picked for a person. A word in the customer’s own language can map to the English name on your shelf, so “zeytin” finds the olives, and the finished order goes through the same repricing and checks as one placed in the portal.
With Xero, prices and stock come in on a schedule, and a sent order becomes a draft invoice in Xero within five minutes for your staff to approve, so nobody retypes an order. A price changed in the staff console is written to the Xero item, not to a second copy that could drift. And the portal never refuses an order because Xero is unreachable: the order places and confirms, and the sync failure waits on a staff screen.
This is Salix Trade, the ordering portal built for New Zealand food wholesalers.
Your whole range goes online, with photographs, categories and search, so a customer can find anything you sell. And the public never sees a single price. Every product invites a business to open a trade account instead. Approved customers sign in with a link sent to their email, or with a password if they prefer.
Once they are in, they see their own prices on everything they can buy. They search, set a quantity and add it to the order in a couple of minutes, at six in the morning if they like. When they send it, every line is priced again against today’s list, so nobody is charged a stale price.
Some customers will always send a WhatsApp instead. Your staff paste the message in, exactly as it arrived, and it is read into order lines, each matched to your catalogue. Anything uncertain is left for a person to choose, and even the customer’s own words work: zeytin finds your olives.
Everything stays in step with Xero. Prices and stock come in, and each order goes out as a draft invoice for your team to approve.
And your prices cannot leak. They are not hidden on the page; they are simply not there, and the whole site is checked every night to prove it.
Salix Trade runs on one engine that we look after for every wholesaler, with your own database, your own brand and your own domain. Grand Bazaar in Auckland runs on it today. See how it would work for you at salixtech.co.nz.
Migration off whatever you have now is part of the build, not an extra line on the invoice. Products, categories and images come across, and the old addresses keep working. A wholesaler's customers have deep links to their regular products saved, and a rebuild that quietly breaks them costs you orders from the people least likely to ring up and complain.
If your catalogue is thin on photographs or descriptions, we will count it and tell you before we design around it, rather than shipping a grid of blank tiles and calling the gap a content task afterwards.
This is a single engagement: Grand Bazaar Ltd, a Turkish and Mediterranean food importer in Henderson, Auckland, live since September 2026. It is described by what was built and measured, not by what it is claimed to have achieved.
Trade catalogue and account-gated ordering portal for a Turkish and Mediterranean food importer supplying dairies, restaurants, cafés and grocers across Auckland. 979 products are public; the wholesale price list is readable only by a signed-in, approved buyer, and Xero holds the prices, the stock and the invoices.
The migration moved 559 products, their categories and 306 distinct images into a purpose-built system, re-encoded from 107.9 MB to 18.2 MB, with 618 old URLs mapped so nothing a customer had bookmarked or Google had indexed went dark. Then measuring the accounting system found it held far more that was sold and priced than the website listed, and the sync now creates those products: the catalogue stands at 979. The source was counted before anything was designed around it, so the pages degrade to typography where a photograph or a description is missing instead of rendering blank frames.
Nine automated checks, wired to run on every push and again each night against the deployed site, and a red result stops the release. Most of them prove the gate shuts: the price schema answers 404 rather than an empty list, an account still under review sees nothing, no money-shaped string appears anywhere in the public HTML, no price identifier survives into the shipped JavaScript, and every email template is rendered and searched because email is gated by none of the database layers. One of them proves it opens, because a policy tight enough to refuse everybody is not security, it is a broken product.
Two tabs pressing Send serialise on a row lock. A resubmitted order is refused by the database rather than by a disabled button. Line prices freeze at the moment of submit, so what a buyer was charged in March does not move because the list changed in April, and GST is computed once on the total rather than per line and summed, because rounding twice produces a number that does not match the invoice. Each of those was verified end to end against fixtures before it was written down.
What is not claimed here is an outcome. One portal is not a sample, nothing has been measured against a before, and any figure we printed about orders won or errors avoided would be invented. What is above is what was built and what was checked.
The full case study goes through it a piece at a time: how the catalogue decides what is orderable, why stock is a status and never a number, what happens between a buyer pressing send and an invoice existing, and where the Xero integration refuses to act.
Salix built our trade website and ordering portal for Grand Bazaar, making it much easier for our customers across Auckland, including dairies, cafés and restaurants, to order from us.
Customers can see our full range, log in to view their trade prices, place orders themselves and quickly reorder their regular items. Orders go straight into Xero, which saves us a lot of time and admin.
Vakkas has also been great to deal with. He is always quick to respond and is happy to make changes or improvements whenever we need them.
We are really happy with the system and would definitely recommend Salix to other wholesale businesses looking for a reliable local tech partner.
One fixed price you can commit to this week, and a band for the build so a purchasing manager knows whether to keep reading. The quote comes out of the audit, not out of a phone call.
Fixed price, three days, credited in full against the build if you go ahead. No GST: Salix Limited is not GST-registered.
NZD, quoted out of The Ledger rather than off this page. No GST: Salix Limited is not GST-registered.
Platform & security: required for as long as the portal is hosted with us. No GST: Salix Limited is not GST-registered.
The order runs audit, then build, then platform. The $1,500 is credited in full against the build, so going ahead costs you nothing extra for having looked first, and the platform fee starts when the portal goes live, not before.
Because hiding them is not what this does. We have seen a trade site hide its prices in the front end and serve the entire wholesale list, unauthenticated, as JSON from an endpoint nobody had thought about, and that is the ordinary way this fails, not an exotic one. A price hidden by the presentation layer is not hidden. So the protection here is four independent layers and three of them sit in the database: the public product table has no price column to leak, the schema that does hold prices is not exposed to the API at all, and the grants are revoked rather than merely filtered by a policy, so a careless future change lands closed instead of open. The fourth is that public pages ship no database key to the browser whatsoever. Then an automated suite tests the output rather than the intent, including crawling every public URL with no cookies and searching the returned HTML for anything money-shaped, which is the check that would have caught the failure described above.
Because it is three days of work and it produces something worth having on its own. You get your price tiers read properly, a count of what your catalogue actually contains rather than what you assume it contains, a written note of what your current system exposes today, and a scope and estimate you keep. If you go ahead, the $1,500 comes off the build. If you do not, you still have the document, and an honest “you do not need to replace this yet” is a legitimate result. Free scoping is not free; it is paid for out of the next quote, and it is why the people who offer it can rarely afford to tell you not to buy.
No. It is the normal starting point, and it is close to the shape the system wants anyway. Price is held per account rather than per product, so a tier is just a set of accounts pointed at the same list, and minimum order quantities live on the same rows. What matters more than the spreadsheet is which system you want to own the numbers from here on. Our strong preference is that your accounting package keeps owning them and the portal reads them, because two places to edit a price is two prices.
The order is accepted and flagged for someone to look at. It is not refused. A distributor does not want its website turning away a dairy at 6am over a limit the office would have waved through at nine, and an order you never received is worse than one you have to make a decision about. Where the limit belongs is on your screen, next to the order, before it is picked.
With Xero it already does, for a live distributor: prices and stock in on a schedule, sent orders out as draft invoices for your staff to approve. Any other system is scoped and priced as a phase of its own rather than as a checkbox, because this is the part that goes wrong quietly. The rules we hold are that the sync is one-directional (the accounting system owns money and stock, the portal owns the catalogue and the orders in flight), and that an order can never be invoiced twice, which needs more than a retry that hopes for the best. Equally important and more often missed: the website must never refuse an order because the accounting system is unreachable. Orders place and confirm regardless, and the sync failure surfaces on a staff screen instead of in front of a customer.
They can share the code. They will not share a database, and that is not a preference we will trade away on price. Three of the four price protections above are database-level and hold precisely because the database contains one business. Add a second and they degrade into an application-level filter, where one missing line of code hands your prices to a competitor who is also a customer. Two wholesale distributors in one category are rivals in a way two takeaway shops are not, so the blast radius gets worse at exactly the moment the safeguard gets weaker. One business, one database.
No, and that is the point. The ordering engine is one piece of software, maintained once and running for every wholesaler on it, so a fix or a new safeguard reaches your portal the day it ships for anyone. What is yours is your own: your database, your brand, your copy, your domain and your customers, set up for you and never shared. You pay for the setup and a monthly platform fee, not for a codebase that only you keep alive.
The audit is three days and they are booked before it starts. We are not going to print a build duration on this page, because the honest answer depends on how much of your catalogue has photographs, how many customer tiers you really have as opposed to how many you think you have, and whether the accounting integration is in scope. That is precisely what the three days are for, and the estimate that comes out of them is one you can hold us to.
Still deciding? Read the guide: Is your wholesale price list really hidden? A 10-minute check for trade websites
We read every enquiry ourselves and reply within two working days. Quick chats, long briefs, half-formed ideas: all welcome.
WhatsApp, phone, a rep with a notebook, an email inbox somebody has to retype: whatever it is, that is the useful starting point, along with how many price tiers you run and roughly how many products are on the list. We will reply with a straight answer on whether The Ledger is worth your $1,500 yet, including if it is not.