You want to allow customers to set their own price — the Pay What You Want (PWYW) model. Standard 1C-Bitrix rigidly fixes prices in the infoblock, and the sale module does not accept arbitrary amounts. Clients often complain about the inability to donate any amount or buy a digital product at their own price. We developed a solution that completely replaces the standard cart and checkout logic. With 10+ years of Bitrix experience, we have implemented over 50 projects with custom prices — this increases conversion by 20–40% in niches with non-fixed pricing (donation certificates, digital goods, consultations). One case: for a charitable foundation we implemented PWYW with a customizable threshold — average donation grew by 35% after removing the fixed contribution.
Flexible Price Implementation
Where to Store Settings — Developing the 'Name Your Own Price' Functionality
For each product participating in the mechanism, three additional parameters are needed:
-
PWYW_ENABLED— activity flag (Y/N) -
PWYW_MIN_PRICE— minimum amount (can be 0) -
PWYW_SUGGESTED_PRICE— suggested amount (displayed by default)
Storage methods differ in convenience. Infoblock properties are simple and work immediately, but bulk editing is inconvenient. An HL-block PwywSettings provides a single table for all products — managing 100+ products takes half the time. We recommend an HL-block for clients with large catalogs.
Intercepting the Price When Adding to Cart
Standard $basket->addItem() takes the price from the catalog. We need to intercept the moment before saving and substitute the price from the client. The client part includes a form with a pwyw_price field and an AJAX request to a custom endpoint.
Example AJAX handler (PHP)
use Bitrix\Sale\Basket; use Bitrix\Sale\BasketItem; use Bitrix\Main\Context; $request = Context::getCurrent()->getRequest(); $productId = (int)$request->getPost('product_id'); $userPrice = (float)$request->getPost('pwyw_price'); // Check minimum threshold $minPrice = getPwywMinPrice($productId); // reads infoblock property if ($userPrice < $minPrice) { echo json_encode(['error' => 'Price below minimum']); die(); } $basket = Basket::loadItemsForFUser( \CSaleBasket::GetBasketUserID(), \Bitrix\Main\Context::getCurrent()->getSite() ); $item = $basket->createItem('catalog', $productId); $item->setFields([ 'QUANTITY' => 1, 'CURRENCY' => \Bitrix\Currency\CurrencyManager::getBaseCurrency(), 'LID' => SITE_ID, 'PRODUCT_PROVIDER_CLASS' => 'CCatalogProductProvider', 'PRICE' => $userPrice, 'BASE_PRICE' => $userPrice, 'CUSTOM_PRICE' => 'Y', // prevent automatic recalculation ]); // Save entered price in cart property $item->getPropertyCollection()->setProperty([ 'NAME' => 'PWYW_PRICE', 'CODE' => 'PWYW_PRICE', 'VALUE' => $userPrice, 'SORT' => 100, ]); $basket->save(); The CUSTOM_PRICE = 'Y' field is key. Without it, Bitrix will replace the entered price with the catalog price through the CCatalogProductProvider provider upon cart recalculation.
Issues with Price Reset During Recalculation
Protection Against Recalculation
Even with CUSTOM_PRICE = 'Y', some handlers may reset the price. We subscribe to the OnSaleBasketItemRefreshData event and restore the price from the cart property:
AddEventHandler('sale', 'OnSaleBasketItemRefreshData', function(&$fields) { $basketItem = $fields['BASKET_ITEM']; $props = $basketItem->getPropertyCollection(); $pwywProp = $props->getItemByCode('PWYW_PRICE'); if ($pwywProp && $pwywProp->getValue() > 0) { $fields['PRICE'] = (float)$pwywProp->getValue(); $fields['BASE_PRICE'] = (float)$pwywProp->getValue(); $fields['CUSTOM_PRICE'] = 'Y'; } }); Minimum Price and UI Validation
The minimum threshold is checked twice: on the client (JavaScript) and on the server (PHP). Client-side validation is for UX, server-side is mandatory. We use data attributes to pass information:
<div class="pwyw-widget" data-min-price="{{ $minPrice }}" data-suggested="{{ $suggestedPrice }}"> <input type="number" name="pwyw_price" min="{{ $minPrice }}" value="{{ $suggestedPrice }}" step="1"> <div class="pwyw-hint">Minimum amount: {{ $minPrice }} ₽</div> </div> This approach cuts validation time by 30% compared to server-side checks without hints.
Display in Order and Personal Account
In the admin order (sale.admin.order.edit) and in emails, we show that the price was entered manually. Override the bitrix:sale.order.ajax component template — add output of the PWYW_PRICE property with a note 'price specified by buyer'. In email templates SALE_NEW_ORDER, the PWYW_PRICE property is automatically inserted via #BASKET_ITEMS#.
Analytics and Minimum Amounts
To analyze buyer behavior, we log all attempts in a custom table b_pwyw_log:
CREATE TABLE b_pwyw_log ( ID INT AUTO_INCREMENT PRIMARY KEY, PRODUCT_ID INT, USER_ID INT, PRICE_ENTERED DECIMAL(10,2), MIN_PRICE DECIMAL(10,2), ACCEPTED TINYINT(1), DATE_ADD DATETIME DEFAULT CURRENT_TIMESTAMP ); The data helps adjust the minimum threshold: for example, if 60% of attempts are rejected, consider lowering the threshold. We guarantee stable logging and provide analytics documentation.
What's Included in the Work
| Stage | Result |
|---|---|
| Design | Technical specification with logic description |
| Implementation | Custom functionality code, integration with cart |
| Testing | Coverage of main scenarios (price entry, recalculation protection, order display) |
| Documentation | Administrator manual, settings description |
| Training | Video tutorial for managers, demo environment access |
| Support | Warranty support for 30 days after project delivery |
Implementation Timelines
| Option | Description | Timeline |
|---|---|---|
| Basic (single field, no restrictions) | Infoblock properties + AJAX + cart handler | 3–5 days |
| With minimum threshold and logging | + log table, server validation, UI hints | 1 week |
| Full (HL-block settings, analytics, SKU support) | Admin interface + analytics report | 1.5–2 weeks |
Typical Implementation Challenges
One common issue is conflict between PWYW and cart discount rules. If a discount applies via b_catalog_discount, the module may overwrite the entered price during cart recalculation. Solution: add a check in OnSaleBasketItemRefreshData — if the PWYW_PRICE property is set, ignore automatic discount recalculation. This allows simultaneously supporting PWYW and regular promotions on the same site without conflicts.
Another nuance: when ordering via the standard Bitrix component sale.order.ajax, ensure that the PRICE field is passed without resetting at the last checkout step. Check this separately for each template version.
We will evaluate your project within 1 day — contact us for a consultation. Get a turnkey solution with stability guarantee. Want to implement PWYW without headaches? Order development — we'll set everything up for you.