Регулярные заказы и подписка в интернет-магазине: как спроектировать модель

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

Что входит в задачу «регулярные заказы и подписка»

Прежде чем обсуждать реализацию, нужно развести три похожих, но разных сценария. Их часто путают, и из-за этого в техническом задании смешиваются несвязанные требования.

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

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

Третий сценарий — собственно регулярные заказы и подписка. Магазин сам инициирует следующую поставку по расписанию или по остатку «оплаченных доставок», а покупатель управляет этим из личного кабинета. Этот сценарий разбираем далее.

Чем регулярный заказ отличается от повторной покупки

Ключевое отличие — в том, кто инициирует событие. При повторной покупке триггер у покупателя, и каждый заказ живёт своей жизнью. При подписке триггер у магазина: есть расписание, есть обязательство поставить товар, есть привязанный способ оплаты или предоплаченный баланс. Значит, появляются новые сущности — сама подписка, её состояние и история списаний, — которых в обычном магазине нет.

Что остаётся за рамками задачи

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

Модель подписки: минимальный набор решений

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

Обязательные параметры модели

• Что подписывается: конкретный товар, набор товаров, категория с правом выбора или пополняемый расходник.
• Периодичность: фиксированный интервал (например, раз в месяц) или календарные даты (каждое 5-е число).
• Способ расчёта: автоматическое списание с привязанного способа оплаты или списание из предоплаченного баланса доставок.
• Момент списания: за сколько дней до отгрузки, в день формирования заказа или в день передачи в доставку.
• Состав следующей поставки: неизменный, выбираемый покупателем или собираемый по правилу.
• Управление: пауза, пропуск одной доставки, замена позиции, изменение адреса, отмена.
• Поведение при сбое: что делать, если оплата не прошла или товара нет в наличии.
• Уведомления: когда и о чём предупреждаем покупателя.

Что фиксируется в карточке подписки покупателя

Карточку подписки видят и покупатель в личном кабинете, и менеджер в административной части. В ней должны быть: состояние (активна, на паузе, отменена), дата следующей поставки, состав, адрес и способ получения, привязанный способ оплаты или остаток доставок, история списаний и изменений. Если карточка неполная, поддержка будет получать вопросы, на которые не сможет ответить без ручного поиска по заказам.

Периодичность оплаты и доступность товара

Это сложная часть модели: расписание привязано к календарю, а склад — к фактическим остаткам. Их нужно согласовать заранее.

Как выбрать интервал

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

Что делать, если товара нет в наличии

Здесь возможны три честных варианта, и один из них нужно выбрать заранее:

• Перенести поставку на ближайшую дату, когда товар появится, и уведомить покупателя.
• Заменить позицию на согласованный аналог — только если покупатель дал на это согласие в правилах подписки.
• Пропустить доставку без списания и сохранить остаток доставок.

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

Приостановка, изменение состава и отмена

Покупатель должен уметь управлять подпиской без обращения в поддержку. Иначе регулярные заказы превращаются в ручную работу менеджера.

Пауза и пропуск доставки

Различайте два действия. Пауза — приостановка на неопределённый срок, следующая поставка не назначается. Пропуск — отмена одной доставки, ритм сохраняется. В обоих случаях нужно решить, до какого момента покупатель может внести изменение: обычно есть «точка невозврата», после которой заказ уже собран и отменять его поздно.

Замена и добавление позиций

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

Отмена и возврат

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

Как подписка связана с заказами, оплатами и отгрузками

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

Заказ как единица учёта

Каждую поставку удобно вести отдельным заказом. Тогда работают привычные инструменты: список заказов, статусы, печать документов, частичные оплаты и частичные отгрузки. Механизмы частичных оплат и отгрузок могут пригодиться, если покупатель оплачивает подписку частями.

Свойства заказа и статусы

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

Оплаты и чеки

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

Логирование изменений

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

Таблица принятия решения: какой вариант подписки выбрать

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

Учебный пример: подписка на кофе с доставкой раз в месяц

Данные ниже условные и приведены только для разбора логики. Это не реальный проект и не статистика.

Входные условия

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

Как проходит цикл

1. Покупатель оформляет подписку и привязывает способ оплаты. В карточке подписки фиксируются состав, адрес, интервал и дата следующей поставки. 2. За три дня до даты система формирует заказ и пытается списать оплату. 3. Если оплата прошла, заказ переходит в работу: сборка, отгрузка, доставка. Покупатель получает уведомление. 4. Если оплата не прошла, заказ не уходит в сборку, покупатель получает уведомление и возможность повторить оплату. Подписка при этом не отменяется автоматически. 5. Если товара нет в наличии, поставка переносится, покупатель уведомляется, списание не производится. 6. После доставки в карточке подписки обновляется дата следующей поставки.

Что проверяем в примере

• Совпадает ли дата следующей поставки в кабинете покупателя и в административной части.
• Не создаётся ли заказ при отсутствии товара.
• Что происходит с подпиской после двух неудачных оплат подряд.
• Применяется ли замена помола к следующей поставке, а не к уже собранной.
• Возвращается ли подписка из паузы в тот же ритм.

Как проверить результат и принять работу

Приёмка подписки — это прогон сценариев на тестовых данных, а не проверка наличия кнопки. Ниже — применимый чек-лист.

• Оформление подписки: состав, интервал, адрес и способ оплаты сохраняются и отображаются в кабинете.
• Формирование заказа: следующая поставка создаётся в ожидаемую дату, а не раньше и не позже.
• Оплата: успешное списание переводит заказ в работу, неуспешное — не запускает сборку.
• Отсутствие товара: поставка переносится или пропускается без списания денег.
• Пауза: следующая поставка не назначается, возобновление возвращает прежний ритм.
• Пропуск одной доставки: ритм сохраняется, остальные поставки не сдвигаются.
• Изменение состава: применяется к следующей поставке, уже собранный заказ не меняется.
• Отмена: будущие поставки прекращаются, неиспользованный остаток обрабатывается по согласованному правилу.
• Уведомления: покупатель получает сообщения о формировании, оплате, переносе и отмене.
• История: изменения заказа и подписки видны в журнале, менеджер может восстановить хронологию.
• Права доступа: менеджер видит подписки и может помочь, но не может изменить данные без основания.
• Возврат: сценарий возврата денег и работа с чеками согласованы с бухгалтерией.

Если магазин работает, перед изменениями сделайте копию, зарезервируйте данные и подготовьте план отката. Проверку удобно проводить на отдельном контуре, а не на боевом сайте. Если нужно оценить текущее состояние магазина перед доработкой, полезен Аудит интернет-магазина — что проверяют и что будет в отчёте — он покажет, какие механизмы уже настроены, а какие придётся добавлять.

Типичные ошибки и ограничения

• Смешивание уведомления о поступлении и регулярных заказов. Это разные задачи, и попытка решить одну через другую даёт запутанную логику.
• Списание без поставки. Если оплата проходит, а товара нет, покупатель теряет доверие. Правило «нет товара — нет списания» стоит закрепить явно.
• Отсутствие «точки невозврата». Без неё покупатель меняет состав после сборки, и заказ приходится пересобирать вручную.
• Молчаливая отмена при неудачной оплате. Подписка не должна исчезать без предупреждения.
• Непрозрачный остаток доставок. Если покупатель не видит, сколько поставок оплачено, он не понимает, за что платит.
• Игнорирование персональных данных и согласий. Хранение способа оплаты и автоматические списания требуют корректного оформления — это зона профильного специалиста.
• Ограничения платформы. Конкретное поведение механизмов подписки, резервирования и чеков зависит от настроек и редакции продукта. Не утверждайте его заранее — проверяйте на тестовом контуре и фиксируйте результат проверки.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, разработчику нужны не пожелания, а конкретика. Подготовьте:

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

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