Hidden Prices and Quote Requests in B2B: How Price Masking Actually Works
Why hide a price instead of showing it
In B2B, hiding a price and replacing the buy button with a "request a quote" button answers real, distinct needs that often get lumped into a single setting: protecting a negotiated price list that competitors could scrape automatically, forcing a qualified contact before selling products whose price depends on volume or configuration, or simply reserving an entire catalog segment (a trade range, a reseller price tier) for verified B2B accounts only. These are three different goals, and the same "hide price" toggle does not always serve them equally well: the first genuinely needs technical masking, the second mostly needs a different button, the third needs a precise scope by customer group, not a single on/off switch.
What a "hidden" price actually hides, and what it does not
The most common way to hide a price on a product page is visually, with a CSS rule (display: none) on the price block, driven by a class added server side once the hiding condition is met. This is a legitimate, widely used method, but it has a technical consequence worth understanding before choosing it: the price stays present in the page's source code, it is simply not rendered on screen. Anyone viewing the page source, running a misconfigured screen reader, or running a basic scraping script can still retrieve that price, even though it never appears on screen for a normal visitor.
That is not necessarily a flaw to fix at all costs: for the goal of "stop a casual competitor from visually comparing prices", visual hiding is entirely sufficient, most competitors never go as far as reading page source. For the goal of "stop systematic automated scraping of the entire price list", visual hiding alone is not enough: you either need to never send the price to the browser for the visitors in question (which requires different template-level logic, not just a CSS class), or you accept that the real protection comes from somewhere else entirely (authentication, rate limiting, bot detection), not from visual masking itself. The right choice depends on what you are actually trying to stop, not on a generic "hide prices" checkbox.
The part that matters most: where the negotiated price gets calculated
Once a B2B customer has received a quote with a price negotiated line by line, the most important technical question is not how the price was hidden in the first place, it is how that negotiated price gets applied at order time. A properly built quote system calculates and applies that price server side, typically through a cart rule generated and tied to the accepted quote, never from a value submitted by the browser's own form. The reason is simple: anything calculated or transmitted client side can be altered by a sufficiently motivated customer before the request is even sent. A negotiated price that existed only as a hidden field in an HTML page would be just as editable as a price displayed in plain sight, with the added illusion of being protected because it is not visible. An "accept the quote, then order" flow therefore has to verify and reapply the negotiated price at every server-side step, not only at the moment the quote was generated.
The scope of masking: everything, a category, a group, a product
Hiding prices across the entire catalog works for a purely B2B site, where no unidentified visitor has any reason to see a price at all. A mixed B2B/B2C site generally needs a narrower scope: hiding only a professional category, or only for customer groups that are not yet verified, leaving the rest of the catalog with normal, visible prices. Getting the scope wrong has a real cost on both sides: hiding too broadly turns B2C visitors who were ready to buy immediately into visitors forced to request a quote for a product whose price was never confidential in the first place, which hurts conversion for no benefit at all; hiding too little leaves exactly the price list you were trying to protect out in the open.
An SEO trap that is easy to miss: the price stays in structured data
A PrestaShop product page generally exposes a price in its structured data (schema.org, the offers block) so search engines can show a price in rich results. Hiding the price visually on the page without also removing or adapting that structured data leaves a price, potentially stale the moment it changes, visible directly in search results, outside any page a visitor actually opens. This is one of the most common blind spots in a quickly rolled-out price masking setup: the visual toggle is done, but the structured data feeding Google never got the memo.
In short
Hiding a price and offering a quote instead answers real B2B needs, but "hide the price" is not a single action: visual masking protects against a casual competitor, not against systematic scraping; the negotiated price calculation always has to happen server side, never inside the browser's own form; the scope of masking (everything, category, group, product) decides whether the setting protects the right audience or hurts conversion for the wrong one; and the page's structured data deserves a separate check, since it does not automatically follow a visual toggle. On PrestaShop, a module such as cll_quotes handles this flow (quote button, scoped price hiding, negotiated price applied server side via a cart rule), but the principles above hold regardless of which tool you pick.
Module installation and configuration guide
Quote Requests - B2B quotes & hide pricesLet customers request a quote instead of buying: optional price hiding, BO quote manager with agreed prices…€89.99View product