Каскад OTP для бизнеса распределяет попытки подтверждения номера между несколькими каналами. Сначала система предлагает Flash Call, затем при сбое запускает Voice OTP, а после следующей неудачи отправляет SMS-код. Такой порядок помогает не терять пользователя из-за особенностей устройства, сети или ограничений канала. В статье разберём, чем отличаются три способа, как выбрать приоритет и какие правила заложить в API-интеграцию.
Что такое Flash Call, Voice OTP и SMS-код?
Flash Call — короткий входящий звонок, по которому сервис подтверждает номер телефона. В некоторых сценариях приложение считывает последние цифры номера автоматически. Пользователь видит вызов и получает подтверждение без ручного ввода текста. Если автоматическое считывание недоступно, номер могут попросить ввести вручную.
Voice OTP работает через голосовой звонок. Робот набирает клиента и произносит одноразовый код, который пользователь вводит в форме. Такой вариант подходит для устройств и приложений, где Flash Call нельзя обработать автоматически. В материалах Unibell описан сценарий, при котором робот повторяет код дважды, чтобы снизить риск ошибки при вводе.
SMS-OTP отправляет код в текстовом сообщении. Этот способ знаком пользователям и подходит почти для любого телефона, но доставка зависит от работы SMS-канала. Задержка, фильтрация или ограничения оператора могут помешать клиенту вовремя завершить вход. Поэтому SMS разумно оставлять в каскаде как отдельный резервный путь, а не рассчитывать на него в каждой первой попытке.
Коротко о различиях:
| Канал | Как получает код клиент | Где особенно уместен | Что предусмотреть |
|---|---|---|---|
| Flash Call | По входящему короткому звонку, иногда с автоматическим считыванием номера | Регистрация, вход, подтверждение действия в приложении | Резерв, если приложение не распознало вызов или звонок не прошёл |
| Voice OTP | Робот произносит одноразовый код | Устройства без автоматической обработки Flash Call | Повтор кода, понятная форма ввода и ограничение повторных попыток |
| SMS | Пользователь получает текстовое сообщение с кодом | Запасной канал для телефонов и сценариев, где звонок неудобен | Срок действия кода, повторная отправка и защита от частых запросов |
Подробное сравнение call-based каналов и SMS описано в материале Voice OTP для бизнеса, если SMS не приходит. Для команды без большого штата это удобная основа перед постановкой задачи разработчику.
Какой порядок каналов выбрать для малого бизнеса?
Начните со сценария, а не с названия технологии. Для входа в личный кабинет важны скорость и минимальное число действий. Для подтверждения оплаты или смены номера на первом месте стоит контроль повторных запросов и понятная фиксация результата. Одинаковый каскад для всех действий часто создаёт лишние звонки и обращения в поддержку.
Практичная базовая схема выглядит так: сначала Flash Call, затем Voice OTP, после этого SMS. Первый канал подтверждает номер без чтения сообщения. Голосовой код помогает пользователю, если приложение не распознало вызов. SMS закрывает сценарии, где входящий звонок недоступен или клиенту проще скопировать текст.
Для веб-сайта порядок может быть иным. Браузер не всегда получает доступ к данным входящего вызова так, как мобильное приложение, поэтому Flash Call может потребовать ручной ввод цифр. В таком случае Voice OTP или SMS стоит показывать раньше, если тесты подтверждают, что пользователи чаще завершают вход именно так.
При выборе учитывайте четыре вопроса:
- Есть ли у приложения возможность распознать входящий вызов?
- Что увидит человек, если звонок завершится раньше, чем он откроет телефон?
- Сколько времени действует один код?
- Как система поймёт, что пора переходить к следующему каналу?
Ответы лучше закрепить в отдельной схеме для регистрации, входа, восстановления доступа и подтверждения чувствительных действий. Тогда разработчик не будет самостоятельно трактовать слово «повторить» и случайно запускать несколько каналов одновременно.
Как построить каскад OTP в API?
Каждый запрос на подтверждение должен получать внутренний идентификатор. По нему система связывает номер телефона, выбранный канал, время отправки и результат проверки. Сам код при этом не показывают в интерфейсе и не передают в ответе API.
Логику перехода между каналами задайте явно. Например, после запроса Flash Call система ждёт событие подтверждения до установленного срока. Если событие не пришло, пользователь нажимает «Получить код голосом». После неудачной голосовой попытки появляется вариант с SMS. Автоматический переход допустим, если он не запускает звонок и SMS одновременно.
Для каждого канала нужны отдельные статусы. Минимальный набор может включать:
- запрос создан;
- канал запущен;
- доставка подтверждена или завершилась ошибкой;
- код введён верно;
- код истёк;
- попытки исчерпаны.
Такая детализация помогает понять, где возник сбой. Если звонок отправлен, но пользователь не подтвердил номер, проблема может быть в интерфейсе. Если API вернул ошибку до запуска звонка, проверять нужно интеграцию. Если Voice OTP сработал, а SMS не понадобилась, каскад сделал свою работу и не создал лишнее действие.
Лимиты лучше задавать отдельно для номера, устройства и сессии. Ограничьте частые повторные запросы, запретите проверку старого кода после выпуска нового и показывайте пользователю время до следующей попытки. Практические правила для повторных запросов разобраны в материале как настроить лимиты и повторные попытки при Flash Call.
Как проверить каскад до запуска?
Тестируйте не только успешный вход. Проверьте задержку, отмену звонка, неверный код, истёкший код, повторную отправку и переход между каналами. Отдельно пройдите сценарий на мобильном интернете и через Wi‑Fi, на сайте и в приложении, если бизнес использует оба интерфейса.
Для небольшого проекта достаточно собрать таблицу тестов. В ней укажите условие, ожидаемый канал, фактический результат и текст, который видит клиент. Например: «Flash Call не распознан», «Voice OTP произнёс код», «SMS отправлено после ошибки голосового канала». Такая запись быстро показывает места, где пользователю непонятно, что делать дальше.
Измеряйте не только доставку. Смотрите, сколько пользователей запросили код, сколько завершили проверку, сколько раз нажали повтор и на каком этапе остановились. Эти показатели подскажут, какой канал сделать первым. Если после звонка люди часто выбирают SMS, проверьте время ожидания и формулировку кнопки, прежде чем менять всю архитектуру.
Какие ошибки чаще всего ломают авторизацию?
- Запуск нескольких каналов сразу. Пользователь получает звонок и SMS почти одновременно, путает коды и повторяет попытку. Следующий канал запускайте после понятного события или действия.
- Один срок действия для всех сценариев. Вход, восстановление доступа и подтверждение платежа требуют разных правил. Настройте время действия кода по операции.
- Бесконечная кнопка «Отправить ещё раз». Она увеличивает нагрузку и мешает понять причину сбоя. Показывайте обратный отсчёт и ограничение попыток.
- Отсутствие понятного объяснения. Фраза «код отправлен» не подходит, если клиенту поступит звонок. Пишите: «Ожидайте входящий звонок» или «Робот продиктует код».
- Проверка только позитивного сценария. Если команда тестирует лишь верный код, переход на резервный канал останется непроверенным. Добавьте ошибки доставки и истечение срока.
3 шага, которые можно сделать на этой неделе:
- Опишите отдельно сценарии регистрации, входа и восстановления доступа.
- Назначьте для каждого сценария первый канал и условия перехода к Voice OTP или SMS.
- Проведите тесты с ошибками доставки, повторами и истёкшими кодами, затем передайте разработчику таблицу статусов.
Для малого бизнеса рабочий каскад обычно начинается с простого правила: Flash Call проверяет номер без ручного ввода, Voice OTP принимает пользователя при сбое звонка, а SMS остаётся резервом. Точный порядок зависит от интерфейса и статистики ваших попыток. Если API сразу фиксирует статусы, лимиты и причину перехода, авторизацию по звонку можно подключать как масштабируемый OTP-сценарий без переделки всей системы при росте нагрузки.
