Для интернет-магазина часто выбирают готовую ecommerce-платформу. Это логично: каталог, корзина, заказы и платежи там уже предусмотрены.
Но небольшому магазину могут быть не нужны многие возможности такой системы. Например, личные кабинеты, бонусные программы, несколько складов или сложное управление заказами.
Недавно я перенёс магазин дизайнерской одежды MISA Design с WordPress и WooCommerce на Astro.
Теперь основные страницы магазина собираются заранее, каталогом владелец управляет через CMS или Excel, а небольшая серверная часть отвечает за оформление заказов и оплату через Т-Банк.
Расскажу, как это устроено на практике и почему для этого магазина оказалось достаточно такого решения.
О том, когда лучше использовать готовую платформу, а когда отдельную разработку, я также писал в статье «Готовая платформа или отдельная разработка: что выбрать для интернет-магазина».
Каталог
В MISA Design сейчас несколько десятков товаров.
У каждого товара есть название, описание, фотографии, цена и варианты, например цвет и размер.
Для вариантов используются три статуса:
- в наличии;
- под заказ;
- нет в наличии.
Покупатель сразу видит, какой вариант можно заказать сейчас.
Точного количественного складского учёта здесь пока нет. Для текущего процесса магазина достаточно статусов наличия.
Это осознанное решение: владельцу сейчас не нужно хранить на сайте точное количество каждой вещи или резервировать остатки при оформлении заказа.
Если такой учёт понадобится позже, можно будет расширить серверную логику или подключить отдельную складскую систему.
Управление товарами
Владелец может самостоятельно обновлять каталог через панель управления в браузере.
В ней можно:
- добавить новый товар;
- изменить цену и описание;
- загрузить фотографии;
- настроить цвета и размеры;
- поменять статусы наличия;
- изменить категории и другие данные.
Изображения хранятся вместе с проектом. При сборке сайта они автоматически обрабатываются и преобразуются в подходящие форматы.
Для массовых изменений предусмотрен второй способ - Excel.
Например, если нужно изменить цены сразу у нескольких десятков товаров, необязательно открывать каждую карточку. Можно выгрузить каталог, отредактировать таблицу и загрузить её обратно.
Перед применением импорта система показывает, какие данные изменятся. Сначала владелец проверяет результат, а затем подтверждает обновление.
Есть и защита от случайного удаления: если какого-то товара нет в загруженном Excel-файле, он не удаляется из каталога автоматически.
Для скрытия товаров предусмотрен отдельный статус публикации.
Что происходит после изменения каталога
Когда владелец сохраняет изменения через CMS или загружает Excel-файл, обновлённые данные попадают в репозиторий проекта.
После этого запускается автоматическая сборка сайта.
Если сборка и предусмотренные проверки проходят успешно, новая версия публикуется на хостинге.
При этом сохраняется история изменений. Можно посмотреть, что менялось раньше, сравнить версии и при необходимости восстановить предыдущие данные из репозитория.
Таким образом, владелец работает через привычную панель управления, а техническая часть публикации выполняется автоматически.
Корзина и оформление заказа
Корзина работает в браузере покупателя.
Человек выбирает товар, цвет и размер, добавляет их в корзину и переходит к оформлению.
В форме заказа указываются:
- имя и фамилия;
- телефон;
- email;
- пункт выдачи Ozon.
Обязательной регистрации и личного кабинета нет.
Для этого магазина они сейчас не нужны. Покупателю не приходится создавать аккаунт только ради одной покупки.
Как устроена оплата
После оформления заказа сайт создаёт заказ на сервере и получает ссылку на оплату.
Покупатель переходит на защищённую страницу Т-Банка, вводит данные карты и подтверждает платёж.
Сам сайт данные банковской карты не обрабатывает.
За этим простым для покупателя сценарием есть несколько важных проверок.
Сумму считает сервер
Браузер покупателя отправляет информацию о выбранных товарах и их вариантах, но не определяет окончательную стоимость заказа.
Сервер самостоятельно получает актуальные цены из каталога, проверяет выбранные варианты и количество, учитывает доставку и рассчитывает итоговую сумму.
Поэтому просто изменить цену в браузере и отправить заказ с произвольной суммой не получится.
Повторный запрос не создаёт второй заказ
При оформлении заказа предусмотрена защита от повторных запросов.
Например, покупатель дважды нажал кнопку оформления или запрос был отправлен повторно из-за ошибки соединения.
Для повторной попытки того же оформления используется существующий заказ, а не создаётся новый.
Это помогает избежать ситуации, когда один и тот же заказ случайно появляется в системе несколько раз.
Оплату подтверждает банк
После платежа Т-Банк отправляет уведомление на сервер магазина.
Сервер проверяет подпись уведомления, сумму заказа и идентификатор платежа.
Только после успешной проверки заказ получает статус оплаченного.
То есть магазин не считает заказ оплаченным лишь потому, что покупатель вернулся со страницы банка.
После подтверждения оплаты отправляются уведомления по email. Владелец получает информацию о новом оплаченном заказе, а покупатель - подтверждение покупки.
Что проверяется автоматически
У проекта есть несколько уровней проверок.
При автоматической публикации выполняются проверка Astro, валидация данных каталога и сборка сайта.
Если на этом этапе обнаруживается ошибка, публикация новой версии останавливается.
Отдельно я написал тесты для серверной части магазина. Они проверяют:
- создание заказа и обработку некорректных данных;
- серверный расчёт стоимости;
- цены вариантов и количество товаров;
- защиту от повторного создания заказа;
- обработку уведомлений от банка;
- неверную подпись уведомления;
- несовпадение суммы или идентификатора платежа;
- сценарии повторной и неуспешной оплаты.
Эти тесты запускаются отдельно при разработке. Они помогают убедиться, что изменения не нарушили критичные сценарии магазина.
Конечно, тесты не гарантируют полного отсутствия ошибок. Но позволяют автоматически проверять те ситуации, где ошибка может привести к неправильной сумме заказа, проблемам с оплатой или дублированию заказов.
Почему здесь достаточно обычного хостинга
Основные страницы магазина заранее собираются в готовые HTML-файлы.
Когда покупатель открывает каталог или карточку товара, серверу не нужно каждый раз формировать страницу из базы данных.
Серверная логика нужна для других задач: создания заказов, проверки цен, обработки платежей и взаимодействия с внешними сервисами.
В MISA Design для этого используется PHP и MySQL.
Магазин работает на обычном хостинге без отдельного VPS и постоянно запущенного Node.js-приложения.
Для текущих задач этого достаточно. Не нужно разворачивать и обслуживать дополнительную серверную инфраструктуру только ради небольшого магазина.
Что было с адресами после WordPress
До переноса MISA Design работал на WordPress и WooCommerce.
При смене платформы важно было сохранить доступность старых адресов страниц, чтобы существующие ссылки не перестали работать.
Для старых URL настроены постоянные перенаправления на новые страницы.
Кроме того, новый сайт формирует sitemap, robots.txt и структурированные данные товаров.
Это не означает, что поисковые позиции гарантированно останутся прежними. На них влияет множество факторов.
Но переход на другую технологию не должен автоматически приводить к тому, что старые ссылки превращаются в ошибки.
Где заканчиваются возможности такой схемы
Решение подходит текущим задачам MISA Design: относительно небольшой каталог, простой сценарий заказа и отсутствие сложного складского процесса.
Но со временем потребности магазина могут измениться.
Например, могут понадобиться:
- точные остатки товаров;
- резервирование при оформлении заказа;
- несколько складов;
- синхронизация остатков с маркетплейсами;
- сложные скидки и программы лояльности;
- расширенная работа с возвратами;
- обмен заказами с CRM или учётной системой.
Появление одной новой функции не означает, что весь сайт придётся переделывать.
Часть возможностей можно добавить отдельно. Например, если потребуется полноценный складской учёт, его можно вынести во внешнюю систему вроде МойСклада, а сайт оставить витриной и интерфейсом покупки.
Между ними понадобится интеграция, но менять всю архитектуру магазина необязательно.
Однако если большая часть работы уже связана с управлением заказами, складами, возвратами, клиентами и несколькими каналами продаж, стоит снова оценить выбор технологии.
В такой ситуации специализированная ecommerce-платформа может оказаться практичнее собственной реализации этих функций.
Итог
На примере MISA Design видно, что небольшому интернет-магазину необязательно использовать крупную ecommerce-платформу.
Владелец самостоятельно управляет каталогом, покупатель оформляет заказ без регистрации, а сервер проверяет цены и обрабатывает оплату. Для критичной логики предусмотрены автоматические тесты.
Основные страницы остаются статическими, а сервер используется только там, где он действительно нужен.
Это не универсальная архитектура для всех магазинов. Но для текущих задач MISA Design её достаточно.
Если процессы станут сложнее, отдельные возможности можно добавить или подключить через внешние сервисы. А если требования существенно изменятся, пересмотреть сам подход.