Новые правила онлайн торговли с 1 сентября 2026 года: как проверить путь до заказа по закону
С 1 сентября 2026 года начнут действовать новые Правила продажи товаров по договору розничной купли-продажи. Для интернет-магазина это повод проверить не только оферты, но и реальный путь покупателя: видит ли он договор и сведения о продавце, понимает ли факт оформления заказа, получает ли подтверждение с идентификатором и может ли найти способ направить претензию. Ниже — маршрут для вашей проверки. Коротко описали процессную и UX-проверку для вашего бизнеса.
О чём эта статья
Проверить нужно не только текст оферты, но и весь клиентский путь
К 1 сентября интернет-магазинам нужно обновить оферты и реквизиты, но этого недостаточно — вам нужно пройти путь клиента: смотреть товар, выбирать оплату и доставку, сделать тестовый заказ. На любом шаге информация о покупке для клиента может отличаться от оферты, быть незаметной, противоречивой или недоступной после оформления. Эти недочёты нужно устранить, если вы занимаетесь E-com.
Что изменится и где проходит граница обязательной UX-проверки
Постановление Правительства России от 30 мая 2026 года № 657 вступит в силу 1 сентября 2026 года и будет действовать до 1 сентября 2032 года. Для дистанционной продажи ключевые положения собраны в пунктах 15–30 Правил. В этой статье мы разбираем только путь до подтверждения заказа и доступность сведений, указанных в пунктах 15–24.
С 1 сентября для проверки сайта будут особенно заметны четыре группы требований.
- Продавец будет обязан дать покупателю возможность ознакомиться с офертой при продаже через интернет.
- После сообщения о намерении заключить договор подтверждение должно будет содержать номер заказа или другой идентификатор, по которому можно получить сведения о договоре и его условиях.
- На сайте должны будут быть доступны сведения о продавце. Набор сведений различается для юридического лица и индивидуального предпринимателя.
- Продавец должен будет сообщить форму и способы направления претензии.
Момент заключения договора Правила связывают с выдачей документа об оплате либо с получением сообщения покупателя — учитывается более раннее событие. Обязательства по передаче товара будут возникать с получения сообщения, если оферта не установит другое условие.
Проверка отвечает на вопросы «что увидел покупатель», «в какой момент» и «может ли он вернуться к тем указанным условиям». Юрист определяет, верно ли сформулированы условия и как применять Правила к конкретной модели продажи.
Как подготовить контрольные сценарии
Не начинайте со списка страниц. Сначала опишите способы, которыми покупатели доходят до заказа. Иначе команда проверит один удобный маршрут и пропустит другую оплату, доставку или версию интерфейса.
Составьте перечень возможностей магазина на дату проверки:
- устройство и интерфейс: мобильная и настольная версии, а при наличии — приложение;
- состояние покупателя: новый пользователь, авторизованный пользователь, гостевой заказ, если он доступен;
- оплата: только те способы, которые магазин действительно предлагает;
- получение: доставка, пункт выдачи, самовывоз и другие действующие варианты;
- тип товара: обычный товар и отдельный сценарий, если условия зависят от категории, наличия или предварительного согласования.
Включите каждый действующий способ оплаты и получения хотя бы в один сценарий. Мобильную и настольную версии пройдите отдельно, а гостевой тестовый заказ — если он доступен. Необязательно проверять все перестановки: объединяйте условия так, чтобы каждая развилка условий продажи встретилась хотя бы один раз.
Для каждого сценария заранее запишите ожидаемый результат. Например: «до отправки заказа покупатель открывает оферту; после оформления получает идентификатор и находит по нему сведения о договоре».
Mobile и desktop
Мобильный экран и ПК-маршруты проходите отдельно. Блок дизайна может быть заметен на широком экране и скрыт в меню на телефоне. Ссылка может работать на компьютере, но возвращать пользователя к пустой корзине в мобильном браузере.
Для воспроизводимого внутреннего протокола сохраняйте ширину экрана, дату и время, адрес страницы, шаг сценария, действие и результат. Если контент зависит от региона, добавьте город или зону доставки.
Оплата, доставка и гостевой заказ
Подтверждение нельзя полноценно проверить, не отправив заказ. В рабочем магазине заранее согласуйте тестовый товар, адрес, оплату, уведомления и отмену. Заказ не должен попасть в реальную комплектацию, искажать отчётность или создавать лишнюю работу поддержке. Если безопасного сценария нет, используйте тестовую среду и отметьте, какие внешние сообщения она не воспроизводит.
Где покупатель видит оферту и сведения о продавце
С 1 сентября пункт 20 будет требовать обеспечить возможность ознакомиться с офертой при продаже через интернет. До теста юрист или владелец процесса должен указать, какое действие магазин считает сообщением покупателя о намерении заключить договор. Проверяющий смотрит, доступна ли оферта до этого действия.
Проверьте три точки маршрута покупки:
- Карточка товара или другой экран, где покупатель узнаёт условия приобретения.
- Корзина, где уже видны состав и стоимость заказа.
- Последний шаг оформления до отправки данных.
В каждой точке зафиксируйте, где находится ссылка, как она названа и что происходит после нажатия. Открытие без потери корзины и понятное название ссылки — внутренние UX-критерии, а не отдельные требования постановления. Они помогают понять, может ли реальный покупатель воспользоваться доступом к условиям.
Пункт 21 будет требовать полную и достоверную информацию, характеризующую товар. Для процессной проверки сопоставьте карточку, корзину и итоговый экран: не меняются ли наименование, количество и цена без понятного объяснения. Полноту обязательной информации для конкретной категории оценивают отдельно.
Сведения о продавце проверяйте комплексно, как единый пакет. Для российского юр. лица пункт 22 требуется указать: полное фирменное наименование, ОГРН, адрес и место нахождения, а также электронную почту и (или) телефон. Для индивидуального предпринимателя — фамилию, имя, отчество при наличии, ОГРНИП и электронную почту и (или) телефон.
Запишите, где именно покупатель находит эти сведения: в оферте, разделе контактов, подвале или на отдельной странице. Затем сравните значения между точками. Разные названия организации, старый адрес или разные контакты — это уже явная задача на устранение нарушений вашему администратору даже до правовой оценки.
Пункт 19 задаёт ещё одно требование. Если на сайте предусмотрено предварительное согласование условий, включая наличие, наименование или количество, товар признаётся не предназначенным для дистанционной продажи. Не применяйте этот чек-лист автоматически как юридический минимум к такой модели: зафиксируйте процесс и передайте его юристу.
Для агрегатора также нужен отдельный разбор ролей. В протоколе разделите, что показывает продавец, что показывает площадка и на каком шаге доступны сведения каждого участника.
Как проверить оформление и подтверждение договора
Начните фиксировать все показанные условия на сайте до нажатия финальной кнопки Заказать. Сохраните состав заказа, итоговую сумму, оплату и доставку, текст кнопки и ссылки на условия. После отправки зафиксируйте результат в том же сценарии.
Проверьте все каналы подтверждения, которые обещает магазин:
- итоговый экран сайта или приложения;
- письмо;
- СМС или сообщение в другом согласованном канале;
- личный кабинет;
- кассовый чек или другой документ об оплате, если он формируется на этом шаге.
Сопоставление состава, цены, оплаты и доставки между корзиной и подтверждением — внутренний критерий качества процесса. Если часть сведений доступна по ссылке, откройте её в новой сессии и проверьте, не зависит ли доступ только от текущего браузера.
Номер или иной идентификатор заказа
С 1 сентября пункт 17 будет требовать, чтобы подтверждение содержало номер заказа или иной способ идентификации. По нему покупатель должен будет иметь возможность получить информацию о договоре и его условиях.
Зафиксируйте какие-то условные идентификаторы во всех каналах привлечения клиентов и проверьте, можно ли однозначно сопоставить их с заказом. Если то, что видит покупатель и то, что говорит/обещает поддержка рассинхронизированы, не совпадают ожидаемые условия клиента и продавца, например, в письме рассылки и записи в системе - это процессный разрыв, который надо однозначно устранять.
Постарайтесь проследить и найти сведения по реальному пути вашего клиента на вашем сайте/приложении. Это наблюдаемая проверка позволит увидеть несоответствие предложенных клиенту условий и действующих у вас в бизнесе реальных условий выполнения заказа.
Доступ к условиям заключённого договора для клиента
Оферта может измениться после заказа. Проверьте, может ли покупатель по идентификатору открыть сведения о своём договоре и его условиях: через идентификатор (смс, email), файл, ссылку или личный кабинет.
Если доступна только ссылка на текущую редакцию оферты, зафиксируйте это для юридической и технической оценки. UX-тест не устанавливает, достаточен ли такой способ хранения.
Пункт 24 касается формы и способов направления претензий. В этой проверке достаточно отметить, где покупатель найдёт сведения, и сопоставить контакты с офертой. Отправка и обработка обращения выходят за границы статьи.
Как оформить протокол расхождений и поставить корректно задачи команде
Протокол нужен для постановки задач команде. Каждое наблюдение связывайте с этапом, сценарием, ожидаемым и фактическим результатом, доказательством и одним ответственным за результат изменений.
Используйте единый код сценария, например M-GUEST-DELIVERY-01: мобильный интерфейс / новый покупатель / доставка. Это просто техническая метка, не универсальный стандарт. Ваша команда может выбрать собственный формат.
| Этап | Что должен получить покупатель | Где проверять | Доказательство | Владелец | Повторная проверка |
|---|---|---|---|---|---|
| Оферта | Доступ к условиям и сведениям о продавце | Карточка, корзина и последний шаг оформления | Скриншот с датой, URL и кодом сценария | Владелец контента | После изменения документа или ссылки |
| Товар | Согласованные наименование, количество и цена | Карточка товара и переход в корзину | Снимки до и после действия | Владелец каталога | После изменения карточки или цены |
| Корзина | Состав заказа, сумма, оплата и получение | Корзина до перехода к оформлению | Скриншот и записанный результат действия | Руководитель e-commerce | После исправления и на втором устройстве |
| Оформление | Понятное финальное действие и доступ к условиям | Последний шаг до отправки заказа | Снимок состояния до нажатия | Владелец продукта | После изменения текста или логики формы |
| Подтверждение | Идентификатор и путь к сведениям о договоре | Итоговый экран, письмо и личный кабинет | Снимки каналов и записанные идентификаторы | Владелец CRM | После тестового заказа тем же сценарием |
В рабочей версии матрицы приоритетов и задач добавьте фактический результат, приоритет и срок. Статусы: «подтверждено», «не сходится (разрыв)», «не применимо» или «нужна правовая оценка». Разрыв - означает расхождение с ожидаемым процессом, а не готовый вывод о нарушении.
Блокирующий приоритет дайте там, где есть разрыв, из-за которого нельзя оформить заказ, открыть условия договора своего заказа. Следующий приоритет — противоречивые сведения и каналы коммуникаций, которые создают риск ошибок или лишней ручной работы. Вопросы о формулировках и применимости норм передавайте юристу вместе с доказательствами.
Задачу формулируйте через наблюдаемый результат. Вместо «поправить оферту» напишите: «на мобильном ссылка открывает документ без потери корзины; после возврата сохраняются товар, доставка и сумма». Укажите ответственного по задаче, срок и сценарий регулярной проверки.
После исправления повторите тот же маршрут с тем же кодом, затем коротко проверьте экраны на других тестовых устройствах.
Когда требуется юридическая проверка
Передайте материал юристу, если вопрос выходит за наблюдаемое поведение интерфейса:
- оферта иначе определяет момент возникновения обязательств продавца;
- часть условий согласуется после заявки по телефону или в переписке;
- магазин работает через агрегатора и роли сторон распределены между несколькими документами;
- товар относится к категории с особыми правилами;
- разные документы называют разные условия, продавца или порядок претензии;
- подтверждение не сохраняет условия, доступные на момент заказа;
- команда хочет сделать вывод о соответствии требованиям.
Юристу передавайте протокол с датой, сценариями, ссылками, снимками и перечнем расхождений. Готовность процесса подтверждена, когда все способы оплаты и получения покрыты сценариями, mobile и desktop пройдены, блокирующие расхождения закрыты, а у остальных задач есть ответственный и дата повторного теста.
Основа материала
Источники
Постановление Правительства Российской Федерации от 30 мая 2026 года № 657. Официально опубликованный текст новых Правил продажи товаров по договору розничной купли-продажи, включая дату вступления в силу и пункты о дистанционной продаже.
Проверено 29 августа 2026 годаО новом порядке продажи товаров дистанционным способом по договору розничной купли-продажи. Разъяснение Управления Роспотребнадзора по Республике Мордовия о моменте заключения договора, подтверждении с идентификатором заказа, сведениях о продавце и способах направления претензий.
Проверено 29 августа 2026 года
Коротко
- Составьте сценарии так, чтобы каждый способ оплаты и получения заказа обязательно присутствовал хотя бы один раз, тесты на mobile и desktop экранах были пройдены отдельно.
- Проверьте пять этапов: оферта, товар, корзина, оформление и подтверждение с идентификатором заказа.
- Для внутреннего протокола сохраняйте дату, URL, код сценария, действие, ожидаемый и фактический результат.
- Начните с двух самых разных сценариев, назначьте ответственного за устранение несоответствий и дату повторного теста; правовые вопросы передайте юристу.