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