Как настроить срок жизни SMS с кодом подтверждения в SMPP?

Укажите срок жизни SMS в параметре validity_period и проверьте, как ваш шлюз передаёт его дальше. Если код действует ограниченное время, сообщение не должно ждать доставки дольше этого срока. При этом срок жизни SMS и срок действия самого кода на сервере настраиваются отдельно. Ниже — порядок настройки и проверки: от момента создания кода до ситуации, когда телефон клиента временно недоступен.

Как связать срок доставки SMS со сроком действия кода?

Начните с одного правила: у каждого кода есть время, после которого сервер перестаёт его принимать. SMS с этим кодом должно перестать ждать доставки не позже. Для одноразовых паролей часто используют короткий срок действия, обычно 5–10 минут (SMS OTP: Как работают одноразовые пароли по SMS, плюсы, минусы и ограничения). Конкретное значение выбирайте под свой сценарий, затем одинаково учитывайте его в приложении и отправке.

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

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

Как передать срок жизни сообщения через SMPP?

В SMPP для срока действия сообщения предусмотрен параметр validity_period в запросе submit_sm. Сначала проверьте в документации своего шлюза, какой формат значения он принимает, что происходит при пустом поле и передаёт ли он ограничение на маршрут доставки. Поведение при истечении срока тоже стоит уточнить заранее: для приложения важно знать, придёт ли итоговый статус и как он будет обозначен.

Затем настройте отправку по одному сценарию. Приложение создаёт код и записывает время его окончания. Перед запросом submit_sm оно вычисляет, сколько времени осталось. Если срок уже вышел, задача закрывается без отправки; если нет — приложение задаёт validity_period с учётом оставшегося времени. Вот почему фиксированное значение, записанное при постановке SMS в очередь, требует осторожности: очередь могла задержать сообщение.

Сохраните связь между запросом клиента, кодом, задачей отправки и message_id, который вернул шлюз. Ответ на submit_sm означает, что шлюз принял запрос, но ещё не доказывает доставку; итоговый статус приходит позже через DLR (интеграция CRM и SMPP для SMS-уведомлений помогает увидеть, где в таком процессе сохранять статусы). Если приложение не получило ответ вовремя, перед повторной отправкой проверьте состояние первой задачи, иначе клиенту могут уйти два сообщения (расчёт стоимости SMS через SMPP полезен при оценке последствий таких повторов).

Как проверить настройку до запуска?

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

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

Для разбора спорных случаев сохраняйте время создания кода, время отправки запроса, message_id и время получения DLR. По этим отметкам видно, где SMS задержалось — в очереди приложения или после приёма шлюзом. Если статусы не приходят, проверьте их обработку отдельно: разбор настройки срока жизни SMS и устаревших уведомлений поможет сопоставить поведение шлюза с вашим сценарием.

Какие ошибки мешают вовремя остановить SMS?

• Срок кода отсчитывают с момента отправки SMS, хотя код создали раньше. Исправление: сохраняйте время окончания при создании кода.
• validity_period задают при постановке в очередь и не пересчитывают перед отправкой. Исправление: проверяйте оставшееся время непосредственно перед submit_sm.
• Успешный ответ шлюза считают доставкой. Исправление: связывайте message_id с DLR и показывайте в системе отдельные состояния «принято» и «доставлено».
• После тайм-аута сразу отправляют тот же код повторно. Исправление: сначала проверьте первую задачу и защитите повторный запрос от дубля.
• Проверяют только получение кода при хорошей связи. Исправление: включите в тест отключённый телефон и задержку в очереди.

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