Когда последнее списание оказывается первым сбоем

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

Речь об онлайн-услуге для потребителей с платой за периоды. У неё три разные записи: сам договор, разрешённый способ оплаты и отдельная денежная операция за выбранный период. Если всё свести к отметке «активно», сотрудник не узнает, закончился ли доступ, отозвал ли человек способ оплаты или последняя операция ещё ждёт результата провайдера. Для сопровождения удобнее хранить эти состояния раздельно и показать, как каждое меняет клиентский кабинет.

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

Подписка начинается с обещания услуги

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

До подтверждения покажите условия. Клиенту нужны сумма первого платежа, сумма или понятное правило расчёта следующих платежей, периодичность и дата ближайшего списания. При пробном периоде отметьте дату его окончания и объясните, сколько будет стоить следующий период.

Если после пробного доступа меняется цена, покажите её рядом с подтверждением. О будущей сумме узнают до оплаты.

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

Первый платёж и сохранённый способ

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

В документации ЮKassa о привязке при платеже сохранение видно по значению true у payment_method.saved. Тогда исполнитель может связать payment_method.id с клиентом у себя. Проверяйте итог самого платежа отдельно. При одностадийной оплате для начала платного доступа разумно дождаться успешного результата, а если выбран двухстадийный порядок, уточните у исполнителя, где в вашем процессе деньги окончательно списываются и какой статус разрешает выдать доступ. Для начала сравните эту точку с порядком приёмки оплаты на сайте.

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

Наглядный разбор

Как способ оплаты становится доступен для продления

  1. Условия

    Клиент узнаёт цену, период и порядок отказа.

  2. Подтверждение

    Выбирает регулярную оплату и проходит первую операцию.

  3. Связь

    Сервис возвращает идентификатор способа, исполнитель связывает его с подпиской.

Следующий платёж появляется только после подтверждённого подключения.

Продление за один период

Следующую операцию назначает сервис компании. В документации ЮKassa о повторной оплате прямо сказано, что периодичность списаний и отключение автоплатежей настраиваются у продавца. В повторную операцию он передаёт сумму и сохранённый идентификатор в поле payment_method_id. Действие привязывайте к периоду подписки. Тогда случайный повтор расписания обнаружится до списания, даже если в платёжном кабинете ещё нет новой строки.

Перед отправкой сверьте два состояния. Подписка допускает продление на следующий период, а сохранённый способ разрешено использовать.

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

Результат операции приходит отдельно. При ответе pending продолжайте ждать окончательного состояния, а следующий оплаченный период открывайте по подтверждённому успеху. Страница «Спасибо» сообщает клиенту состояние платежа. Доступ к оплаченному периоду система открывает по итоговому состоянию самой операции, которое она получает от платёжного сервиса, даже если клиент уже закрыл страницу и продолжил работу в другом окне. Связь платёжной операции с кабинетом стоит включить в задание на проверку онлайн-оплаты.

Наглядный разбор

Одна операция на один расчётный период

  1. Период

    Записать дату и сумму.

  2. Допуск

    Сверить статус подписки и разрешённый способ.

  3. Исход

    Обновить доступ по подтверждённому результату.

На экране клиента дата и сумма следуют из той же записи, по которой выставлен платёж.

Ошибка, ожидание и повтор

Отклонённая операция требует понятного исхода. В описании автоплатежа ЮKassa при неуспехе указан статус canceled, а причина приходит в cancellation_details. Покупателю достаточно знать, продлился ли доступ и что он может сделать дальше.

Отдельно договоритесь, что видит поддержка, если человек не смог оплатить и хочет заменить способ. У сотрудника должен быть статус, дата и разрешённое следующее действие.

Сетевой сбой оставляет вопрос открытым. Когда система не получила ответ от провайдера, новый запрос с другим ключом может создать ещё один платёж, хотя первый уже был принят. В правилах API ЮKassa для повтора предусмотрен заголовок Idempotence-Key: при тех же данных и ключе запрос обрабатывается как повторный. Защита действует 24 часа с первого запроса. Храните в своём учёте связь подписки, периода и попытки, чтобы после этой границы сверить прежний платёж и выяснить его исход, прежде чем поручать провайдеру списать деньги снова.

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

Отказ от реквизитов и прекращение продления

Клиент может убрать способ оплаты. С 1 марта 2026 года для потребительских услуг по абонентскому договору в интернете действует пункт 4.2 статьи 16.1 закона о защите прав потребителей, внесённый законом № 376-ФЗ. Если человек сообщил исполнителю, что отказывается от использования ранее предоставленных реквизитов банковского счёта или данных электронного средства платежа, использовать их для очередных периодических платежей запрещено. Правило относится к указанному способу расчёта.

Возможность направить отказ нужна и в электронной форме. Роспотребнадзор разъясняет это требование применительно к платным онлайн-подпискам. В кабинете дайте человеку понятное действие и после него покажите, по какому способу принят отказ и будут ли новые попытки. В поддержке используйте тот же результат: сообщение из электронной формы должно остановить применение реквизитов и в рабочей очереди, иначе клиент увидит разные состояния на экране и при списании.

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

Наглядный разбор

Два действия в личном кабинете

  1. Отказ от способа

    Следующий запрос с ранее выбранным средством запрещён.

  2. Отмена подписки

    Меняется сам порядок продления и доступа по договору.

Исполнитель сохраняет смысл того действия, которое выбрал клиент.

Что предъявить при сдаче оплаты

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

ПробаЧто увидит покупательЧто сверит исполнитель
Первый платёж и согласиеЦена, ближайшая дата, условия остановкиФакт оплаты и разрешённый сохранённый способ
Следующий периодТекущий платёж и новый срок доступаОдна успешная операция за период
Сбой связиСостояние ожидания или уточнениеСтарый запрос найден, второй платёж не создан
Отказ от средстваПодтверждение принятия отказаСледующая попытка по этому средству остановлена
Отмена подпискиДата завершения доступа и дальнейший порядокПродление остановлено по правилам услуги

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

Проверка до приглашения действующих клиентов

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

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

Историю прежних покупок сохраняют отдельно: по номеру сотрудник сможет найти исходный платёж и объяснить, к чему он относится, даже если для следующего периода клиент выбрал другой способ расчёта или дату.

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

Источники и полезные ссылки

  1. Роспотребнадзор — отказ от платёжных данных при подписках ↗
  2. ЮKassa — привязка способа во время платежа ↗
  3. ЮKassa — проведение автоплатежа ↗
  4. ЮKassa — формат запросов и защита от повтора ↗

Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →