Первый месяц оплачен. Через месяц сайт снова отправит запрос на списание, но пользователь уже мог отключить продление, сменить карту или уйти с сервиса. Именно на этих переходах и проверяется подписка. В Гуси-Лебеди мы предлагаем начинать с понятных правил для человека, а затем связывать их с платежами и доступом.
Рекуррентные платежи позволяют повторно оплачивать услугу с помощью ранее сохранённого способа оплаты и полученного согласия. Подписка описывает другое: что клиент получает и на какой срок. Её можно продлевать вручную. И наоборот, сохранённая карта ещё не означает действующую подписку. Ниже разберём организацию регулярной оплаты на сайте, от предложения до проверки отмены.
Условия подписки: цена, период и согласие на списания
Представьте условный сервис отчётов с ежемесячным доступом. Покупатель должен понимать не только цену первого месяца. Ему нужно знать дату следующего списания, стоимость продления и путь отказа. Если доступ продаётся на календарный месяц, а программа прибавляет к дате оплаты фиксированное число дней, условия и работа системы могут разойтись.
До подключения договоритесь, что именно считается периодом. Как рассчитывается конец срока при оплате в последний день месяца? Что происходит при переходе на другой тариф? Когда начинает действовать новая цена? Эти решения нельзя оставлять на усмотрение отдельных экранов или фоновой задачи.
Проверка предложения. Прочитайте экран подключения без дополнительных пояснений: «Что я оплачиваю сейчас? Что произойдёт потом? Как остановить следующие списания?» Если для ответа требуется звонить менеджеру, формулировки нужно уточнить.
В инструкции ЮKassa по сохранению способа оплаты получение согласия возложено на магазин. Пользователя требуется предупредить о сумме, периодичности и отказе от дальнейшего использования платёжных данных. Настройка сохранения способа оплаты не заменяет согласие клиента.
При выборе платёжного сервиса сравнивайте доступные для вашего подключения способы оплаты, порядок активации автоплатежей, комиссии и возвраты, тестовую среду и механизм уведомлений. Универсального тарифа для всех подписок нет. В ЮKassa, например, подключение автоплатежей для настоящего магазина нужно согласовать с менеджером, хотя в тестовом магазине они доступны по умолчанию. Общую часть приёма оплаты мы разобрали в статье про эквайринг на сайте.
Отдельно согласуйте документы и фискализацию: кто отвечает за условия услуги, какие данные нужны для чека и как обрабатываются возвраты. Платёжная интеграция должна выполнять эти решения, а не подменять их.
Как работает повторная оплата и продление доступа
Полезно хранить отдельно подписку, оплаченные периоды и платёжные попытки. У одной подписки может быть неудачная попытка, затем успешная. Если оставить только поле «активна», поддержка не сможет объяснить, за какой период пришли деньги и почему изменился доступ.
Рассмотрим тот же условный сервис отчётов. Мы заранее выбрали правило: успешная оплата открывает очередной период; отключение продления прекращает будущие попытки. Это пример проектного решения, а не обязательная схема для любого бизнеса.
- Первое подключение. Клиент видит условия и подтверждает согласие. Система получает результат оплаты и отдельно проверяет, что способ оплаты действительно сохранён для следующих списаний.
- Следующий период. Задача на сервере проверяет состояние подписки и создаёт платёжную попытку для нужного периода. В сценарии ЮKassa с сохранённым способом оплаты используется его идентификатор; периодичность и отключение определяются на стороне магазина.
- Подтверждение результата. До окончательного результата попытка остаётся незавершённой. После подтверждённого успеха система открывает период один раз и сохраняет связь с операцией.
- Неуспешная попытка. Система фиксирует причину, показывает доступное действие и действует по согласованному правилу доступа. Повторять списание или давать дополнительное время нужно по определённому сценарию, а не бесконечно.
Принятый запрос не равен полученным деньгам. В правилах обработки ответов ЮKassa статус pending означает, что результат пока неизвестен. Даже HTTP 500 не доказывает отсутствие операции: документация предусматривает проверку объекта либо повтор с теми же данными и ключом идемпотентности. Новый ключ при каждом техническом повторе способен нарушить защиту от дублей.
Обработчик событий тоже должен выдерживать повторное сообщение. ЮKassa требует подтвердить получение уведомления кодом HTTP 200 и при других ответах продолжает доставку. В документации об уведомлениях также описана проверка их подлинности и текущего статуса объекта. Поэтому доступ нельзя выдавать только по возвращению пользователя на страницу «Спасибо».
При разработке серверной логики регулярной оплаты мы рекомендуем описать эти переходы до написания интеграции. Это помогает проверить неприятный случай: списание подтвердилось, уведомление задержалось, а пользователь в этот момент нажал отмену.
Личный кабинет: отмена продления и понятные статусы
Клиенту не нужна внутренняя схема базы данных. Ему нужны ответы: оплачен ли доступ, когда он закончится и будет ли следующее списание. Отображайте эти сведения из подтверждённого состояния системы. Если данные ещё уточняются, так и напишите.
Для условного сервиса можно подготовить три разных сообщения:
- Оплата ещё проверяется
- «Проверяем результат платежа. Статус обновится после подтверждения». Не предлагайте сразу оплатить повторно, пока исход первой попытки неизвестен.
- Продление отключено
- «Автоматическое продление отключено». Отдельно покажите фактическую дату окончания доступа, если он сохраняется по условиям вашего сервиса.
- Платёж не завершён
- Объясните подтверждённую причину и возможное действие. Нельзя писать «Недостаточно денег», если провайдер сообщил отзыв разрешения или другая причина ещё выясняется.
Разделите управление будущими списаниями, отказ от использования платёжных данных и расторжение договора. Это связанные действия, но их последствия для уже оплаченной услуги и возврата нужно определить в условиях. Кнопка должна запускать реальный переход в системе. Одного исчезновения карты с экрана недостаточно.
Для интернет-услуг по абонентским договорам с 1 марта 2026 года действует важное правило. По разъяснению Роспотребнадзора, исполнитель не вправе использовать прежние платёжные данные для периодических списаний после отказа потребителя от их использования. Приём такого отказа нужно организовать в том числе электронно. Поэтому путь отказа и фиксацию его получения следует включить в требования к сайту.
После отмены остановите соответствующие задачи и проверьте фактическое состояние. Если запрос на оплату уже отправлен, поддержку нужно обеспечить историей событий, а порядок решения согласовать заранее. Не обещайте пользователю результат, который система ещё не подтвердила.
Сотруднику поддержки пригодятся идентификаторы операций, их статусы, оплаченный период, время получения отказа и история действий. Полные реквизиты карты и секреты интеграции в журнал обращений переносить не нужно. Такой журнал должен помогать разобраться в конкретном платеже, а не заставлять сотрудника угадывать причину по общей надписи «Ошибка».
Проверка подписки: дубли, сбои и отмена перед списанием
Успешный первый платёж проверяет только начало пути. Перед запуском пройдите полный цикл в предусмотренной провайдером тестовой среде. Для каждого случая запишите исходное состояние, событие и ожидаемый результат. Например: продление отключено, наступила дата оплаты, новая попытка не создаётся.
Проверьте границы периода. Подключение в конце месяца, смену часового пояса в отображении дат, смену тарифа и повторную покупку при действующем доступе. Ожидаемое поведение должно совпадать с условиями предложения. Там, где результат зависит от выбранного правила, сначала утвердите правило.
Создайте технические повторы. Обработайте одно уведомление дважды, повторно запустите задачу продления и восстановите её после сбоя. Не должно появиться второй оплаченный период из одного платежа или лишняя попытка из повторного запуска. Проверяйте операции у провайдера и записи на сайте, а не только текст сообщения.
Пройдите отмену в неудобный момент. До запуска очередной задачи и после отправки запроса на оплату. Сверьте, какие действия реально успели выполниться, как прекращаются следующие списания и что видят клиент и поддержка. Этот сценарий особенно важен, когда уведомления приходят с задержкой.
Сверьте неуспешную оплату и возврат. Доступ, сообщение, дальнейшая попытка и документы должны соответствовать выбранному сценарию. Проверка в тестовом магазине не подтверждает настройки настоящего подключения: перед запуском отдельно сверяются возможности магазина и рабочая конфигурация.
В руководстве по проверке пользовательских сценариев сайта разбираем фиксацию расхождений. Для подписок добавьте к обычному отчёту платёжные идентификаторы и последовательность событий: именно они помогут воспроизвести ошибку.
После запуска следите за подтверждёнными продлениями, неуспешными попытками и обращениями по отмене. Само количество подключённых подписок не показывает полученную выручку. В Гуси-Лебеди мы рекомендуем передавать вместе с интеграцией правила периодов, схему состояний, результаты проверок и порядок работы поддержки. Тогда регулярная оплата остаётся понятной и для клиента, и для команды, которая обслуживает сайт.