Отмена подписки и удаление аккаунта: как разделить сценарии

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

Какое действие человек собирается совершить

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

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

Подписка, доступ и данные меняются отдельно

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

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

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

Что показать перед последним подтверждением

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

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

Для выгрузки данных заранее объясните состав, доступный формат и срок получения. Проверка полезнее обещания «всё сохранится»: в продукте могут быть вложения, связи и записи разных участников. Не делайте секретный экспорт на посторонний адрес только потому, что человек нажал кнопку отмены.

Когда пользователь передумал

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

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

Как согласовать приложение с платёжной системой

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

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

Приёмка на учебном рабочем пространстве

1. Создайте тестовую организацию без реальных списаний и рабочих данных.
2. Проверьте полномочия сотрудника и владельца на каждое действие.
3. Отмените продление и проверьте сохранение согласованного доступа.
4. Убедитесь, что выгрузка и удаление не запустились без выбора пользователя.
5. Проверьте возобновление до конца периода и сценарий после прекращения.
6. Смоделируйте задержку синхронизации и повторное подтверждение.
7. Проверьте итоговое состояние, историю и понятное уведомление.

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

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