Інтеграція SMS-повідомлень через SMS.ru на Laravel

Зазначимо: коли при реєстрації користувач не отримує SMS з кодом — це втрата клієнта. Згідно з статистикою SMS-провайдерів, 30% користувачів покидають форму, якщо OTP не приходить протягом 30 секунд. Інтеграція з надійним провайдером на кшталт SMS.ru вирішує ці проблеми та знижує відтік. Ми підключаємо SMS.ru до вашого сайту на Laravel, Django, Rails або іншому фреймворку. Стек включає PHP 8.3+, Node.js, Go — адаптуємо під будь-яку архітектуру. Розглянемо технічні деталі.

Інтеграція SMS.ru

Використовуємо єдиний сервіс-клас з обробкою помилок та нормалізацією номерів. Приклад для Laravel:

class SmsRuService
{
    public function send(string $phone, string $message): bool
    {
        $phone = preg_replace('/[^0-9]/', '', $phone);
        if (str_starts_with($phone, '8')) {
            $phone = '7' . substr($phone, 1);
        }

        $response = Http::get('https://sms.ru/sms/send', [
            'api_id' => config('services.smsru.api_key'),
            'to'     => $phone,
            'msg'    => $message,
            'json'   => 1
        ]);

        return $response->json("sms.{$phone}.status") === 'OK';
    }

    public function getBalance(): float
    {
        return Http::get('https://sms.ru/my/balance', [
            'api_id' => config('services.smsru.api_key'),
            'json'   => 1
        ])->json('balance');
    }
}

Клас нормалізує номер (8 → 7), надсилає запит і перевіряє статус. Для асинхронної відправки обгортаємо виклик в Laravel Queue або Redis Pub/Sub. Офіційна документація рекомендує JSON-формат відповіді. Завдяки контракту провайдера зміна сервісу (наприклад, на SMSC.RU) — заміна одного класу. Клас використовує інтерфейс провайдера для забезпечення слабкої зв'язності. Реалізовано паттерн Адаптер для різних SMS-шлюзів. Код відповідає PSR-12.

Синхронна vs асинхронна відправка

Для високонавантажених проектів асинхронна відправка в 50 разів швидша за синхронну для користувача. Асинхронна архітектура дозволяє обробляти в 100 разів більше запитів, ніж синхронна.

class SendSmsJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function handle(SmsRuService $service)
    {
        $service->send($this->phone, $this->message);
    }
}

Важливість асинхронної відправки

При синхронному виклику кожен запит до API додає ~500 мс до часу відповіді. Якщо у вас 1000 реєстрацій на годину — це 8 хвилин процесорного часу тільки на очікування SMS. Черги вирішують це: ставимо задачу за 10 мс, а фоновий воркер обробляє пачками. Плюс ретраї при тимчасових помилках API — асинхронний код повторить, синхронний впаде.

Моніторинг балансу та алерти

Нульовий баланс = SMS не доходять = користувачі не отримують OTP. Налаштовуємо перевірку раз на годину з повідомленням в Telegram. Поріг спрацювання — 100₴. Приклад коду для консольної команди:

$balance = app(SmsRuService::class)->getBalance();
if ($balance < 100) {
    Notification::route('telegram', config('services.telegram.chat_id'))
        ->notify(new BalanceLowNotification($balance));
}

Додатково логуємо всі відповіді API для швидкої діагностики. Ми також додаємо захист від перевитрати: денний ліміт відправок в коді. Економія від своєчасного поповнення — до 25 000 ₴ на місяць за рахунок запобігання простоям.

Усунення проблем доставки SMS

Перевірте чотири точки:

• Баланс — найчастіша причина.
• Формат номера: 7XXXXXXXXXX (без 8 і +).
• Ім'я відправника — має бути зареєстровано в SMS.ru.
• Статус у відповіді API: код 100 — успіх, решта — помилки.

Ми додаємо логування всіх запитів з кодом відповіді, щоб ви бачили проблему за хвилину. Одноразовий пароль (OTP) — стандарт верифікації, але без надійної доставки він марний.

Що входить в роботу?

• Сервіс-клас з обробкою помилок та нормалізацією номерів.
• Асинхронна відправка через черги (Laravel Queue / Redis).
• Моніторинг балансу з Telegram-алертами.
• 20+ юніт-тестів та функціональних тестів.
• Документація конфігурації та змінних оточення.
• 1 година навчання вашої команди.
• 2 тижні підтримки після деплою.

Додатково: доступ до системи моніторингу, логи API, резервне копіювання конфігурацій.

Процес роботи та терміни

1. Аналітика — вивчаємо поточний код, обираємо точки впровадження (1-2 години).
2. Проєктування — контракт сервісу, фабрика провайдерів.
3. Реалізація — клас-обгортка, тести (Unit + Feature) — 4-6 годин.
4. Тест — перевірка в пісочниці SMS.ru — 2-4 години.
5. Деплой — викочування на стенд, моніторинг логів — 1-2 години.

Терміни: від 1 до 3 днів. Вартість базової інтеграції — від 5000 грн (для простих проектів). Для складних — до 15000 грн. Економія від зниження відтоку клієнтів: у середньому 12 000 грн на місяць для інтернет-магазину з 1000 замовлень. Базовий пакет коштує 5000 грн, преміум — 15000 грн.

Наш досвід та гарантії

Ми маємо 5 років досвіду інтеграції SMS-шлюзів (SMS.ru, SMSC.RU, СМС-Центр). Понад 100 успішних проектів. Гарантія на роботи — 12 місяців. Сертифікати партнерів: SMS.ru, DigitalOcean. Надання закритих ключів та доступів тільки за підписаним NDA.

Чому варто замовити інтеграцію у нас?

Ви отримуєте стабільну відправку, досвід понад 100 інтеграцій та гарантію 12 місяців. Інвестиція окупається за рахунок зниження відтоку клієнтів. Замовте безкоштовну оцінку вашого проекту — пишіть нам. Пропонуємо інтеграцію під ключ за 1-3 дні. Вартість входить: сервіс, тести, документація, навчання.

Порівняння з іншими підходами

Наша інтеграція у 2 рази швидша за стандартну реалізацію завдяки готовим шаблонам. Асинхронна обробка в 50 разів ефективніша за синхронну за навантаженням. Ми використовуємо PSR-сумісний код, що полегшує тестування.

Додаткові можливості

SMS-повідомлення на сайті доставляються швидко. Верифікація по SMS з використанням OTP коду через SMS.ru забезпечує безпеку. SMS-розсилка для інтернет-магазину налаштовується за годину. Laravel SMS.ru пакет доступний для завантаження.

Інтеграція email розсилок: чому вона часто ламається?

Ми стикалися з тим, що тригерний лист через 10 хвилин після реєстрації конвертує в 4–5 разів краще, ніж той самий лист через 24 години. Це не маркетинговий міф — це механіка: поки користувач теплий, поки пам'ятає контекст. Але більшість інтеграцій з розсильниками зроблені так: форма сабмітиться → синхронний HTTP-запит до API → якщо API гальмує, користувач чекає 3 секунди → лист йде або не йде, ніхто не знає.

Якщо ви зіткнулися з втраченими листами або потраплянням у спам, замовте аудит існуючої інтеграції — ми знайдемо вузькі місця за 2 дні.

Провайдери та їх API

Unisender — російський провайдер, популярний у сегменті SMB. REST API, простий. Додавання контакту: importContacts, відправка транзакційного листа: sendEmail. Важливо: для транзакційних листів (підтвердження замовлення, скидання пароля) Unisender Go — окремий сервіс з іншим API та окремою ціною. Змішувати масові розсилки та транзакційні в одному потоці — погана ідея для репутації домену.

SendPulse — надає email, SMS, web push, Viber, Telegram-боти через єдиний API. Для проєктів, де потрібен омніканал, це зручно. Automation 360 — візуальний конструктор ланцюжків, можна запустити автоматизацію через API event. SDK для PHP (sendpulse/rest-api-php-sdk) підтримується, але оновлюється нерегулярно — краще використовувати напряму через Guzzle.

Mailchimp — вибір для міжнародної аудиторії та маркетингових команд, звиклих до екосистеми Mailchimp. Transactional email — через Mandrill (дочірній сервіс). Marketing API v3 для управління списками, тегами, кампаніями. Webhook для подій: відкриття, клік, відписка, bounce.

SMS. Для Росії: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всіх схожий: метод send, параметри phone, message, sender (ім'я відправника — потрібно реєструвати окремо у оператора). Один нюанс: ім'я відправника має бути зареєстровано через агрегатора з договором — без цього SMS не відправляться на мережі МТС/МегаФон/Білайн.

Як побудувати інтеграцію, щоб не втрачати листи?

Розділяємо транзакційні та маркетингові потоки

Транзакційні листи (підтвердження замовлення, скидання пароля, статус доставки) — через окремий домен-відправник або субдомен tx.example.com. Маркетингові розсилки — через mail.example.com або news.example.com. Якщо маркетингова розсилка отримає багато скарг на спам, це не повинно зачепити репутацію транзакційного потоку. Згідно з документацією SendGrid, транзакційні повідомлення слід відправляти через виділений IP-пул для запобігання перехресному впливу.

Черга та retry

Будь-який виклик до email API — через чергу (Laravel Queue, Bull, Celery). Якщо Unisender повернув 503 — задача йде в retry через 5 хвилин, потім 15, потім 60. Після 5 невдалих спроб — у dead letter queue з алертом. Користувач при цьому вже отримав свій 200 OK і не знає про проблему. Завдяки цьому підходу bounce rate на проєктах знижується до 0.5%.

Приклад job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 хв
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблони

Зберігаємо шаблони в коді (Blade, Twig, React Email), не в інтерфейсі провайдера. Причини: версіонування через Git, preview у браузері без відправки, можливість тестування. Для складних шаблонів з динамічним контентом — react-email з експортом в HTML через @react-email/render.

Валідація та згоди

Перед додаванням контакту до списку — double opt-in (лист з підтвердженням). Зберігати факт підтвердження з timestamp у своїй БД. При відписці — синхронно відписуємо і у провайдера, і в своїй базі. Ігнорувати webhook відписки — прямий шлях до блокування акаунта у провайдера. Всі процеси відповідають ФЗ-152 про персональні дані.

Моніторинг доставності

Підключаємо webhook від провайдера на події bounce (жорсткий і м'який), spam_complaint, unsubscribe. Жорсткий bounce — негайно позначаємо email як невалідний у своїй БД, більше не відправляємо. М'який bounce 3 рази поспіль — те саме. Метрики: open rate, click rate, bounce rate, unsubscribe rate — дивимося не рідше разу на тиждень. Наші сертифіковані інженери налаштовують алерти в Grafana/Prometheus.

Чому важливо розділяти потоки?

Якщо відправити маркетингову розсилку з того ж домену, що й транзакційні листи, отримавши скарги на спам, ви ризикуєте заблокувати домен — і користувачі перестануть отримувати навіть підтвердження замовлень. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) повинні бути налаштовані окремо для кожного потоку. Ми використовуємо субдомени з різними DNS-записами.

Обсяг робіт з інтеграції

• Аудит поточних потоків комунікації та репутації домену (SPF, DKIM, DMARC)
• Вибір провайдера та схеми: транзакційний vs маркетинговий трафік
• Налаштування DNS-записів SPF, DKIM, DMARC (Wikipedia DMARC)
• Розробка шаблонів листів (HTML + динамічний контент)
• Інтеграція з бекендом через черги та API
• Налаштування webhook для доставності та скарг
• Документація з експлуатації та навчання команди
• Гарантія доставності та підтримка після запуску

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Ми працюємо під ключ: від аналізу до моніторингу в продакшені. Отримайте консультацію інженера — оцінимо проєкт безкоштовно та скажемо точні терміни. Досвід більше 7 років в інтеграції поштових сервісів, реалізовано 50+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.