Восстановление пароля через Flash Call строится так: пользователь указывает номер телефона, сервис делает короткий входящий звонок, а человек вводит последние цифры номера на странице сброса доступа. Такой сценарий подходит для личного кабинета интернет-магазина, сервиса записи, приложения или закрытого раздела сайта. В статье разберём путь пользователя, требования к API и проверки, которые помогут запустить авторизацию без лишних экранов.
Как выглядит восстановление доступа через Flash Call?
Пользователь открывает форму «Забыли пароль?», вводит номер телефона и нажимает кнопку продолжения. Система проверяет формат номера и создаёт одноразовую попытку подтверждения. После этого Flash Call отправляет на указанный номер короткий входящий звонок.
Кодом становится часть номера, обычно последние цифры входящего звонка. Пользователь видит номер на экране телефона, возвращается в браузер и вводит код в форму. Сервер сравнивает введённые цифры с ожидаемым значением и, если проверка успешна, разрешает задать новый пароль.
В сценарии участвуют четыре элемента:
- форма восстановления доступа на сайте или в приложении;
- сервер, который создаёт попытку и проверяет код;
- интеграция Flash Call через API или веб-хук;
- экран ввода цифр и установки нового пароля.
Полезно заранее описать этот процесс в одном предложении для интерфейса: «Мы позвоним на ваш номер, введите последние цифры входящего звонка». Пользователь сразу понимает, что делать с пропущенным вызовом.
Как настроить сценарий сброса пароля по шагам?
1. Найдите учётную запись по номеру
После ввода номера система ищет пользователя в базе личного кабинета. Если номер найден, приложение создаёт временную сессию восстановления. Если записи нет, интерфейс может показать нейтральное сообщение, чтобы не раскрывать наличие конкретного аккаунта.
На этом этапе не стоит сразу менять пароль. Сначала нужно подтвердить, что доступ к номеру есть у человека, который начал процедуру. Сам пароль пользователь задаёт только после успешной проверки звонком.
2. Создайте попытку подтверждения
Сервер формирует идентификатор попытки, срок её действия и ожидаемый код. Идентификатор связывает звонок с конкретным запросом пользователя. Это важно, если один человек несколько раз нажал кнопку или открыл восстановление в двух вкладках.
Для каждой новой попытки нужен новый код. Старый код после успешной проверки следует закрывать, чтобы его нельзя было применить повторно. Количество попыток ввода также лучше ограничить на уровне сервера, а не только в интерфейсе.
3. Передайте номер в Flash Call
Приложение отправляет запрос на API сервиса авторизации. В запросе обычно передают номер, идентификатор операции и параметры, необходимые для обратного уведомления о звонке. После создания вызова система получает статус операции и ждёт данные о входящем звонке.
Техническая схема может выглядеть так:
- браузер отправляет номер на сервер сайта;
- сервер создаёт попытку восстановления;
- сервер передаёт номер в Flash Call;
- сервис отправляет входящий звонок;
- информация о звонке приходит в приложение через веб-хук;
- пользователь вводит цифры, а сервер проверяет их.
Веб-хук нужен, чтобы приложение получило сведения о звонке автоматически. Практическое описание подключения веб-хука и проверки номера приведено в материале как проверить номер звонком и настроить Flash Call для бизнеса.
4. Покажите понятный экран ожидания
После запуска звонка экран должен объяснить следующий шаг: посмотреть входящий вызов и ввести последние цифры номера. Кнопка «Отправить код повторно» не должна появляться сразу. Сначала дайте завершиться текущей попытке, иначе пользователь получит несколько звонков и не поймёт, какой код вводить.
Если звонок не поступил, добавьте действия «Позвонить ещё раз» и «Изменить номер». При повторе сервер создаёт новую попытку и закрывает предыдущую. В интерфейсе лучше показывать обратный отсчёт до повторной отправки, но не обещать точное время доставки, если оно зависит от телефонной сети.
5. Разрешите задать новый пароль
После правильного ввода цифр сервер помечает попытку как подтверждённую и выдаёт короткоживущий токен восстановления. Этот токен открывает только форму смены пароля. Он не должен давать доступ к личному кабинету до завершения процедуры.
Форма нового пароля должна проверять минимальные требования ещё до отправки. После сохранения пароля токен нужно закрыть, а старые сессии пользователя завершить, если такая логика подходит продукту. Так восстановление доступа не превращается в параллельный вход с давно открытого устройства.
Почему Flash Call подходит для сброса пароля?
Пользователю не нужно искать текст сообщения среди уведомлений. Он видит входящий вызов и использует цифры номера как одноразовое подтверждение. Для человека, который восстанавливает доступ с телефона, такой путь требует одного поля и одного действия после звонка.
Call-based каналы применяют короткий звонок или телефонный вызов с кодом вместо текстового сообщения. Их используют в сценариях аутентификации, когда нужно подтвердить номер и быстро продолжить вход (IBZ Source). При этом Flash Call не отменяет необходимость продумать резервный путь для случаев, когда телефон выключен, абонент занят или звонок не отобразился.
Для малого бизнеса полезно начинать с одного сценария: сброса пароля в личном кабинете. Так проще проверить путь от формы до API, настроить статусы и понять, где пользователи прекращают процедуру. После этого тот же механизм можно адаптировать для подтверждения заказа или напоминания клиенту, если такие задачи есть в продукте.
Какие проверки нужны на стороне сервера?
Главное правило — считать подтверждённым только тот номер, который прошёл проверку в текущей попытке. Нельзя принимать код, который пришёл из браузера как готовый результат. Браузер передаёт введённые цифры, а сервер самостоятельно сравнивает их с данными операции.
- Связывайте попытку с конкретным номером и идентификатором операции.
- Закрывайте код после успешной проверки.
- Ограничивайте число неверных вводов.
- Не разрешайте повторное использование старой попытки.
- Проверяйте срок действия кода на сервере.
- Разделяйте подтверждение номера и установку нового пароля.
Отдельно проверьте повторную отправку звонка. Если пользователь нажал кнопку несколько раз, в системе не должно появиться несколько активных кодов для одной формы. При новом запросе приложение закрывает старую операцию и показывает пользователю только актуальный сценарий.
Какие ошибки мешают восстановить пароль?
- Код проверяется в браузере. Пользователь может изменить JavaScript или отправить собственный запрос, поэтому проверку выполняет сервер.
- Старая попытка остаётся действительной. После повторного звонка предыдущий код нужно закрыть.
- Пользователь не понимает, какие цифры вводить. Напишите прямо: «Введите последние цифры номера входящего звонка».
- Нет состояния для незавершённого звонка. Сервер должен различать созданную, подтверждённую, просроченную и отменённую попытку.
- Форма сразу сообщает, существует ли аккаунт. Нейтральный текст снижает риск раскрытия списка зарегистрированных номеров.
- Смена пароля доступна по одному открытому экрану. После подтверждения выдавайте отдельный временный токен, который действует только для сброса.
Перед запуском проверьте сценарий на нескольких устройствах и в разных состояниях: номер занят, звонок пропущен, пользователь запросил повтор, код введён с ошибкой, страница обновлена. Такой тест быстро показывает, где интерфейс теряет связь с операцией на сервере.
3 шага, которые можно сделать на этой неделе:
- Нарисовать путь пользователя от кнопки «Забыли пароль?» до сохранения нового пароля.
- Описать состояния попытки: создана, звонок получен, подтверждена, просрочена, отменена.
- Подключить тестовый вызов через Flash Call, принять данные веб-хука и проверить повторные попытки.
После такой проверки команда получает понятный сценарий, который можно встроить в личный кабинет без перестройки всей авторизации. На сайте flashcall.by подобную услугу можно заказать для авторизации по звонку, подтверждения заказов и напоминаний клиентам, выбрав только нужный бизнес-процесс.


