Hiding Prices with a 'Learn Price' Button: Architecture and Implementation
A wholesale customer enters your catalog, sees the retail price, and leaves — thinking it's too expensive. Or a competitor monitors your prices via a parser. Hiding prices with a 'Learn Price' button solves both problems: the B2B client submits a request, and the parser gets an empty field instead of a number.
Our team configured hidden prices for a project with 15,000+ products and 4 dealer types. The approach turned out not to be trivial — we had to combine price type permissions, infoblock properties, and a custom request form. Below we share the architecture and guarantee that the solution will fit into your catalog in as little as 2 hours.
How Prices Are Stored in 1C-Bitrix
The product price resides in the b_catalog_price table, linked to a price type (b_catalog_group). The catalog.element component uses CCatalogProduct::GetOptimalPrice() — it selects the available price type for the current user. If no price type is allowed, the method returns an empty array. This is the hook point for hiding.
Levels of Price Hiding
-
Component template level. The simplest: in
template.phpyou check a condition and output a button instead of the price. Conditions: user group, infoblock propertyHIDE_PRICE, presence of a specific price type. -
Price type level. Create a separate price type 'On Request' in Store → Settings → Price Types. For products with hidden prices, do not assign a retail price.
CCatalogProduct::GetOptimalPrice()finds no price — handle it in the template. -
Infoblock property level. Add a
PRICE_ON_REQUESTproperty of type 'List' (Yes/No). In the template check the property value and replace the price block with a request form. This method is convenient for bulk management via CommerceML.
Implementing the 'Learn Price' Button
The button should open a form with a minimum of fields: name, phone/email, and an automatically inserted product SKU. Main options:
| Option | Implementation Speed | Additional Features |
|---|---|---|
bitrix:form.result.new |
2–3 hours | Ready-made templates, event model |
| BX.SidePanel | 4–6 hours | Doesn't leave the page, can embed CRM form |
| AJAX request | 3–5 hours | Minimal form, full control over design |
The request must land in CRM (if Bitrix24) or be sent to a manager's email. For CRM use crm.lead.add via REST API or the OnAfterResultAdd web form event with a lead creation handler. In one project, via the event we created not only a lead but also a deal linked to the product using crm.item.add — clients received an offer with the actual hidden price.
Why It Is Important to Check the Cart?
If the price is hidden on the product page but the product can be added to the cart and checked out, the hiding loses its purpose. You need to override CatalogBasketProvider or check the price in OnBeforeBasketAdd. This is a common mistake: they forget to configure the cart, and clients see the price only at checkout.
How to Organize Bulk Update of the Hiding Flag?
For catalogs of 1000+ products, use the infoblock property PRICE_ON_REQUEST and import via CSV or 1C exchange (CommerceML). We write an agent script that iterates through all products and sets the flag in 1–2 days. Group setting via infoblock API is also possible.
Hiding Prices by User Groups
For a B2B scenario: authorized dealers see the price, guests see the request button. Check via $USER->GetUserGroupArray() in the component template. Or via price type permissions — in the price type settings specify which user groups have access. The CCatalogGroup::GetGroupsList() method returns the allowed groups.
| Scenario | Approach | Setup Time |
|---|---|---|
| Hide for all, 'Learn Price' button | Infoblock property + template modification | 2–4 hours |
| Hide for guests, show for dealers | Price type permissions + group check | 4–6 hours |
| Bulk management (1000+ products) | Property + CSV/1C import | 1–2 days |
How We Configured Price Hiding in a Project with 4 Dealer Levels
A concrete case: an auto parts e‑commerce store. 4 dealer groups, each with its own price for the same product. The retail price was shown only to guest users; dealers saw their group price. The challenge: hide the retail price for both guests and dealers because the supplier prohibited publishing prices.
Solution: we created an 'On Request' price type with no group bindings. All products were assigned this price type with zero value. In the catalog.element template we added a check: if the price type is 'On Request' and the price equals 0, then display the 'Learn Price' button. For dealers — an additional check: if the user is in a dealer group, instead of the button show their price (stored in a separate infoblock property). The form was implemented via BX.SidePanel with a bitrix:form.result.new form. Requests go to leads via REST; the manager sees the product and the client's group and can respond immediately.
Most Common Mistakes
- Forgetting to set price type permissions — then
GetOptimalPrice()may return another available price, and hiding won't work. - Not checking for an empty price — the 'Learn Price' button is shown even if the price actually exists (equals 0).
- Ignoring the cart — if the price is hidden but the product can be added to the cart and checked out, hiding is pointless.
Price Type Access Permissions
The `CCatalogGroup::GetGroupsList()` method returns an array of allowed groups for each price type. If no group is specified, the price is visible to everyone. Ensure that for the hidden price type no exception groups are set.What Is Included in the Hidden Price Setup
- Analysis of the current catalog structure and price types.
- Design of display logic (by groups, properties, conditions).
- Implementation of the component template with button and form.
- CRM integration (leads/deals).
- Testing on 10+ scenarios (guest, dealer, parser).
- Documentation for further management.
We'll evaluate your project in 1 business day. Contact us — we'll prepare a detailed work plan and timeline.