Проверьте, на каком этапе остановился вход: сервис запустил звонок, сайт принял код или браузер получил доступ к аккаунту. Успешный статус Flash Call сам по себе не означает, что пользователь вошёл. Звонок, проверка кода и создание сессии — отдельные этапы, и сбой нужно искать на конкретном переходе. Ниже разберём, что проверить владельцу сайта вместе с разработчиком, как отличить ошибку формы от ошибки интеграции и что показать клиенту, чтобы он не заказывал звонок повторно без необходимости.
Что означает статус «Flash Call прошёл»?
Сначала уточните, где появилась отметка об успехе и что она означает по документации сервиса. Ответ API о приёме запроса подтверждает только то, что сервис принял задачу. Статус звонка описывает следующий этап. Результат проверки кода относится уже к попытке входа на вашем сайте. Объединять эти события в одну отметку «успешно» нельзя: по ней разработчик не поймёт, где искать причину.
Flash Call помогает подтвердить доступ к номеру телефона. Пользователь получает короткий звонок и вводит код из номера, если интеграция предусматривает такой сценарий. Затем сайт проверяет ответ и решает, открыть ли доступ к аккаунту. Даже после верного кода вход остановится, если сайт не найдёт нужный аккаунт или не создаст сессию.
Сессия — это способ, с помощью которого сайт узнаёт пользователя после входа. Благодаря ей при переходе в личный кабинет не приходится подтверждать номер заново. Поэтому полезно отдельно отмечать в техническом журнале запрос звонка, результат проверки кода и результат создания сессии. Сам код для такой диагностики записывать не нужно.
Попросите разработчика связать события одной попытки общим идентификатором. Тогда по обращению «код подошёл, но снова вижу форму входа» можно будет найти всю цепочку, а не искать похожие записи по времени.
Как проверить, что сайт правильно принимает код?
Начните с формы, которую видит клиент. Она должна объяснять, откуда взять код и какие цифры ввести. Количество цифр и способ проверки сверяют с настройками конкретной интеграции. Если интерфейс просит одну часть номера, а сервер ожидает другую, звонок дойдёт, но подтверждение завершится ошибкой.
Следующая проверка касается связи кода с попыткой входа. Серверу нужно понимать, к какому номеру и запросу относится ответ. Особенно легко запутать эту связь, когда клиент открывает сайт в соседней вкладке, меняет номер или повторно запрашивает звонок.
- Сверьте подсказку в форме с тем кодом, который ожидает сервер.
- Проверьте, что форма отправляет ответ для текущей попытки входа.
- Убедитесь, что после нового запроса сайт отклоняет код предыдущей попытки.
- Проверьте срок действия кода на сервере, а не только таймер на экране.
- Посмотрите, какую ошибку сервер возвращает при неверном или просроченном коде.
Сообщение «Что-то пошло не так» не подсказывает следующего действия. Для неверного кода подойдёт текст «Код не подошёл. Проверьте цифры в номере входящего звонка». Для истёкшего срока нужен другой ответ: «Срок действия кода истёк. Запросите новый звонок». Показывайте эти сообщения только тогда, когда сервер подтвердил соответствующую причину.
Повторный запрос тоже требует отдельной логики. В материалах flashcall.by о выборе каскада OTP рекомендуется ограничивать частые запросы, запрещать старый код после выпуска нового и показывать время до следующей попытки. В форме полезно прямо написать, что теперь действует код из последнего звонка.
Почему верный код не открывает личный кабинет?
Если сервер принял код, проверяйте следующий переход: как сайт находит аккаунт и создаёт сессию. Например, подтверждение номера прошло, но сайт не определил, нужно открыть существующий профиль или продолжить регистрацию. Для этих ситуаций нужны разные действия. Сообщение «Вход выполнен» допустимо только после того, как сайт действительно подготовил доступ.
Попросите разработчика проверить ответ сервера после успешного подтверждения. Если сайт использует cookie для сессии, браузер должен принять её и передать при следующем обращении. Cookie — это небольшая служебная запись в браузере. Ошибка в её настройках приводит к ситуации, когда сервер подтвердил вход, а при открытии кабинета снова видит гостя.
Отдельного внимания требует переход между адресами сайта. Форма входа и личный кабинет могут находиться на разных поддоменах, и настройки сессии должны учитывать этот маршрут. Проверять нужно весь путь клиента: от кнопки запроса звонка до обновления страницы кабинета.
Бывает и другой разрыв: сервер создал сессию, но форма продолжает показывать ожидание. Тогда разработчик проверяет, как интерфейс обрабатывает успешный ответ. Кнопка не должна оставаться заблокированной, а сообщение об ошибке от предыдущей попытки нужно убрать. Новый звонок здесь не исправит причину.
Успешную проверку кода нельзя повторно использовать для создания новых сессий. При этом повторный ответ на тот же запрос из-за сетевой задержки не должен запускать противоречивые действия. Это поведение стоит заранее согласовать при API-интеграции: что сайт делает при повторе запроса и какой результат возвращает форме.
Как проверить исправление до запуска?
Выберите один тестовый сценарий и пройдите его от начала до конца. Менять сразу настройки звонка, форму и сессию неудобно: после такого изменения трудно понять, что устранило сбой. Сначала найдите последний успешный этап, затем исправьте следующий переход.
- Пройдите вход с актуальным кодом и проверьте, открылся ли нужный аккаунт.
- Обновите страницу кабинета и убедитесь, что сайт сохраняет вход.
- Запросите новый звонок и проверьте, что старый код больше не подходит.
- Повторите вход в соседней вкладке и проверьте, что попытки не смешиваются.
- Проверьте сценарий с истёкшим кодом: форма должна объяснить, как продолжить.
Для каждого теста зафиксируйте ожидаемый и фактический результат. Например: «После верного кода открывается кабинет; после обновления страницы пользователь остаётся в аккаунте». Такой критерий понятен владельцу бизнеса и разработчику. Отметка «звонок поступил» проверяет только часть сценария.
Отображение звонка и поведение формы стоит проверить на телефонах, которыми пользуются клиенты. Для этой части пригодится материал о проверке Flash Call на iPhone и Android перед запуском. Полную последовательность проверок можно сверить с тест-планом Flash Call перед запуском в Беларуси.
Если подключаете авторизацию через API, включите эти проверки в задачу на интеграцию. В ней должны быть результат проверки кода, создание сессии и понятные сообщения при сбоях. Тогда приёмка охватит рабочий вход в кабинет, а не закончится на факте звонка.
Типичные ошибки при поиске причины
- Считать ответ «запрос принят» подтверждением входа. Исправление: разделить статусы запроса, проверки кода и сессии.
- Предлагать новый звонок при любой ошибке. Исправление: сначала определить, завершилась ли проверка кода; после неё искать сбой в доступе к аккаунту.
- Разрешать проверку старого кода после повторного запроса. Исправление: привязать ответ к актуальной попытке и объяснить это в форме.
- Проверять только первое открытие кабинета. Исправление: добавить обновление страницы и переход в другой раздел после входа.
- Снимать ограничения ради успешного теста. Исправление: проверить лимиты отдельно и сохранить защиту от массовых запросов.
Начните с одного действия: откройте задачу разработчику и добавьте вопрос «На каком этапе обрывается вход: проверка кода, создание сессии или открытие кабинета?».
