Лимиты повторов при авторизации по звонку помогают остановить лишние попытки, когда пользователь несколько раз запрашивает код, бот перебирает номера или сайт получает всплеск заявок. Для малого бизнеса достаточно заранее определить задержку между запросами, число попыток на один номер и правило перехода на резервный канал. В статье разберём, как собрать такую схему без сложной антифрод-системы, проверить её перед запуском и не платить за одинаковые звонки.
Почему повторные запросы увеличивают расходы на авторизацию?
Каждый новый запрос запускает отдельную попытку подтверждения номера. Если посетитель несколько раз нажимает кнопку «Получить код», система может сделать несколько звонков подряд, хотя первый уже поступил. Такая ситуация встречается, когда человек не заметил входящий вызов, связь задержалась или страница долго показывает загрузку.
Отдельная проблема — автоматические запросы. Бот отправляет формы с разными номерами либо многократно использует один номер, чтобы создать нагрузку и потратить лимит звонков. Простое ограничение повторов не заменяет полноценную защиту во всех сценариях, но закрывает базовый источник лишних попыток.
Flash Call работает через короткий входящий звонок: пользователь сверяет цифры номера, с которого поступил вызов, с кодом на экране. Voice OTP передаёт код голосом во время звонка. Для обоих вариантов полезны одинаковые ограничения: не запускать второй вызов, пока действует первый код, и не разрешать бесконечные повторы.
Короткий звонок для Flash Call обычно создаётся за несколько секунд, поэтому пользователь часто успевает получить код до того, как решит нажать кнопку повторно (Messaggio Multichannel Messaging Platform). Интерфейс всё равно должен ясно показать, что запрос уже отправлен: например, вывести текст «Звонок отправлен, проверьте входящие» и таймер до следующей попытки.
Какие лимиты задать для одного номера?
Начать стоит с трёх правил: срока действия кода, паузы перед повторной отправкой и общего числа попыток. Их настраивают на стороне сайта или приложения и в API-процессе поставщика звонков. Главное — связать правила с номером телефона и с конкретной сессией пользователя, иначе посетитель обновит страницу и получит новую серию запросов.
| Правило | Что ограничивает | Практический смысл |
|---|---|---|
| Срок действия кода | Время, в течение которого код принимается | Пока код действует, повторный звонок не нужен: сначала предложите пользователю проверить входящие. |
| Пауза перед повтором | Частоту нажатий кнопки | Таймер убирает серию случайных запросов, когда страница отвечает с задержкой. |
| Лимит попыток на номер | Число запросов в выбранный период | После достижения лимита сайт временно прекращает отправку и показывает понятное сообщение. |
| Лимит на IP или сессию | Поток запросов с одного источника | Помогает, когда бот меняет номера, но продолжает работать из одной сессии или сети. |
Не стоит копировать чужие значения без проверки. Интернет-магазин подтверждает номер перед оформлением заказа, а сервис записи — перед созданием личного кабинета. В первом случае человек часто торопится и может повторить запрос. Во втором полезнее остановить серию попыток и предложить вернуться позже. Лимит выбирают после просмотра реальных причин повторов в журнале событий.
Как выглядит рабочая логика повторной авторизации?
Сценарий лучше описать до интеграции. Тогда разработчик, менеджер сайта и сотрудник поддержки одинаково понимают, что происходит после каждого нажатия кнопки. Для этого достаточно схемы из нескольких шагов.
- Пользователь вводит номер и запрашивает подтверждение.
- Сайт проверяет, нет ли активного кода для этого номера и текущей сессии.
- Если код активен, сайт показывает оставшееся время и не создаёт новый звонок.
- После окончания паузы пользователь получает право запросить повтор.
- Когда число попыток достигает лимита, сайт прекращает отправку на установленный срок.
- Если звонок не прошёл по технической причине, система фиксирует статус и использует заранее выбранный резервный канал.
Последний пункт нужен отдельно от лимита. Отказ в повторе и техническая ошибка — разные ситуации. Если поставщик вернул ошибку доставки, нет смысла считать её полноценной попыткой пользователя. А если человек пять раз подряд запросил код и ни разу его не ввёл, следующий вызов лучше временно не отправлять.
Резервный канал выбирают по задаче и доступности. SMS остаётся понятным вариантом, но у SMS бывают задержки и блокировки операторскими фильтрами. Flash Call в последние годы также сталкивается с фильтрами, которые блокируют роботизированные звонки; поэтому для части сценариев используют голосовой звонок с кодом или каскад из нескольких каналов (Журнал Mindbox о разумном бизнесе).
Для каскада заранее задают порядок: сначала звонок, затем резервный канал только при конкретном статусе ошибки или после исчерпания одной разрешённой попытки. Если включить все каналы одновременно, расходы вырастут, а пользователь получит несколько кодов и не поймёт, какой вводить.
Как проверить лимиты до запуска на сайте?
Тестировать стоит на отдельном наборе номеров и сценариев, а не только по успешному входу. Проверьте обычную авторизацию, повторный запрос до окончания таймера, обновление страницы, смену устройства и ввод неверного кода. Отдельно воспроизведите ситуацию, когда пользователь получил звонок, но не завершил форму.
В журнале событий полезно хранить технические статусы: запрос создан, звонок отправлен, код подтверждён, пользователь запросил повтор, лимит сработал. Эти записи помогают увидеть, где теряются люди. Например, если повторов много сразу после первого запроса, стоит проверить текст на кнопке, работу таймера и скорость ответа сайта.
При API-интеграции разработчик может передавать идентификатор попытки и получать статус звонка обратно в систему сайта. Так легче отличить сбой доставки от повторного клика. Если авторизация связана с заявками, заказами или записью, правила полезно согласовать с CRM: один и тот же номер не должен порождать несколько одинаковых лидов из-за повторной проверки.
На случай проблем со связью пригодится отдельный сценарий: пользователь видит, что запрос принят, но сервис временно не может завершить подтверждение. Подробнее о таком подходе можно прочитать в материале как авторизация по звонку работает при сбоях связи.
Типичные ошибки при настройке повторов
- Разрешить повторный вызов сразу после первого клика и не показывать пользователю таймер.
- Считать техническую ошибку доставки использованной попыткой и блокировать человека без объяснения.
- Хранить лимит только в браузере: после обновления страницы он пропадает.
- Ограничивать один номер, но не учитывать поток запросов из одной сессии или с одного IP-адреса.
- Отправлять резервный код автоматически вместе со звонком, не дожидаясь понятного статуса.
- Не проверять журнал попыток после запуска и узнавать о лишних звонках только по счёту.
3 шага, которые можно сделать на этой неделе:
- Опишите текущий путь пользователя от ввода номера до успешного подтверждения и отметьте места, где он может запросить код повторно.
- Задайте срок действия кода, паузу перед повтором и предел запросов для номера, сессии и IP-адреса.
- Подключите журнал статусов через API и через несколько дней проверьте, какие причины повторов встречаются чаще всего.
Лимиты повторов работают, когда сайт различает активный код, ошибку доставки и подозрительную серию запросов. Такая схема уменьшает число лишних звонков, оставляет пользователю понятный путь подтверждения и даёт бизнесу данные для дальнейшей настройки авторизации.
