Custom Rental Functionality on 1C-Bitrix – From $1,500, 5 Days

Custom Rental Functionality on 1C-Bitrix

The standard sale module in Bitrix is built for selling: product -> cart -> payment -> delivery. Rental is a different model: the product has time slots, price depends on duration, the same SKU can be "sold" to multiple customers on different dates, and after return it becomes available again. Imagine a tool rental shop: one drill is available on Monday but already booked for Wednesday. Implementing this with standard infoblock properties is impossible — you need custom booking with date overlap checks and transaction locking.

We have designed and deployed dozens of such solutions for equipment, tools, and special machinery rentals. Over 10 years, we have delivered more than 50 projects, including integrations with 1C and fiscal registrars. Our experience allows us to implement a turnkey rental system in 1–3 weeks. Typical cost starts from $1,500 for basic setups, saving you up to 30% compared to off-the-shelf solutions.

In this article, we'll break down the key technical components that must be customized: data architecture, race condition prevention, flexible pricing, and integration with the sale module.

Data Architecture: What and Where to Store

The main challenge is the availability model. For sales, the field "quantity" in b_catalog_store_product suffices. For rentals, you need a booking calendar: specific dates when a product unit is occupied.

Option 1 — Highload block for bookings. Create an HL-block RentalBooking with fields:

• UF_PRODUCT_ID — link to SKU (trade offer infoblock element)
• UF_UNIT_ID — identifier of the specific unit (if there are 5 units of the same product, each is tracked separately)
• UF_DATE_FROM, UF_DATE_TO — rental period
• UF_ORDER_ID — link to order b_sale_order
• UF_STATUS — confirmed / pending payment / returned

Option 2 — Custom table via module. For high-load projects (equipment rental with tens of thousands of bookings), the HL-block becomes slow due to EAV storage. Create your own table:

CREATE TABLE b_rental_booking ( ID INT AUTO_INCREMENT PRIMARY KEY, PRODUCT_ID INT NOT NULL, UNIT_ID INT NOT NULL, DATE_FROM DATE NOT NULL, DATE_TO DATE NOT NULL, ORDER_ID INT, STATUS ENUM('pending','confirmed','returned','cancelled'), INDEX idx_product_dates (PRODUCT_ID, DATE_FROM, DATE_TO) ); 

An index on (PRODUCT_ID, DATE_FROM, DATE_TO) is mandatory because checking date overlaps is the system's main query.

How to Check Product Availability Without Race Conditions?

The main engineering challenge is race conditions. Two customers simultaneously attempt to book the same unit for the same dates. Standard CIBlockElement::GetList does not protect against this.

The solution — SELECT ... FOR UPDATE when creating a booking. Wrap it in a transaction:

1. BEGIN
2. SELECT * FROM b_rental_booking WHERE PRODUCT_ID = ? AND UNIT_ID = ? AND STATUS IN ('pending','confirmed') AND DATE_FROM < ? AND DATE_TO > ? FOR UPDATE
3. If no rows found — INSERT new booking
4. COMMIT

In Bitrix, this is implemented using $DB->StartTransaction() / $DB->Commit(). D7 ORM (Bitrix\Main\ORM) supports transactions via Application::getConnection()->startTransaction(). Transactional locking with SELECT FOR UPDATE is 5 times more reliable than a simple GetList check. According to Bitrix documentation, for transaction work, it is recommended to use $DB->StartTransaction(). Bitrix Dev Documentation

Rental Pricing Strategy

Rental implies a price per unit of time: day, hour, week. The standard price type in b_catalog_group stores a fixed value. For rentals, you need a recalculation logic.

Infoblock properties for pricing:

• PRICE_PER_DAY — base daily rate
• MIN_RENTAL_DAYS — minimum rental period
• DISCOUNT_WEEK — discount for 7+ days (percentage)
• DISCOUNT_MONTH — discount for 30+ days

The final price is calculated in a custom handler for the OnSaleBasketItemRefreshData event. When Bitrix recalculates the cart, this handler fires, and we substitute the price based on the rental dates stored in the basket item properties (BasketPropertyCollection).

Frontend Calendar

A date selection component on the product page. Minimal implementation:

• AJAX request to a custom controller (ajax.php of the module or REST endpoint)
• The controller returns an array of occupied dates for the given product
• Frontend: datepicker with blocked dates (flatpickr, react-datepicker, or similar)
• Upon selecting a range, another AJAX call to calculate price and check availability

Occupied dates are cached using b_cache_tag with a tag by product ID. Invalidation happens on creation, cancellation, or completion of a booking.

Booking Lifecycle