Платформы интернет-магазина: модели поставки и представители

TL;DR: любая платформа интернет-магазина относится к одной из четырёх моделей поставки: SaaS, коммерческая коробка, open-source self-hosted или custom-разработка. Модель определяет, кто владеет кодом и данными, кто отвечает за обновления и сколько стоит расширение; название платформы вторично по отношению к этим четырём различиям. Сценарий покупки при любом выборе описан в каталоге и checkout.

Почему модель поставки важнее названия

Критерии выбора из обзора контура распределяются по моделям поставки по-разному: SaaS решает срок запуска и обновления, но проигрывает по владению кодом; open-source решает владение, но переносит ответственность за безопасность и сопровождение на команду проекта. Сначала фиксируется модель, затем выбирается представитель внутри неё.

Модель 1. SaaS — магазин как услуга

Назначение. Магазин на инфраструктуре и коде поставщика, управляемый через тариф и кабинет. Срок до первой продажи — дни или недели, а не месяцы.

Представители:

Яндекс KIT — конструктор интернет-магазина от Яндекса с публичной документацией и API разработчика.
InSales — российская SaaS-платформа с открытым API для интеграции приложений и обмена данными.
Shopify — международный SaaS-лидер с готовым B2B-режимом; см. оговорку ниже.

Подходящий сценарий: быстрый запуск B2C-магазина, проверка спроса на новой нише, ограниченный бюджет разработки, команда без постоянной техподдержки.

Способ расширения: готовые приложения поставщика, публичный API, иногда собственные приложения поверх API.

Ограничения SaaS

Владелец данных и лимиты тарифа. Тариф определяет число SKU, объём трафика и набор доступных функций; каталог, заказы и клиентская база физически находятся у поставщика.
Глубина кастомизации. Нестандартный checkout или B2B-логика возможны только в пределах расширений поставщика; форк кода невозможен.
Экспорт. Выгрузка каталога, заказов и клиентов зависит от возможностей платформы и тарифа. Перед входом проверяется, что критичные сущности выгружаются целиком и в открытом виде, иначе будущая миграция станет дорогой.

Shopify и российский бизнес

По Shopify нельзя утверждать ни полную доступность, ни недоступность для российских проектов: каждая точка — юрлицо для регистрации, биллинг подписки, эквайринг на витрине, валюты и выплаты продавцу — проверяется отдельно перед проектом. Shopify Payments не представлен для бизнеса из РФ в официальном списке поддерживаемых стран (на момент подготовки раздела). B2B-функции Shopify привязаны к тарифному плану — страница plan features входит в чек-лист оценки B2B-сценария.

Модель 2. Коммерческая коробка

Назначение. Лицензионное ПО, развёрнутое на своей или арендованной инфраструктуре, с техподдержкой вендора по лицензии.

Представители:

«1С-Битрикс: Управление сайтом» — самый распространённый в РФ коробочный движок ecommerce: редакции различаются набором функций, есть готовая связка с 1С.
CS-Cart — коробочная платформа для интернет-магазинов и мультивендорных маркетплейсов.
UMI.CMS (редакция Shop) — коробочная CMS с магазинным профилем отдельной редакции.

Подходящий сценарий: средняя и крупная торговля со сложными ценовыми правилами, обязательная интеграция с 1С, требование хранить данные на своей инфраструктуре.

Ограничения. Лицензия покупается единоразово, бесплатные обновления идут в пределах периода, затем продлеваются — без продления прекращаются обновления безопасности. Исходный код вендора недоступен или ограниченно доступен для изменений.

Роль разработчика: развёртывание, модули интеграции, кастомизация шаблонов и бизнес-логики, поддержка между релизами вендора.

«1С-Битрикс: Управление сайтом» и Битрикс24 — два разных продукта

«1С-Битрикс: Управление сайтом» — контентная и магазинная CMS, разворачиваемая на своём хостинге. Битрикс24 — облачный сервис автоматизации бизнеса с CRM в ядре. Это разные продукты для разных задач, и «переключить» один на другой нельзя: архитектуры не совместимы. В ecommerce-проекте обе системы могут сосуществовать: сайт на «Управлении сайтом», CRM — в Битрикс24, обмен клиентами и заказами через интеграцию.

Модель 3. Open-source self-hosted

Назначение. Открытый код без лицензионных платежей, полностью подконтрольный команде, на своей инфраструктуре.

Представители:

WooCommerce — открытый ecommerce-плагин на WordPress; REST API даёт управление товарами, заказами, клиентами и налогами.
OpenCart — открытый движок магазина с готовой витриной и админкой.

Подходящий сценарий: контентно-ориентированные магазины с издательской частью (WooCommerce), проекты с собственной командой сопровождения и стандартным для РФ сценарием «каталог — заказ».

Ограничения. Ответственность за хостинг, обновления и безопасность лежит на команде проекта. Безопасность — постоянный процесс (обновления ядра и плагинов, мониторинг уязвимостей), а не разовая настройка.

Способ расширения: хуки и фильтры ядра, плагины, при необходимости форк кода; у WooCommerce — вся экосистема плагинов WordPress.

Модель 4. Custom — собственная разработка

Назначение. Магазин как собственный продукт, когда стандартный сценарий готовых платформ не покрывает модель торговли, данные или внутренние системы компании.

Базовый стек. Laravel как приложение-скелет и основа витрины; commerce-домен — каталог, корзина, checkout, статусы заказа — разрабатывается под модель торговли или подключается через проверенные commerce-пакеты, а не пишется с нуля без обоснования.

Админ-панель — это не магазин

Filament — это Panel Builder и UI-инструментарий для создания админ-интерфейсов на Laravel. Это не готовый магазин и не ecommerce-платформа: он даёт таблицы, формы и панели для панели управления. Вся торговая логика (каталог, корзина, платежи, статусы) требует разработки commerce-домена — Filament лишь оформляет её в админ-интерфейсе. Ошибка «возьмём Filament и получим магазин» приводит к бюджету, рассчитанному на «админку», при незакрытой половине домена.

Подходящий сценарий: специфическая модель торговли (агрегатор, нестандартный B2B), глубокая интеграция с внутренней системой компании, особые требования к производительности витрины.

Ограничения. Полный цикл разработки и сопровождения силами команды: витрина, админка и интеграции проектируются, тестируются и развиваются самостоятельно; первый запуск занимает месяцы.

Способ расширения: независимый от вендора — Composer-пакеты, собственные модули, доменные сервисы под каждый сценарий.

Сравнение моделей поставки

Критерий	SaaS	Коммерческая коробка	Open-source self-hosted	Custom
Срок запуска	Дни–недели	Недели	Недели–месяцы	Месяцы
Владение кодом	Нет	Лицензия на использование	Да	Да
Владение данными	У поставщика	У владельца	У владельца	У владельца
Оплата ПО	Ежемесячный тариф	Лицензия + продление обновлений	Бесплатно	Оплата разработки
Расширяемость	В границах API и приложений	Модули, ограниченная доработка	Хуки, плагины, форк	Полная
API для интеграций	Есть, полнота различается	Есть; у «Битрикса» — связка с 1С	REST API (WooCommerce)	Проектируется под задачу
Экспорт данных	По возможностям тарифа	Полный (своя инфраструктура)	Полный	Полный
Инфраструктура	Облако поставщика	Свой хостинг	Свой хостинг	Свой хостинг
Обновления	Поставщик	Вендор + команда	Команда	Команда
B2B-возможности	Ограничены тарифом (у Shopify — отдельный план)	Есть у «Битрикса» и CS-Cart	Через плагины	Разрабатываются под модель
Российские интеграции (1С, эквайринг, доставка)	Готовые у локальных SaaS	Готовые у «Битрикса», модули	Плагины и связки 1С	Разработка под задачу

Как читать таблицу при выборе

Снимите требования с модели торговли: B2B-портал или маркетплейс почти всегда упираются в B2B-возможности и split-платежи, а не в срок запуска.
Проверьте точки данных: какими сущностями платформа обменивается по API и что выгружает целиком (см. данные и интеграции).
Только затем сравнивайте цену и сроки представителей внутри подходящей модели.

Связанные страницы

Обзор контура — критерии выбора платформы и карта контура платформы и витрины.
Каталог и checkout — сценарий покупки, который платформа обязана покрыть при любом выборе.
Данные и интеграции — обмен платформы с 1С, платёжными системами и доставкой.
Стек WooCommerce — приёмочный порядок open-source-варианта.

Материалы и источники

Яндекс KIT: документация и API Яндекс KIT — наличие публичного API у SaaS-платформы.
InSales: как интегрироваться с API и приложениями — расширение SaaS-платформы через API и приложения.
1С-Битрикс: редакции «Управления сайтом» — редакционная модель лицензии коробки.
1С-Битрикс: интеграция с 1С — готовая связка коробки с 1С.
Отличие «1С-Битрикс» от Битрикс24 — подтверждение, что это два разных продукта для разных задач.
Shopify Payments: поддерживаемые страны — доступность Shopify Payments по странам (на момент подготовки раздела).
Shopify B2B: plan features — привязка B2B-функций Shopify к тарифному плану.
WooCommerce REST API — открытый API для каталога, заказов и клиентов.
CS-Cart — коробочная модель, сценарии интернет-магазина и маркетплейса.
UMI.CMS: редакция Shop — магазинный профиль отдельной редакции коробки.
OpenCart: возможности — открытый движок с готовой витриной.
Laravel: установка — Laravel как приложение-скелет custom-модели.
Filament: getting started — позиционирование Filament как Panel Builder и UI-инструментария для админ-интерфейсов.