Интернет-магазин: арендуемая платформа или заказная разработка?

По мнению Mesterséges Intelligencia Központ Kft., компании по разработке программного обеспечения из Будапешта, с арендуемой платформы стоит начинать, если ассортимент укладывается в её рамки; заказная разработка оправдана, когда ценообразование или интеграции их перерастают.

Коротко: решают три вопроса: укладываются ли ассортимент и процесс заказа в рамки арендуемой платформы, со сколькими системами магазину нужно обмениваться данными и насколько важно развивать его без ограничений платформы. Для многих компаний арендуемая платформа станет хорошим первым шагом: если данные экспортируются, позже можно перейти на индивидуальное решение.

Из каких вариантов можно выбирать?

Сегодня к «интернет-магазину» ведут четыре пути. Границы не резкие (за арендуемой платформой может стоять индивидуальная интеграция, а индивидуальный магазин может использовать готовую платёжную страницу), но ответственность и свобода действий у каждого свои.

Арендуемый интернет-магазин (SaaS)

SaaS (software as a service, программное обеспечение как услуга) означает, что ПО магазина запускает, обновляет и защищает поставщик, а продавец подписывается на него и управляет им из браузера. Среди международных примеров можно назвать Shopify, а на венгерском рынке Shoprenter и UNAS. Платформы дополняются расширениями, большинство предлагает и API, то есть программный интерфейс, через который другая система читает данные магазина или записывает их.

Документация Shoprenter для разработчиков описывает интерфейс по ресурсам (в том числе товары, покупатели, заказы) и предлагает вебхуки: автоматические сообщения, которые магазин шлёт внешней системе после события, например оформления заказа или смены его статуса (Shoprenter: WebHook automation). По документации UNAS, API связывает магазин с внешними системами, даже двусторонне, например с сервисом выставления счетов или складским учётом; интерфейс доступен в тарифах PREMIUM и VIP (UNAS: документация API, проверено 17 октября 2026 года). Поэтому при выборе тарифа стоит проверить, что позволяет его уровень.

Интернет-магазин с открытым исходным кодом на собственном хостинге

Распространённым примером является WooCommerce, плагин интернет-магазина с открытым кодом для системы управления контентом WordPress. Его код доступен по лицензии GNU General Public License версии 2 или более поздней (WooCommerce: лицензия); описание плагина упоминает REST API и вебхуки для интеграций и подчёркивает, что контент и данные магазина остаются у владельца (WordPress.org: WooCommerce). У свободы есть цена: хостинг, обновление WordPress и плагинов, резервное копирование и защита ложатся на владельца или нанятого им подрядчика по эксплуатации.

Headless-интернет-магазин

В headless-архитектуре («без головы») видимый покупателю интерфейс и движок магазина являются отдельными системами. По документации Shopify для разработчиков, headless-коммерция отделяет фронтенд магазина от бэкенда: интерфейс можно создать и разместить на любой технологии, а товары, корзину и оформление заказа обслуживает API платформы (Shopify: Headless). Это полезно, если покупательский опыт должен быть очень своеобразным, если магазин является частью сайта, богатого контентом, или если один ассортимент нужно показывать в нескольких каналах: в вебе, мобильном приложении, киоске. Взамен сопровождать приходится две системы: платформу и свой интерфейс.

Интернет-магазин, разработанный на заказ

В индивидуальном магазине модель товаров, ценообразование, процесс заказа и интеграции создаются точно под работу компании. Ограничений платформы нет, но нет и готового рынка расширений: всё, что должен уметь магазин, нужно спроектировать, разработать, протестировать и эксплуатировать. Этот путь силён, когда магазин служит основным каналом продаж компании и должен тесно работать с системой управления предприятием, складом или производством.

Сравнение в одной таблице

Критерий	Арендуемая платформа	Открытый исходный код (например, WooCommerce)	Headless	Заказная разработка
Запуск	самый быстрый: готовая тема и настройки	быстрый, если хватает готовых тем и плагинов	дольше: нужно создать свой интерфейс	самый долгий; решает размер разработки
Модель оплаты	подписка; дополнительные приложения могут стоить отдельно	подписки на ПО нет; хостинг, платные плагины и эксплуатация	подписка на платформу плюс разработка и эксплуатация своего интерфейса	разовая разработка, затем эксплуатация и развитие
Расширяемость	в рамках платформы и её рынка расширений	свободно, но каждый плагин добавляет ещё один элемент для обновления	интерфейс расширяется свободно, движок остаётся за платформой	без ограничений, вопросы исходного кода регулируются договором
Интеграции (склад, ERP, счета, курьеры)	готовым расширением или через API, если тариф позволяет	плагином или собственным кодом	через API платформы	через любой интерфейс, по нуждам компании
Производительность	определяют инфраструктура поставщика и качество темы	зависит от хостинга и числа плагинов	хорошо оптимизируется, но своими силами	зависит от проектирования и эксплуатации
Данные и экспорт	по функциям экспорта и условиям платформы	вся база данных принадлежит владельцу	данные движка находятся на платформе	вся база данных принадлежит заказчику
Хостинг и безопасность	отвечает поставщик	владелец или его подрядчик по эксплуатации	разделены: движок на стороне платформы, интерфейс на стороне компании	заказчик или его подрядчик по эксплуатации

Скорость стоит измерять, а не угадывать: рекомендуемые Google показатели Core Web Vitals измеряют загрузку (LCP), отзывчивость (INP) и визуальную стабильность (CLS) (web.dev: Web Vitals) и применимы к любому типу магазина.

Когда достаточно арендуемой платформы, а когда оправдан индивидуальный магазин?

Признаки, что арендуемой платформы достаточно

Товары простые: мало вариантов, однозначная цена, нет сложной конфигурации.
Процесс заказа привычный: корзина, способ доставки, оплата, подтверждение.
Для нужных интеграций (сервиса выставления счетов, курьерской службы, оплаты) есть готовые расширения.
Важен быстрый запуск, а у команды нет времени или желания эксплуатировать сервер.
Магазин является одним из каналов продаж, а не всей бизнес-моделью.

Признаки, что стоит двигаться к индивидуальному или headless-решению

Товары конфигурируемые или изготавливаются по меркам, либо цена рассчитывается из нескольких факторов.
Нужны прайс-листы для реселлеров (B2B), особые правила скидок, цены по рамочным договорам.
Магазин должен работать в реальном времени с ERP, складом или производством.
Плагинов уже столько, что даже одно обновление становится риском.
Из-за ограничений платформы компания подстраивает свой процесс под ПО, а не наоборот.

Распространённым и удачным промежуточным решением является арендуемый магазин с индивидуальной интеграцией: магазин остаётся на платформе, а индивидуальный сервис за ним связывает заказы с сервисом выставления счетов, складом и системой управления предприятием. Это задача системной интеграции; подробности приведены на странице Автоматизация процессов. Общее сравнение заказного ПО и готового продукта дано в статье Заказное ПО или готовое решение (SaaS)?

Венгерская специфика: счета, NAV, курьеры, оплата

Выставление счетов и NAV Online Számla

По разъяснению венгерской налоговой службы (NAV), с 4 января 2021 года данные нужно предоставлять и по счетам, выставленным лицам, не являющимся плательщиками НДС, в том числе частным покупателям; программа для выставления счетов должна при выставлении счёта сразу, без участия человека, передавать данные электронно, в формате XML, в систему Online Számla (NAV). Описание машинного интерфейса NAV публикует и в общедоступном репозитории (NAV: Online-Invoice). Магазины обычно решают это через сервис выставления счетов: по документации Számlázz.hu, например, интерфейс Számla Agent автоматизирует в XML операции со счетами и чеками (Számlázz.hu: документация API). Важнее всего сам процесс: оплаченный или выполненный заказ должен становиться счётом без ручного переноса, а о сбое или отклонении передачи данных кто-то должен узнать.

Курьерские службы и постаматы

Подключение курьерских служб и пунктов выдачи означает три вещи: при оформлении заказа покупатель выбирает пункт выдачи или постамат, этикетка посылки создаётся из заказа автоматически, а статус посылки возвращается в магазин и покупателю. На арендуемой платформе стоит проверить, есть ли для этого готовое расширение; в индивидуальном магазине или без подходящего расширения мы подключаемся к интерфейсу поставщика. Мы подключаем, например, GLS, Foxpost, MPL или Packeta.

Онлайн-оплата

При оплате картой международный стандарт безопасности PCI DSS касается всех, кто хранит, обрабатывает или передаёт данные карт. По документации Stripe, при интеграциях с пониженным риском платёжные данные идут прямо к платёжному сервису, минуя серверы продавца, что сокращает его обязательства по PCI (Stripe: Integration security guide). Поэтому мы рекомендуем не хранить данные карт в магазине: оплата должна проходить на странице платёжного сервиса (например, Barion, SimplePay или Stripe) или в его встроенном интерфейсе.

Склад и управление предприятием

Если остатки ведутся в системе складского учёта или ERP, магазин должен читать их оттуда, чтобы распроданный товар нельзя было заказать, и записывать туда заказы. Это одна из важнейших связей магазина; об учётной стороне мы пишем на странице ПО для бизнеса.

Правовые требования, которые касаются любого интернет-магазина

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

Право на отказ от договора

Директива 2011/83/ЕС регулирует права потребителей по дистанционным договорам; ниже мы опираемся на консолидированный текст от 27 сентября 2026 года (EUR-Lex: Директива 2011/83/ЕС, консолидированный текст):

По пункту 1 статьи 9 потребитель может в течение 14 дней отказаться от договора без объяснения причин; для товаров срок, как правило, считается со дня их получения.
По подпункту (h) пункта 1 статьи 6 продавец до заключения договора должен сообщить потребителю условия, срок и порядок отказа; сюда относятся типовая форма и, если она есть, сведения о наличии и расположении функции отказа.
Статья 11a, введённая Директивой (ЕС) 2023/2673, требует, чтобы при дистанционных договорах через онлайн-интерфейс продавец обеспечил функцию отказа с надписью «withdraw from contract here» (в английской версии директивы; по-русски примерно «отказаться от договора здесь») или равнозначной однозначной формулировкой, непрерывно доступную весь срок для отказа; через неё потребитель подаёт онлайн-заявление шагом с надписью «confirm withdrawal» («подтвердить отказ»), а продавец подтверждает получение на долговременном носителе. Государства-члены применяют эти нормы с 19 июня 2026 года (EUR-Lex: Директива (ЕС) 2023/2673).
Без этой информации срок для отказа по статье 10 истекает через 12 месяцев после окончания первоначального срока.
По статье 13 продавец возвращает все платежи потребителя, включая, если применимо, расходы на доставку, в течение 14 дней после того, как узнал об отказе.
Статья 16 перечисляет исключения, например товары, изготовленные по спецификации потребителя или явно персонализированные.

В Венгрии детальные правила содержит Постановление правительства 45/2014 (II. 26.); функцию отказа регулируют положения его § 22, введённые Постановлением правительства 415/2025 (XII. 23.) (Nemzeti Jogszabálytár, проверено 17 октября 2026 года). Для магазина это конкретные функции: информация до оформления заказа, онлайн-функция отказа, непрерывно доступная весь срок для отказа, с подтверждением получения, отслеживание возвратов товаров и денег и пометка персонализированных товаров.

Доступность

По Директиве (ЕС) 2019/882 государства-члены с 28 июня 2025 года должны применять требования доступности к услугам электронной торговли для потребителей (венгерские правила транспонируют директиву); это услуги, оказываемые через веб-сайты и мобильные сервисы для заключения потребительского договора (EUR-Lex: Директива (ЕС) 2019/882). Микропредприятия, оказывающие услуги (по директиве это менее десяти занятых и оборот или итог баланса ниже установленного порога), должны освобождаться от требований (статья 4, пункт 5). По приложению I директивы веб-сайты и мобильные приложения должны быть воспринимаемыми, управляемыми, понятными и надёжными. На арендуемой платформе это отчасти зависит от платформы и выбранной темы, поэтому тему стоит проверить и на доступность; в индивидуальном магазине мы следуем рекомендациям WCAG 2.2.

По пункту 3 статьи 5 консолидированного текста Директивы 2002/58/ЕС о конфиденциальности в электронных коммуникациях хранить информацию на устройстве пользователя или обращаться к уже хранящейся там информации можно лишь с предварительного согласия, данного после ясного и полного информирования. Исключением является хранение, строго необходимое для услуги, прямо запрошенной пользователем (EUR-Lex: Директива 2002/58/ЕС). Поэтому cookie корзины оценивается иначе, чем аналитический или рекламный: для последних нужно согласие, а баннер cookie должен давать реальный выбор.

Искусственный интеллект в интернет-магазине

Тексты о товарах: описания товаров, тексты категорий и переводы, подготовленные большой языковой моделью. Часть арендуемых платформ уже встроила это: по справочному центру Shopify, ИИ-функции панели администратора пишут и описания товаров, а сама Shopify просит продавцов проверять всё созданное ИИ, так как там бывают ошибки (Shopify Help Center: ИИ-функции).
Поиск: поиск товаров, понимающий и намерение покупателя («непромокаемые туристические ботинки для дождя»), а не только точное ключевое слово.
Служба поддержки: ИИ-чат-бот, отвечающий по собственным данным магазина (товары, условия доставки, статус заказа) и сообщающий, что покупатель общается с искусственным интеллектом. Подробности приведены на странице ИИ-чат-боты и ИИ-агенты; о правовой стороне рассказывает статья AI Act и GDPR.

На арендуемой платформе набор ИИ-функций зависит от платформы или расширения. В индивидуальном магазине или при индивидуальной интеграции можно выбрать среди моделей OpenAI (ChatGPT), Anthropic (Claude) и Google (Gemini), и мы подключаем модель прямо к данным магазина, с проверкой человеком там, где ошибка стоит денег или доверия.

Переезд: с арендуемой платформы на индивидуальное решение

Многие компании начинают с арендуемой платформы и уходят с неё, когда магазин перерастает её рамки. Гладкость перехода во многом зависит от того, сколько данных можно вынести из старой системы. По справочному центру Shopify, например, в CSV можно экспортировать и товары, и заказы, и покупателей (Shopify: экспорт товаров, экспорт заказов, экспорт покупателей), но изображения товаров в CSV товаров не входят, их нужно сохранять отдельно. Этапы переезда:

Инвентаризация данных: что есть в старой системе (товары, варианты, изображения, покупатели, прошлые заказы, купоны, контентные страницы) и что можно экспортировать.
Сопоставление и очистка данных: куда идёт каждое старое поле и что привести в порядок (например, дубли покупателей или неполные данные товаров).
Карта URL и перенаправления: по руководству Google Search Central каждый старый адрес сопоставляют с новым и настраивают серверные постоянные перенаправления (301 или 308), чтобы не потерять позиции в поиске (Google Search Central).
Переподключение интеграций: выставление счетов, оплата, курьеры и склад, с полной проверкой на пробных заказах.
Запуск и последующий контроль: финальная синхронизация данных старой системы, затем мониторинг показателей и ошибок после перехода.

Если вы сегодня выбираете арендуемую платформу, план выхода стоит подготовить сразу: какие данные экспортируются, в каком формате и есть ли API, через который будущая система сможет непрерывно их получать.

От чего зависят стоимость и сроки?

На арендуемой платформе стоимость складывается из подписки, дополнительных приложений, темы и работы по настройке; индивидуальная интеграция, если она нужна, представляет собой отдельную разработку. Для индивидуального магазина функциональный размер разработки мы измеряем в функциональных точках COSMIC (ISO/IEC 19761), и на его основе составляются предложение и график работ. Помимо размера, важны:

число интеграций и качество документации их интерфейсов;
сложность модели товаров: варианты, конфигурируемые товары, особые правила ценообразования;
уникальность дизайна и число интерфейсов (веб, мобильное приложение, панель администратора);
объём и качество переносимых данных;
нефункциональные требования: скорость, бесперебойность работы, доступность, безопасность;
объём эксплуатации и развития после передачи.

Метод измерения описан на странице Ценообразование.

Частые ошибки при выборе

Смотрят только на стоимость запуска, а не на подписку, расширения и эксплуатацию за несколько лет.
Не проверяют заранее, какие данные экспортируются и есть ли API в выбранном тарифе.
Ставят столько плагинов, что после обновления никто не знает, что и почему сломалось.
Начинают с ручного выставления счетов, и с ростом числа заказов оно становится узким местом.
При переезде не настраивают перенаправления, и старые адреса ведут на страницы ошибок.
Баннер cookie по умолчанию принимает всё или грузит аналитические скрипты и после отказа.

Частые вопросы

Какой интернет-магазин выбрать: арендуемый или индивидуальный?

Если ассортимент и процесс заказа укладываются в рамки арендуемой платформы (например, Shopify, Shoprenter, UNAS) или WooCommerce, это более быстрый и менее рискованный старт. Индивидуальный интернет-магазин оправдан, если ассортимент или ценообразование необычны, нужна тесная связь с ERP или складом в реальном времени или магазин является основным каналом продаж и его хотят развивать без ограничений платформы. Промежуточным путём служит арендуемый магазин с индивидуальной интеграцией.

Можно ли переехать с арендуемой платформы на индивидуальное решение?

Да, если данные можно вынести из старой системы: товары, покупателей, заказы, изображения и контент. Существенную часть переезда составляют перенаправление старых адресов на новые и переподключение интеграций. Уже при выборе платформы стоит проверить, какой экспорт и API она предлагает.

Можно ли связать интернет-магазин с сервисом выставления счетов и складом?

Да. Сервис выставления счетов (например, Számlázz.hu, Billingo) мы подключаем с автоматическим выставлением счетов, а систему складского учёта или ERP подключаем с синхронизацией остатков, если у них есть доступный интерфейс (API) или данные доступны в файлах или базе данных. Такую связь можно построить и за арендуемым магазином, если API платформы есть в выбранном тарифе.

Кому принадлежат данные на арендуемой платформе?

Это определяют условия использования платформы и её соглашение об обработке данных; по статье 28 GDPR обработка от имени контролёра должна регулироваться договором (EUR-Lex: Регламент (ЕС) 2016/679). На практике решает то, можете ли вы вынести свои данные: крупные платформы предлагают экспорт и API, но их объём зависит от платформы и тарифа. В магазине на собственном хостинге или разработанном на заказ вся база данных у владельца.

Должен ли интернет-магазин соответствовать требованиям доступности?

По правилам, транспонирующим Директиву (ЕС) 2019/882, услуги электронной торговли для потребителей с 28 июня 2025 года должны соответствовать требованиям доступности; микропредприятия, оказывающие услуги, по директиве должны освобождаться от них. Если компания не является микропредприятием, магазин стоит проверить на доступность, а на арендуемой платформе проверить и тему. Это информация, а не юридическая консультация.

Как мы можем помочь?

Мы разрабатываем индивидуальные интернет-магазины и связываем их с сервисами оплаты, доставки и выставления счетов, складом и ERP, а по запросу и с искусственным интеллектом. Если арендуемая платформа вам хорошо служит, менять её не нужно: мы построим интеграцию за ней. Подробнее читайте на странице Разработка интернет-магазинов.

Первая консультация бесплатна, по запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором. Если вы в нескольких предложениях опишете, что продаёте и с какими системами работаете, свяжитесь с нами.