From the outside a wholesale store barely differs from a retail one: the same catalogue, the same product cards, a «buy» button. The difference starts right after that button. The price depends on who logged in. The quantity is limited by the case. The order is closed with an invoice rather than a receipt. And the catalogue is browsed not by a shopper making up their mind, but by a buyer who already knows the part number.
On 31 July 2026 we measured seven wholesale catalogues — from 1,656 URLs in the medical one to 13,590 in the underwear one. Below are six places where B2B logic diverges from retail, and what the measurements found inside.
The price depends on who logged in
In retail there is one price for everyone, and that is the simplest part of a store. In wholesale the same product has several: a base price for a walk-in visitor, a dealer price, a separate one for a key account that takes volume every month. As long as this lives in Excel, it lives badly: the file was forwarded, the price went stale, the client argues, and the manager digs for the version of the price list sent last time.
On OpenCart this is a built-in mechanism — customer groups and price tiers. The client logs in and sees their own column, a retail visitor sees the base one. There is a single source of prices, and it is updated by a price list import, not by correspondence.
The other half of this point is registration. Wholesale prices are not shown to a random visitor, so the registration form does not grant access by itself: the request goes to moderation and a manager confirms this is really a buyer. It gets hard where the price depends on the group, the order volume and the product category at the same time. That is already separate pricing logic, described in the specification and checked combination by combination.
The quantity is limited by the case
A retail customer takes one unit. A wholesale customer takes a case of twelve, a pallet or a minimum batch — and any order for seven units goes back to a manager for manual approval. That is the most expensive way of taking orders there is.
Pack multiplicity is set at product level, and the cart refuses a quantity that is not a multiple of it. The same goes for the minimum batch and the minimum order value. A detail that is easy to miss and expensive to fix later: the button has to explain why it is disabled. A «place order» that does nothing reads as a broken site; «add 4 more — this item ships in cases of 12» reads as a rule.
In one of the measured catalogues — a wholesale building materials store with 3,145 items — there is also calculation by pallets and volume: the selling unit does not match the storage unit, and the coefficient belongs in the system rather than in the manager's head.
Orders are typed as a list, not clicked together
A buyer arrives with a ready list: thirty part numbers and quantities. The retail scenario — find the item, open the card, add to cart, go back — turns into half an hour of clicking on thirty positions. That is why wholesale needs a quick order form: part number and quantity, pasted as a list, with the cart assembled in one move.
The second half of the same thing is repeating a previous order from the account area. The client opens the last order, removes what is not needed, adds something new and checks out. There is an honest limit here: an account area only makes sense where people actually come back. If your client orders once a quarter, it will sit empty — and that is around seven working days of work. You know your repeat-order frequency, we do not, and it is what decides whether this is worth building.
Payment is closed with a document
A retail customer needs a receipt. A company needs a document: an invoice with a number and full legal details, a bank transfer to an IBAN, different terms for a sole trader and for a VAT payer. If a manager produces all of that by hand in the accounting system, every order costs several minutes of someone else's time.
An invoice generated from the order itself is the simplest mechanism that removes the most routine: details, number, line items and totals are filled in automatically. In the measured catalogues this kind of payment is the norm. The wholesale underwear store has eight payment methods, an invoice among them, and they are exposed both in the page text and in the structured data. The B2B catalogue of industrial sewing machine parts offers a VAT-free bank transfer to a sole trader account and payment after collecting the goods at the carrier's warehouse.
The list of documents the site closes instead of a manager is one of the two things that define the scope of work. The other is the number of price tiers. How a figure is built from those two numbers is covered separately: how much an online store costs.
Prices and stock are driven by the accounting system
In wholesale, selling something that is not in stock costs more than it does in retail: the client took the item to resell, promised it to their own customer, and it never arrived. So stock levels on the site have to come from the database instead of being updated by hand.
A one-way price list import is the basic part of the work: prices and stock are refreshed on a schedule you set. Two-way exchange with 1C or BAS is separate work of about ten working days, because synchronisation runs both ways: stock and prices to the site, order statuses back into the database. It starts not with a verbal description but with a real export file — the description and the actual contents of a database diverge almost every time.
One limit worth naming straight away: synchronisation cannot be verified from the outside. We can measure someone's catalogue and speed, but not whether stock levels really arrive there every night.
The catalogue is built for picking, not for browsing
A retail catalogue walks a person from a category to a product. A wholesale one has to bring them to the exact item in as few steps as possible, and the scenarios differ by niche.
In the wholesale underwear store it is selection by sizes and colours inside a model: the buyer assembles the range on one product card instead of walking through forty pages. That catalogue holds 13,428 product pages. In the sewing machine parts catalogue it is finding a part by code or by equipment model, because a mistake in selection costs production downtime. At the building materials supplier it is calculation by volume and pallets. In the B2B catalogue of chocolate production equipment with 106 items there is no cart at all: there is a quotation request form, because a tempering machine is not bought in one click.
The same section covers what happens after checkout: delivery tariff zoning, where delivery to the next district and delivery to a village sixty kilometres off the highway cost you differently, and split shipments, where part of the order is with you and part is at a supplier's warehouse.
What seven measured wholesale catalogues showed
The measurements of 31 July 2026 produced a few observations you cannot get from a project description.
Size alone does not make a site slow. The first server response on catalogues from 1.6 to 13.6 thousand URLs ranged from 289 to 576.8 milliseconds. The fastest response belonged to the largest catalogue.
A tidy sitemap is a minority habit. The underwear one has 13,590 URLs and exactly one duplicate — 0.007%. Next to it in the sample sits a cosmetics catalogue where an old sitemap still lives in parallel: 7,782 entries for 2,755 unique URLs, and not a single URL of the second language version in it. The bilingual version exists, and for search it does not.
Analytics dies quietly. In a B2B catalogue with 1,848 items the code still carries Universal Analytics and there is no GA4 property at all. Data has not been collected since July 2023, and the owner does not know, because the site itself works.
Page weight does not follow catalogue size. The heaviest document in the sample is 751.2 KB on the home page of a store with 13 thousand items; a catalogue with 1,848 items serves 120.2 KB. The difference is in how the page is built, not in how much product it holds.
What a wholesale store will not do
It will not replace the manager. Agreeing on a batch, deferred payment, a disputed price, a defect claim — those stay with people. The site removes the routine: the invoice, the repeat order, stock levels, order status.
It will not pull the price list out of messengers overnight. Some buyers have worked by phone for years and will send a list on Viber even when everything is on the site. The realistic outcome is not «everyone moved to the site» but «some clients order on their own, and that is the part the manager no longer handles by hand».
In search a wholesale store is needed differently from a retail one. A buyer looks for a part number, a category and the words «opt» or «hurt», often together with a brand name — not for «buy cheap». The technical part is the same either way: clean URLs, canonicals, unique titles, a sitemap without duplicates, structured data. That is exactly where the measured catalogues have the most holes.
Where to start
Development of a wholesale store takes 30–55 working days from the approved specification; a retail store on the same engine takes 25–45, and what stretches those timelines is covered separately. The longest stage in wholesale is the build: every combination of customer group and price has to be checked on a live order.
It all starts with a free review of your commercial scheme: how many price tiers you have, which documents the manager produces by hand, where stock levels come from. That takes 1–3 working days, and an estimate broken down by stage follows. Then a written contract with a fixed amount and a 30 calendar day warranty from the date the acceptance act is signed.
