Getting Started

Install the channel with Composer:
```
composer require laravel-notification-channels/smsc-ru
```
The service provider is auto-discovered on Laravel 5.5+, so no manual registration is needed on modern versions.
Publish / inspect the config. Run the vendor publish command (or look at config/services.php if the package defers to it — check vendor/laravel-notification-channels/smsc-ru/config/ to see which one applies to your version):
```
php artisan vendor:publish --provider="NotificationChannels\SmscRu\SmscRuServiceProvider"
```
Then add credentials to .env:
```
SMSCRU_LOGIN=your_login
SMSCRU_PASSWORD=your_password
```
These map to the SMSC.ru account login and password used on the send.php endpoint.
Make the notifiable reachable by phone. Either expose a phone attribute on the model or add an explicit routing method:
```
public function routeNotificationForSmscru()
{
    return $this->phone; // E.164, e.g. +79001234567
}
```

Write your first notification. This is the canonical use case — an OTP or order-confirmation:

use Illuminate\Notifications\Notification;
use NotificationChannels\SmscRu\SmscRuChannel;
use NotificationChannels\SmscRu\SmscRuMessage;

class OrderShipped extends Notification
{
    public function via($notifiable)
    {
        return [SmscRuChannel::class];
    }

    public function toSmscRu($notifiable)
    {
        return SmscRuMessage::create()
            ->content('Your order has shipped.');
    }
}

Trigger it with $user->notify(new OrderShipped());.

The first thing to verify end-to-end is a single send to your own number in a tinker session — that validates credentials, sender approval, and phone formatting all at once.

Implementation Patterns

Custom sender per message. The default sender comes from config, but you can override it per message (the sender must already be approved in your SMSC.ru dashboard):

SmscRuMessage::create()
    ->content('Your code is 1234')
    ->from('MyBrand');

Transliteration for Cyrillic. Latin-only SMS get 160 chars per segment; Cyrillic gets roughly 70. Enable translit per message or globally so Russian text is romanized and billing stays predictable:

SmscRuMessage::create()
    ->content('Ваш заказ отправлен')
    ->translit(true);

On-demand notifications (no model). Useful for one-off sends, e.g. from a webhook handler or admin action:

Notification::route('smscru', '+79001234567')
    ->notify(new OrderShipped());

This bypasses routeNotificationForSmscru() entirely — handy for testing and for one-shot recipients.

Queue everything. SMS is an external HTTP call; wrap notifications in ShouldQueue so a slow SMSC.ru response doesn't block the request:

class OrderShipped extends Notification implements ShouldQueue
{
    public $tries = 3;
    public $backoff = [10, 60];
}

Multi-channel fallback. Pair SMS with mail or a database notification so delivery isn't a single point of failure — return [SmscRuChannel::class, 'mail'] from via() and implement toMail() alongside toSmscRu().

Centralize templates. Rather than inlining strings, add a small message factory or a toSmscRu() base class per domain (auth, billing, shipping) so copy changes happen in one place and transliteration/sender settings stay consistent.

Testing. Use Laravel's fake to assert the channel was targeted without hitting the API:

Notification::fake();
$user->notify(new OrderShipped());
Notification::assertSentTo($user, OrderShipped::class, function ($notification, $channels) {
    return in_array(SmscRuChannel::class, $channels);
});

The package itself only does an HTTP call — for deeper assertions, mock the Guzzle client or use Http::fake() if your Laravel version's HTTP client is being used under the hood.

Integration with domain events. The cleanest wiring is an event listener or a model observer that dispatches a notification. Keep the notification class dumb; let application code decide when to fire it.

Gotchas and Tips

Sender names must be pre-approved. If from() fails silently or returns an SMSC error, it's almost always because the sender isn't registered on the account. Confirm in the SMSC.ru dashboard before debugging code.
API-level errors can return HTTP 200. SMSC.ru's send.php frequently responds 200 with a JSON body describing the failure (error, error_code). The channel may not translate that into an exception, so a notification can "succeed" locally while the SMS never arrives. Log responses or wrap the channel in a subclass if delivery guarantees matter.
Phone format is strict. SMSC.ru expects international format (+79001234567 or 79001234567). A bare 9001234567 will usually send to the wrong country or fail. Normalize in routeNotificationForSmscru() rather than in each notification.
Config location trips people up. Depending on the version, credentials live in a published config/smscru.php or in config/services.php under a smscru key. If sends fail with auth errors, grep vendor/ for where the package reads login — don't assume.
Password vs. API key. SMSC.ru supports both password auth and API-key auth. This package's psw parameter expects the password flow by default. If your account has 2FA or API keys enforced, you may need to fork or subclass the channel to pass the key instead.
Cyrillic = shorter messages = more segments. Always set translit for mixed-audience sends, or at least verify message length against the 70-char Cyrillic limit before composing.
No rate limiting out of the box. SMSC.ru has per-second throughput limits on the account tier. If you're doing bulk sends, throttle the queue (->onConnection('redis')->through(...) or a rate-limited job middleware) or you'll get partial failures.
Low adoption = thin maintenance surface. With ~0 dependents and infrequent releases, pin the version in composer.json ("^x.y") and keep an eye on the endpoint behavior. The extension point is simply the message class and channel — subclass SmscRuChannel and override send() if you need retry logic, logging, or a different auth flow.
Debugging checklist when nothing sends: (1) routeNotificationForSmscru() returns a non-null value, (2) credentials are correct in .env and config is cached-cleared (php artisan config:clear), (3) sender is approved, (4) phone is E.164, (5) the notification is actually queued/executed (check queue:work logs). Those five cover 95% of failures.

Smsc Ru Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips