Cart Configuration for 1C-Bitrix E-Commerce
Cart in 1C-Bitrix is not just a product list. It's \Bitrix\Sale\Basket object, connected to orders, discounts, delivery rules, and user session. Proper cart configuration directly impacts conversion: from mini-cart load speed to login merge logic. Let's examine key mechanics, discount rules, and cross-sell techniques.
sale.basket.basket Component
Standard sale.basket.basket component handles full cart page. Its parameters set behavior:
- COLUMNS_LIST — which columns to display (image, name, quantity, price, remove).
- HIDE_COUPON — hide coupon field if promo isn't used.
- QUANTITY_FLOAT — allow fractional quantity (for weight-based products).
- PRICE_VAT_SHOW_VALUE — show VAT as separate line.
- AUTO_CALCULATION — recalculate cart on every quantity change without page reload.
Component works via AJAX: on quantity change, request is sent to \Bitrix\Sale\Compatible\BasketCompatibility or directly to \Bitrix\Sale\Basket::refresh(), discounts are recalculated, total updates.
Deferred items — built-in cart feature. Product with DELAY = Y property doesn't participate in cost and delivery calculation, but remains in b_sale_basket. Switching between deferred and active state is done via \Bitrix\Sale\BasketItem::setField('DELAY', 'Y').
Mini-Cart
Mini-cart (sale.basket.basket.line) usually placed in site header. Shows product count and sum. Main issue — performance. Component by default queries database on every hit. On high-load projects this is solved by:
- Client-side caching — cart data saved in
localStorageand updated only on user actions. - Deferred AJAX loading after page load (
lazy load). - Using
composite cachewith cart block excluded via\Bitrix\Main\Page\Frame.
Cart Discount Rules
Discounts in Bitrix divided into catalog discounts (applied to product before cart) and cart rules (sale.discount). Cart rules are powerful tool working at order level.
Cart rule consists of conditions and actions:
Conditions — what must happen:
- Cart sum more than N.
- Cart contains product from section X.
- Quantity of product with property Y more than Z.
- Coupon activated.
- User belongs to group W.
Actions — what happens on condition fulfillment:
- N% discount on entire order.
- Discount on specific product or section.
- Gift (adding product with zero price).
- Free delivery (via
DELIVERY_DISCOUNTflag).
Order of discount application set via priorities. Discounts with same priority apply together; with different — sequentially, each next calculated from already discounted price. "Stop application" flag stops chain — useful for exclusive promotions.
Common mistake — catalog and cart discount conflict. By default Bitrix doesn't sum them: if product already has catalog discount, cart rule may not apply. Behavior set in sale module settings → Discount Recalculation Type.
Cross-Sells in Cart
Cross-sells on cart page increase average check. Bitrix implements them several ways:
Via product property "Related Products" — bindings at iblock level. catalog.recommended.products component outputs them near cart. Simple to configure, but requires manual link filling.
Via automatic recommendations — bigdata module (Personalization) analyzes user behavior and picks products via collaborative filtering. Configured in Marketing → Personalization section. Works only with sufficient data (minimum thousands of orders).
Via cart rules with gift — create rule: "on purchase from section A — offer product from section B with 50% discount". User sees offer right in cart and can accept with one click.
For maximum effectiveness, cross-sells are combined: automatic recommendations for bulk products and manual links for high-margin items.
Cart Merge on Login
When unauthorized user adds products to cart, they're bound to FUSER_ID — anonymous ID from cookie. After login Bitrix calls \Bitrix\Sale\Fuser::getIdByUserId() and performs merge:
- Products from anonymous cart transferred to user cart.
- If product exists in both carts — quantity is summed.
- Discounts recalculated for merged cart.
Merge happens automatically via OnAfterUserLogin event handler. Problems arise when custom auth (SSO, external OAuth) bypasses standard mechanism. In that case, explicitly call \Bitrix\Sale\Fuser::update() to merge identifiers.
Checkout Steps Configuration
Transition from cart to checkout is controlled by sale.order.ajax component. Can be configured for step-by-step checkout (separate pages for delivery, payment, confirmation) or one-page (all-in-one). Practice shows one-page checkout gives 15-20% higher conversion, but requires more client-side validation work.
Key parameters: DELIVERY_TO_PAYSYSTEM — link delivery services to payment systems, SHOW_NOT_CALCULATED_DELIVERIES — show deliveries for which cost couldn't be calculated.