Не приходит код подтверждения: чек-лист диагностики

Если пользователю не приходит код подтверждения, сначала определите, на каком этапе остановился запрос: форма не создала проверку, VerifyBox отклонил её по параметрам или лимитам, провайдер не принял сообщение либо оператор задержал доставку. Повторная отправка без диагностики может создать ещё несколько сессий, запутать пользователя и зря расходовать баланс.

Правильный порядок — пройти цепочку от номера до итоговой проверки и найти первый этап без подтверждённого результата. Ниже собран практический чек-лист для поддержки, разработчика и владельца формы.

Быстрая проверка за пять минут

До глубокого разбора ответьте на шесть вопросов:

1. Номер передан в правильном международном формате?
2. В VerifyBox создалась сессия проверки?
3. Запрос доставки был передан провайдеру?
4. Провайдер вернул идентификатор сообщения и статус приёма?
5. Не сработали ли лимит, таймер или недостаточный баланс?
6. Пользователь вводит код из последнего сообщения и до окончания срока действия?

Первый ответ «нет» или «неизвестно» определяет направление поиска. Если сессия не создана, бесполезно проверять мобильного оператора. Если провайдер отклонил запрос, изменение времени жизни кода не поможет. Если сообщение доставлено, но пользователь вводит старый код, новая отправка только усложнит ситуацию.

Разделите создание, доставку и проверку кода

В нормальном процессе есть несколько независимых событий:

1. Сайт отправляет запрос на создание проверки.
2. VerifyBox валидирует параметры, применяет лимиты и создаёт сессию.
3. Код передаётся в выбранный канал доставки.
4. Провайдер принимает сообщение и возвращает свой идентификатор.
5. Оператор доставляет сообщение на устройство пользователя.
6. Пользователь вводит код.
7. VerifyBox проверяет срок действия, число попыток и совпадение.
8. Сайт получает результат и продолжает бизнес-сценарий.

VerifyBox отвечает за создание и проверку кода, сессию и защитные ограничения. В рабочем SMS- или voice-сценарии доставку выполняет провайдер, подключённый клиентом. Поэтому «сессия создана» и «SMS доставлено» — не одно и то же состояние.

Такое разделение особенно важно для формы Tilda. Подробный рабочий контур описан в инструкции по подтверждению номера телефона в Tilda.

Шаг 1. Проверьте номер до отправки

Начните с значения, которое фактически ушло из интеграции, а не с того, как оно выглядит на экране. Маска может показывать +7 (999) 123-45-67, а запрос — содержать лишний символ, пропущенный код страны или другую последовательность.

Используйте согласованный нормализованный формат. Для международного сценария обычно сохраняется знак +, код страны и цифры без пробелов. Не подставляйте страну молча, если аудитория вводит номера разных направлений.

Проверьте:

• код страны и длину номера;
• отсутствие букв и служебных символов в передаваемом значении;
• не обрезается ли первая цифра маской;
• совпадает ли номер в интерфейсе и журнале;
• поддерживает ли провайдер это направление;
• не относится ли номер к типу, который канал не обслуживает.

Не публикуйте полный телефон в общей системе аналитики или публичной переписке. Для поддержки достаточно маскированного значения и безопасного идентификатора сессии.

Шаг 2. Исключите причины на устройстве пользователя

Если проблема единичная и сессия с доставкой выглядит нормально, проверьте простые причины:

• телефон находится в авиарежиме или временно без сети;
• сообщения попали в спам или отдельную папку;
• устройство переполнено или приложение сообщений работает со сбоем;
• пользователь указал SIM-карту, которой сейчас нет в телефоне;
• номер находится в роуминге;
• виртуальный номер ограничивает сервисные сообщения;
• оператор задерживает входящие SMS;
• включена блокировка неизвестных отправителей.

Попросите пользователя проверить последние цифры номера, подождать до окончания указанного таймера и только затем повторить запрос. Не советуйте нажимать кнопку много раз подряд.

Если проблема воспроизводится у разных людей, направлений или операторов, переходите к журналам системы и провайдера — это уже не похоже на одно устройство.

Шаг 3. Убедитесь, что сессия VerifyBox создана

Если сессия не появилась, код ещё не дошёл до канала доставки. Ищите ошибку в запросе или правилах проекта.

Типичные причины:

• неверный идентификатор проекта;
• ошибка авторизации;
• обязательный параметр отсутствует;
• номер не прошёл валидацию;
• домен или форма не соответствуют настройкам;
• достигнут лимит проекта;
• предыдущий запрос ещё находится в периоде ожидания;
• интеграция использует тестовую конфигурацию на рабочем сайте.

Сопоставьте время нажатия с записью в журнале. Если пользователь говорит о 12:10, а ближайшая сессия создана в 12:03, это может быть другой запрос. Часовой пояс интерфейса и сервера тоже должен быть понятен поддержке.

Не создавайте новую сессию автоматически при любой ошибке фронтенда. Сначала выясните, был ли предыдущий запрос принят. Иначе один клик может превратиться в несколько сообщений и несколько действительных кодов.

Шаг 4. Проверьте ответ провайдера доставки

После успешного создания сессии найдите соответствующий запрос у провайдера. Нужны как минимум идентификатор сообщения, время, направление и последний статус.

Проверьте:

• принял ли провайдер запрос;
• вернул ли он идентификатор сообщения;
• достаточно ли средств на балансе;
• разрешены ли имя отправителя и шаблон;
• поддерживается ли страна и мобильная сеть;
• не заблокировано ли направление настройками аккаунта;
• какой статус вернулся после передачи оператору;
• есть ли код или описание ошибки.

Статус accepted или «принято» часто означает только то, что платформа провайдера получила запрос. Для ответа о фактической доставке нужен отдельный статус, если провайдер и оператор его поддерживают.

Если запрос отклонён из-за баланса, шаблона или направления, повтор через минуту даст тот же результат. Сначала устраните причину. Если провайдер принял сообщение, но финального статуса долго нет, зафиксируйте идентификатор и обратитесь в его поддержку.

Шаг 5. Проверьте лимиты и таймер повторной отправки

Защитные ограничения предотвращают перебор и расходование баланса. Для пользователя срабатывание лимита иногда выглядит как «код не приходит», особенно если интерфейс показывает общую ошибку.

Проверьте ограничения:

• на конкретный номер;
• на сессию;
• на проект;
• на IP или иной риск-сигнал, если он используется;
• на число запросов за короткий период;
• на количество неверных вводов;
• на повтор после блокировки.

Интерфейс должен различать «сообщение отправляется», «повтор доступен через 30 секунд» и «лимит исчерпан». Общая надпись «Попробуйте ещё раз» провоцирует новые клики, хотя следующий запрос всё равно будет отклонён.

При расследовании не повышайте лимиты на всём проекте только ради одного теста. Лучше использовать контролируемую тестовую среду и понять, какое правило сработало.

Шаг 6. Исключите конфликт нескольких кодов

Пользователь запросил первый код, не дождался, нажал повторно, а затем получил два сообщения в обратном порядке. Если система принимает только последний код, ввод первого закончится ошибкой, хотя цифры получены из настоящего SMS.

Заранее выберите и документируйте правило:

• действителен только последний созданный код;
• предыдущий код остаётся действительным в ограниченном окне;
• повторный запрос продлевает текущую сессию без создания нового кода.

Какой бы вариант ни использовался, интерфейс и журнал должны говорить об одном и том же. После повторной отправки полезно явно написать: «Используйте код из последнего сообщения».

Не показывайте в журнале сам код ради удобства поддержки. Для сопоставления достаточно идентификаторов сессии и сообщения.

Шаг 7. Проверьте срок действия и серверное время

Код может прийти, когда срок уже почти закончился, особенно при задержке оператора. Слишком короткий TTL ухудшает пользовательский опыт; слишком длинный увеличивает окно для злоупотребления.

Проверьте:

• когда сессия была создана;
• когда провайдер принял сообщение;
• когда оно фактически доставлено, если статус доступен;
• когда пользователь отправил код на проверку;
• какое серверное время использует система;
• не расходятся ли часовые пояса в журнале.

Таймер в браузере помогает пользователю ориентироваться, но источником истины остаётся сервер. Изменение времени на телефоне или зависшая вкладка не должны продлевать срок действия.

Если задержки характерны для конкретного направления, корректируйте канал и TTL на основе наблюдений, а не случайного значения из другой интеграции.

Шаг 8. Разберите ошибку проверки кода

Сообщение пришло — это ещё не конец диагностики. Код может быть отклонён из-за:

• опечатки пользователя;
• ввода кода из старой сессии;
• истёкшего срока действия;
• превышения числа попыток;
• изменения номера после отправки;
• повторного запроса, который сделал предыдущий код недействительным;
• передачи кода не в тот проект или сценарий;
• ошибки связи между формой и результатом VerifyBox.

Разделяйте эти состояния в интерфейсе. «Неверный код» и «Время истекло» требуют разных действий. В первом случае пользователь исправляет цифры, во втором — запрашивает новый код после разрешённого таймера.

На форме Tilda проверьте также, что поле ввода появляется внутри виджета и связано с текущим номером. После успешной проверки изменение телефона должно сбрасывать результат.

Что записывать в журнал для диагностики

Хороший журнал позволяет восстановить цепочку без доступа к секретам и содержимому сообщения. Сохраняйте:

• время события с часовым поясом;
• идентификатор проекта;
• идентификатор сессии VerifyBox;
• маскированный или защищённый номер;
• выбранный канал;
• идентификатор сообщения провайдера;
• нормализованный статус;
• код категории ошибки;
• длительность между этапами;
• источник запроса или форму.

Не сохраняйте одноразовый код, ключ API, полный текст авторизации и лишние персональные данные. Доступ к диагностическому журналу должен быть ограничен теми, кому он нужен для поддержки.

События полезно связывать одним корреляционным идентификатором. Тогда запрос на сайте, сессия VerifyBox и сообщение провайдера находятся без ручного сравнения телефонов.

Как локализовать массовую проблему

Если обращения приходят сразу от нескольких пользователей, сгруппируйте их по признакам:

• страна и оператор;
• SMS, звонок или Telegram;
• провайдер;
• проект и форма;
• браузер и версия сайта;
• время начала проблемы;
• статус сообщения;
• код ошибки.

Проблема только у одного оператора указывает на маршрут доставки. Ошибка во всех направлениях после публикации сайта — на интеграцию или конфигурацию проекта. Нормальная доставка при нулевой успешной проверке — на срок действия, новые коды или передачу результата.

Не меняйте одновременно провайдера, лимиты, шаблон и скрипт страницы. Иначе после восстановления будет непонятно, что именно помогло.

Когда предложить другой канал

Резервный канал полезен, если основной действительно нестабилен, а не когда сессия создаётся с ошибкой. Если провайдер клиента поддерживает звонки, можно предложить получение кода звонком. На тарифе Business доступна отправка через Telegram по каналу VerifyBox за 2,5 ₽ за сообщение.

Переключение должно быть осознанным:

• не запускайте два платных канала одновременно без согласия пользователя;
• сохраняйте общие лимиты на проверку;
• объясните, куда придёт код;
• не показывайте канал, недоступный для данного номера;
• учитывайте стоимость и правила конкретного сценария.

Если VerifyBox отклоняет запрос по лимиту или номер передан неверно, смена SMS на звонок не устранит исходную причину.

Как улучшить интерфейс и сократить обращения

Часть проблем «код не пришёл» возникает из-за неясного состояния формы. Хороший интерфейс заранее отвечает на вопросы пользователя.

После запроса покажите:

• маскированный номер получателя;
• выбранный канал;
• подтверждение, что запрос принят;
• таймер до повторной отправки;
• возможность исправить номер;
• подсказку использовать последнее сообщение;
• отдельное сообщение при лимите или технической ошибке.

Не переносите поле кода далеко от номера и не очищайте уже заполненные поля формы. На мобильном устройстве ввод должен оставаться видимым над клавиатурой. Автозаполнение из SMS ускоряет сценарий, но пользователь всё равно должен иметь возможность ввести цифры вручную.

Если форма собирает лиды, после подтверждения явно покажите, что остался финальный шаг — отправить заявку. Иначе часть людей решит, что получение зелёной отметки уже завершило процесс.

Профилактический чек-лист перед рабочим запуском

• тестовый и рабочий проекты разделены;
• номер нормализуется одинаково на всех этапах;
• провайдер поддерживает нужные направления;
• баланс и шаблон проверены;
• статусы провайдера сохраняются;
• таймер повторной отправки виден пользователю;
• лимиты действуют на серверной стороне;
• старые и новые коды обрабатываются по одному правилу;
• срок действия учитывает реальную скорость доставки;
• код не попадает в логи и аналитику;
• поддержка знает, где найти идентификаторы сессии и сообщения;
• резервный канал включается только при подходящем сценарии.

Актуальные параметры интеграции проверяйте в открытой документации VerifyBox. Устаревший фрагмент кода или неверный проект может выглядеть как проблема доставки, хотя сообщение даже не было запрошено.

Какие данные передать в поддержку

Чтобы обращение не превратилось в переписку «у нас не работает», подготовьте:

1. Время запроса и часовой пояс.
2. Маскированный номер и страну.
3. Проект, форму и страницу.
4. Канал доставки.
5. Идентификатор сессии VerifyBox.
6. Идентификатор сообщения провайдера, если он создан.
7. Последний нормализованный статус и код ошибки.
8. Был ли код получен позже и какой именно ввод отклонён — первый или последний.
9. Воспроизводится ли проблема на другом номере того же оператора.

Не отправляйте секретный ключ и сам код в открытый чат. Если проблема относится к провайдеру, его поддержке понадобится собственный идентификатор сообщения, а не только номер сессии VerifyBox.

Вопросы о недоставленном коде

Сколько ждать SMS-код перед повторной отправкой?

Ориентируйтесь на таймер интерфейса и реальные данные выбранного провайдера. Не нажимайте повторно до разрешённого времени: новый запрос может сделать предыдущий код недействительным.

Сессия создана, но идентификатора сообщения нет. Где ошибка?

Вероятно, цепочка остановилась до успешного приёма провайдером. Проверьте конфигурацию канала, баланс, шаблон, поддерживаемое направление и ответ интеграции доставки.

Провайдер пишет «принято», но SMS нет. Что это значит?

Часто статус подтверждает приём запроса платформой, а не доставку на телефон. Найдите следующий статус оператора или обратитесь к провайдеру с идентификатором сообщения.

Почему правильный код может не приниматься?

Он мог истечь, относиться к предыдущей сессии, стать недействительным после повтора или превысить лимит попыток. Сопоставьте ввод с последним запросом и серверным временем.

Стоит ли сразу переключать пользователя на другой канал?

Только если проблема действительно в доставке текущего канала. Ошибка номера, лимита или сессии повторится и после смены SMS на звонок.

Как защититься от бесконечных повторных SMS?

Используйте таймер, лимит на номер и проект, ограничение попыток и серверную проверку частоты. Дополнительные уровни разобраны в статье о защите форм Tilda от спама.

Итог

Когда не приходит код подтверждения, не начинайте с повторной отправки. Сначала найдите первый этап без успешного результата: нормализация номера, создание сессии, передача провайдеру, доставка оператором или проверка введённого кода. Такая последовательность сокращает время диагностики, сохраняет баланс и даёт пользователю точный следующий шаг.

Для проверки пользовательского сценария откройте демо VerifyBox, для настройки формы используйте руководство по Tilda, а актуальные варианты подключения и каналов смотрите в разделе стоимости. Если проблема воспроизводится и у вас есть идентификаторы, свяжитесь с VerifyBox с безопасным набором диагностических данных.