SMSC: российский SMS-шлюз для одноразовых кодов

В статье про OTP разобрана общая механика входа без пароля: код приходит пользователю, он вводит его в форму, сервер сверяет значение и открывает сессию. Там код уходил на почту через Supabase — так проще всего для старта. Но если приложение рассчитано на российскую аудиторию, надёжнее слать код в SMS: телефон проверяют реже, чем почту, а открывают почти сразу после того, как экран блокировки показал уведомление. Для этого нужен отдельный сервис — SMS-шлюз, и среди российских разработчиков один из самых известных вариантов — SMSC.

Зачем вообще нужен SMS-шлюз, если есть почта

Код на почту дешевле и проще в реализации: почтовый ящик у пользователя обычно уже есть, а отправка письма ничего не стоит сверх обычного тарифа Supabase или другого провайдера аутентификации. У этого пути есть слабое место — письмо не всегда открывают сразу. Оно может пролежать во «Входящих» пять минут, попасть в папку со спамом или потеряться среди рекламных рассылок. Для входа в игру задержка в пару минут не критична. Для банковского приложения, сервиса с оплатой или формы регистрации, где человек ждёт код прямо сейчас, — уже проблема, из-за которой часть пользователей просто уходит, не дождавшись письма.

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

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

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

Что такое SMS-шлюз и как он устроен

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

Схема работы простая и одинаковая для большинства шлюзов, включая SMSC:

1. Твой сервер формирует запрос к SMS-шлюзу: номер телефона получателя, текст сообщения, иногда — имя отправителя, которое увидит абонент вместо обычного короткого номера.
2. Шлюз принимает запрос, проверяет данные для входа, списывает деньги с твоего баланса по внутреннему тарифу и передаёт сообщение дальше — либо напрямую оператору, либо через цепочку агрегаторов.
3. Оператор доставляет SMS на телефон абонента — обычно за несколько секунд, но иногда доставка может занять минуту-две, особенно в сетях с плохим покрытием.
4. Шлюз может вернуть отчёт о статусе доставки: сообщение доставлено, не доставлено, ещё в очереди, — либо сразу в ответе на запрос, либо отдельным уведомлением чуть позже.

SMSC — один из старейших российских SMS-шлюзов, работающий именно по такой модели. Его главное преимущество для курса skillmake — доступность из России без VPN и без иностранной карты. Здесь проявляется прямая параллель с темой из первого модуля курса: там VPN нужен был, чтобы вообще достучаться до зарубежных ИИ-сервисов и оплатить их иностранной картой. С российским SMS-шлюзом такой преграды нет с самого начала — регистрация, оплата и работа с API идут напрямую, без обходных путей.

flowchart TB
    A["Пользователь вводит номер"] --> B["Сервер запрашивает SMSC"]
    B --> C["SMS с кодом абоненту"]
    C --> D["Пользователь вводит код"]
    D --> E["Сервер проверяет код"]

Чем SMSC отличается от зарубежных SMS-сервисов

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

Первая — доступ к самому сервису. Регистрация и привязка способа оплаты у иностранных SMS-платформ обычно рассчитаны на карту, выпущенную за пределами России, и требуют доступа к сайту сервиса без ограничений — то есть снова VPN, снова иностранную карту, снова весь тот же набор преград, который в курсе уже разбирался применительно к Claude, GitHub и другим западным инструментам.

Вторая проблема тоньше и заметна не сразу: доставка SMS именно на российские номера у зарубежных шлюзов часто менее стабильна, потому что у них нет прямых договоров с российскими операторами связи. Сообщение может идти дольше или теряться на промежуточных агрегаторах трафика. SMSC работает по обратной модели: его целевая аудитория — это в первую очередь российский рынок, поэтому договоры с местными операторами прямые, а доставка на номера МТС, МегаФона, Билайна и Tele2 отлажена как основной, а не второстепенный сценарий.

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

Регистрация и пополнение баланса

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

В личном кабинете сервиса обычно доступны логин и пароль для входа в HTTP API — их указывают в каждом запросе на отправку сообщения. Это фактически ключ доступа к твоему балансу: тот, кто им завладеет, сможет слать SMS от твоего имени и тратить твои деньги. Хранить эти данные в коде приложения, в открытом виде в репозитории или в переменных, которые попадают в клиентскую часть, нельзя. Где именно их держать правильно, подробно разобрано в статье про хранение секретов и токенов — принцип для SMSC точно такой же, как для ключа любого другого стороннего API: переменные окружения на сервере, никогда не в git и никогда в коде, который выполняется в браузере пользователя.

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

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

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

Отправка SMS через HTTP API

У SMSC, как у большинства SMS-шлюзов, отправка сообщения — это обычный HTTP-запрос, без сложных протоколов и без необходимости устанавливать специальные библиотеки. В общих чертах он выглядит так: сервер приложения обращается по определённому адресу API сервиса и передаёт в запросе несколько обязательных параметров.

Логика набора параметров одинакова для большинства подобных сервисов:

• Данные для авторизации — логин и пароль от личного кабинета или отдельный API-ключ, в зависимости от того, что предлагает конкретный сервис.
• Номер телефона получателя — в международном формате, с кодом страны.
• Текст сообщения — собственно сам код и, как правило, короткая поясняющая фраза вроде «Код для входа: 482913».
• Необязательные параметры — имя отправителя, если оно настроено, формат ответа сервиса (например, обычный текст или JSON), запрос отчёта о доставке.

В ответ шлюз присылает результат: идентификатор отправленного сообщения, по которому потом можно узнать статус доставки, либо код ошибки — например, если баланс закончился, номер указан в неверном формате или превышен лимит отправок. Обработка ошибок здесь так же важна, как сама отправка: если сервер приложения не проверяет ответ шлюза, пользователь может остаться без кода и без объяснения, что пошло не так, а разработчик — не узнать об этом, пока не начнутся жалобы.

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

У многих SMS-шлюзов, включая SMSC, есть тестовый режим — возможность имитировать отправку без реального списания денег и без фактической доставки SMS, чтобы проверить, что запрос к API собран правильно и обрабатывается корректно. Стоит воспользоваться таким режимом на этапе разработки, а переключаться на боевую отправку только когда логика полностью отлажена — это экономит баланс и нервы.

Точный формат запроса — какие параметры обязательны, в каком порядке их передавать, какой протокол шифрования использовать для передачи данных — смотри в официальной документации SMSC на сайте сервиса. Она периодически дополняется новыми возможностями API, и пересказывать её здесь смысла нет: актуальная версия всегда там, а не в статье, написанной в определённый момент времени.

Отчёты о доставке

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

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

Что если у пользователя иностранный номер

Приложение может собирать аудиторию не только из России — например, если Змейка из курса набирает игроков за рубежом. SMSC работает и с международными направлениями, но здесь есть два нюанса. Во-первых, доставка на номера других стран может стоить заметно дороже, чем на российские, — сервис обычно показывает разбивку тарифов по направлениям в личном кабинете. Во-вторых, скорость и надёжность доставки на зарубежные номера зависят от того, насколько у шлюза налажены партнёрские каналы именно в этой стране, и для по-настоящему международного продукта картина может быть не такой ровной, как внутри России.

Для проекта, где основная масса пользователей — из России, а часть — из соседних стран или диаспоры за рубежом, SMSC обычно справляется без дополнительных сложностей. Если же аудитория рассредоточена по всему миру примерно поровну, стоит заранее протестировать доставку на нужные направления в тестовом режиме, прежде чем закладывать SMS как основной канал подтверждения.

Как встроить SMSC в форму OTP-входа

В статье про OTP, сессии и токены разобрана общая механика: пользователь вводит контакт, получает код, вводит его обратно, сервер создаёт сессию. SMSC встраивается в эту схему вместо шага «отправить письмо»: там, где раньше уходило письмо через Supabase, теперь уходит запрос к SMSC, а всё остальное — генерация кода, хранение, проверка, создание сессии — остаётся прежним.

Логика шага за шагом:

1. Пользователь вводит номер телефона в форму входа.
2. Сервер генерирует одноразовый код — например, случайное шестизначное число.
3. Сервер сохраняет код рядом с номером телефона и временем создания, чтобы потом проверить его и не дать использовать дважды или после истечения срока действия.
4. Сервер отправляет HTTP-запрос к SMSC с этим кодом в тексте сообщения.
5. SMSC доставляет SMS на телефон пользователя.
6. Пользователь вводит код в приложении.
7. Сервер сравнивает введённый код с сохранённым и проверяет, что срок действия ещё не истёк, а число попыток ввода не превышено.
8. Если всё совпало, сервер создаёт сессию — точно так же, как при входе по коду с почты, — и дальше в дело вступают уже знакомые из статьи про OTP механизмы: cookie для браузера, токены для запросов к API.

Здесь Supabase и SMSC решают разные части одной задачи. Supabase — это то, что хранит сессии, токены и данные пользователей и умеет само проверять код, если код доставляется по email. SMSC — просто канал доставки кода по SMS, у него нет встроенного понятия «пользователь» или «сессия», он лишь отправляет текст на номер. Поэтому при подключении SMS-варианта логику генерации и проверки кода обычно пишет само приложение: код создаётся на сервере, сохраняется в базе рядом с номером телефона, и именно с этой записью сверяется введённое пользователем значение.

Стоит заранее продумать и удобные мелочи интерфейса: кнопку «Отправить код повторно», которая должна быть заблокирована на короткое время после предыдущей отправки, понятное сообщение об ошибке, если номер введён некорректно, и таймер обратного отсчёта до истечения срока действия кода. Это не только вопрос удобства — без ограничения на повторную отправку пользователь может случайно (или специально) запросить десяток кодов подряд, и каждый такой код — это реальные деньги, списанные с баланса SMSC.

Защита от злоупотреблений

Одноразовый код, который можно запросить сколько угодно раз, — открытая дверь для двух видов проблем. Первая: бот может слать запросы на отправку кода пачками, и баланс SMSC уйдёт в ноль за считаные минуты, а платить за это будешь ты. Вторая: если ограничений на количество попыток ввода кода нет, код можно подобрать перебором — шестизначных комбинаций всего миллион, и без лимита на число попыток это не такая уж большая преграда для автоматизированного скрипта.

От обеих проблем защищает один и тот же принцип — лимит запросов, применённый на разных уровнях:

• Лимит на отправку кода по одному номеру телефона. Не больше нескольких запросов на новый код за короткий промежуток времени — например, не чаще раза в минуту и не больше нескольких раз в час.
• Лимит на попытки ввода кода. После нескольких неверных попыток код нужно считать недействительным и требовать новый запрос, а не позволять пробовать бесконечно.
• Лимит по IP-адресу или устройству. Если с одного адреса за короткое время приходит много запросов на разные номера, это похоже на автоматизированную атаку, а не на обычное поведение живого пользователя.
• Ограничение общего расхода баланса за период. Даже если отдельные лимиты обойдены, суточный или часовой потолок трат защищает от сценария, когда что-то пошло не так и деньги утекают быстрее, чем успеваешь заметить проблему.

Подробный разбор, как выставлять такие ограничения и распознавать автоматизированные запросы, — в статье про защиту от перебора и ботов. Для SMS-канала это не факультативная мера, а обязательная: почтовый лимит Supabase бесплатный сам по себе, а лимит на SMSC — это прямая экономия денег. Разница в цене ошибки здесь ощутима: забытый лимит на отправку писем стоит нервов, забытый лимит на отправку SMS стоит реальных денег с баланса.

Где хранить API-ключ SMSC

Логин, пароль или API-ключ от SMSC дают доступ к балансу и позволяют слать сообщения от имени твоего проекта, поэтому обращаться с ними нужно так же аккуратно, как с любым другим секретом приложения. Общий принцип — переменные окружения на сервере, доступ только из серверного кода, никогда не в репозитории и никогда в переменных, которые попадают в код, исполняемый в браузере. Подробно этот подход, включая типичные ошибки новичков и разницу между секретами для сервера и публичными ключами для клиента, разобран в статье про хранение секретов и токенов.

Что дешевле — почта или SMS

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

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

Частые ошибки при подключении SMS-шлюза

Ошибка 1. Хранить логин и пароль от SMSC в коде фронтенда

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

Ошибка 2. Не ограничивать частоту отправки кода

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

Ошибка 3. Не проверять ответ шлюза на ошибки

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

Ошибка 4. Использовать один и тот же код для разных попыток входа

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

Ошибка 5. Забывать про тестовый режим на этапе разработки

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

Чек-лист «SMS-шлюз готов к работе»

• Аккаунт в SMSC зарегистрирован, баланс пополнен.
• Логин и пароль (или API-ключ) хранятся в переменных окружения на сервере, а не в коде фронтенда.
• Запрос на отправку SMS уходит только с серверной части приложения.
• Настроен и проверен тестовый режим отправки перед переходом на боевой.
• Код генерируется на сервере, сохраняется вместе с номером телефона и временем создания.
• Старый код инвалидируется при запросе нового.
• Настроен лимит на повторную отправку кода по одному номеру.
• Настроен лимит на количество попыток ввода кода.
• Настроен лимит по IP-адресу или устройству на количество запросов.
• Проверена обработка ошибок ответа SMSC — например, недостаточный баланс или неверный номер.
• Продуманы удобные детали интерфейса: таймер до истечения кода, блокировка кнопки повторной отправки.

Частые вопросы

Нужен ли SMSC, если у меня уже настроен вход через Supabase?

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

Можно ли отправлять SMS прямо из браузера пользователя, без сервера?

Нет. Логин и пароль от SMSC в этом случае окажутся видны в коде страницы, и любой сможет тратить твой баланс. Запрос к SMSC всегда должен уходить с сервера приложения.

Сколько стоит одно SMS через SMSC?

Точные тарифы меняются и зависят от направления и объёма отправок — актуальные цифры смотри на сайте сервиса.

Работает ли SMSC без VPN и иностранной карты?

Да, в этом и заключается его основное отличие от зарубежных SMS-шлюзов вроде Twilio: регистрация, оплата и доставка на российские номера рассчитаны на работу из России без обходных путей.

Что делать, если SMS не приходит?

Сначала проверь баланс аккаунта в SMSC и статус доставки конкретного сообщения — сервис обычно показывает, дошло ли SMS до оператора. Если баланс в порядке, а сообщения всё равно не доходят, стоит обратиться в поддержку SMSC: возможны технические ограничения на стороне конкретного оператора.

Можно ли использовать SMSC вместе с email-кодами в одном приложении?

Да, ничего не мешает предлагать пользователю выбор канала — почта или SMS. Логика сервера в обоих случаях одинаковая: сгенерировать код, сохранить его и сверить при вводе, различается только способ доставки конечного сообщения.

Нужно ли регистрировать имя отправителя отдельно?

Да, если хочешь, чтобы пользователь видел в SMS название проекта вместо обычного короткого номера. Такая настройка обычно требует отдельной регистрации в личном кабинете сервиса, иногда с дополнительной проверкой, поэтому её стоит планировать заранее, до запуска.

Есть ли у SMSC альтернативы для российского рынка?

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

Заключение

SMS-шлюз вроде SMSC закрывает конкретную задачу: доставить одноразовый код на телефон пользователя, когда почты недостаточно или важна скорость подтверждения. Для российского проекта он удобен тем, что работает без VPN и иностранной карты — преграды, ради обхода которой в первом модуле курса и понадобился VPN для других сервисов, здесь просто нет.

Встраивается SMSC в уже знакомую схему OTP-входа без особых сложностей: код по-прежнему генерирует и проверяет сервер приложения, шлюз лишь доставляет готовое сообщение до телефона. Главное — не переносить логику отправки в браузер, хранить ключ доступа так же бережно, как любой другой секрет проекта, и с самого начала настроить лимиты на запросы: SMS, в отличие от письма, стоит денег с каждой отправки, и без ограничений это довольно быстро становится заметной статьёй расходов.