Setting up separate shopping carts for different 1C-Bitrix sites

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Configuring Separate Carts for Multiple Sites in 1C-Bitrix

A multisite setup with a shared catalog introduces a non-obvious problem: the cart in 1C-Bitrix is associated with a user by default, not with a site. A customer adds items on the retail site, then visits the wholesale site — and sees the same cart there. This is unacceptable when the sites have different prices, shipping rules, and customer types.

How the Cart Works in 1C-Bitrix

The cart is stored in the b_sale_basket table. Key fields:

SELECT id, fuser_id, site_id, product_id, quantity, price, currency
FROM b_sale_basket
WHERE fuser_id = 12345;

The SITE_ID field exists in the cart and 1C-Bitrix does use it. The problem is that fuser_id (fusion user — the anonymous user identifier) is tied to the BITRIX_SM_FUSER_ID cookie, which is shared across all subdomains unless configured otherwise.

Isolating Carts by Site

Method 1: separate domains without shared cookies. The most reliable approach. If sites operate on different domains (retail.shop.com and wholesale.shop.com) or different second-level domains, the fuser_id cookie is not shared between them automatically. In this case, 1C-Bitrix creates separate carts out of the box.

Verify the current configuration:

// /bitrix/php_interface/dbconn.php or .settings.php
// Check SESSION_DOMAIN — if the same for all sites, there is a problem
$_SESSION['BITRIX_SM_FUSER_ID']; // Same for all sites

Method 2: explicitly passing SITE_ID to the cart component. The bitrix:sale.basket.basket component accepts a SITE_ID parameter. Ensure it is passed correctly:

$APPLICATION->IncludeComponent('bitrix:sale.basket.basket', '.default', [
    'SITE_ID' => SITE_ID, // Current site ID
    'PRICE_VAT_SHOW_VALUE' => 'Y',
    // ...
]);

Method 3: programmatic separation via an event handler. If the architecture does not allow domain separation, subscribe to the cart item creation event and force the SITE_ID:

// /local/php_interface/init.php
AddEventHandler('sale', 'OnBeforeBasketItemAdd', 'SetBasketSiteId');

function SetBasketSiteId(&$arFields) {
    $currentSite = \Bitrix\Main\Context::getCurrent()->getSite();
    $arFields['SITE_ID'] = $currentSite;
    return true;
}

Cart Counter Display

The item count in the header is a typical place where separate carts break visually: the total count across all sites is shown. Fix it with an explicit filter:

use Bitrix\Sale\Basket;
use Bitrix\Main\Context;

$basket = Basket::loadItemsForFUser(
    \CSaleBasket::GetBasketUserID(),
    Context::getCurrent()->getSite() // Pass the current SITE_ID
);
$itemCount = $basket->count();

Timeline

Configuration Timeline
Diagnostics and separation setup (ready architecture) 0.5–1 day
Setup with programmatic separation 1–2 days
Template refactoring + testing 2–3 days