Smspoh Laravel Package

Technical Evaluation

Architecture fit. Unchanged in shape: laravel-notification-channels/smspoh remains a thin, single-purpose channel behind Laravel's via() abstraction. v2.0.0 does not alter the integration model — it enriches the message object. What does change is that the channel now pulls two new responsibilities into our architecture that previously lived outside it: (1) deliveryReceiptUrl($url) means we must own a publicly reachable inbound webhook endpoint and its security, and (2) scheduledAt() moves send-time orchestration from our scheduler into the vendor. Both are reasonable features, but they widen the trust boundary. The package is still not a vendor abstraction layer.

Integration feasibility. Still low effort for a greenfield integration. Two adjustments: the credential model changes from a single token to key + secret, so provisioning, secrets-manager entries, and rotation runbooks all change; and the new feature set (encryption, scheduling, receipts) roughly doubles the configuration surface that needs deliberate decision-making rather than default acceptance. Budget a half-day more than the original estimate to cover the receipt endpoint and encryption decisions.

Technical risk. The prior project-health risks are unchanged (see below), but v2 introduces several specific ones that must be closed before adoption:

• Adoption signals unchanged. The release does not change the ~7-star, near-zero-dependent reality. Governance via the laravel-notification-channels org still provides a convention baseline but not a maintenance guarantee. Validate composer.json, tag history, and issue responsiveness directly; the earlier caution about automated, low-confidence metrics still applies, though the concrete changelog and UPGRADE.md link now give us verifiable artifacts to check.
• Breaking change, cleanly signalled. token → key/secret and sender → from in config/services.php, plus SmspohMessage->sender() deprecated in favour of from(). The deprecation (rather than removal) of sender() is good hygiene. Risk is low but it is a coordinated config + secrets change, not a drop-in bump. Open question: does v2 drop support for older Laravel/PHP versions? "Compatibility with Laravel 13.x" is stated; minimum constraints are not. Pull the actual composer.json constraint — this is the single most likely blocker.
• Encryption introduces key-management risk. encrypt() with optional encryptKey($key) implies a default key path. If the default is a vendor-side or shared key, it is unsuitable for OTP and banking content. We must determine the algorithm, who holds the key, rotation behaviour, and what happens to scheduled messages encrypted under a retired key. This is now a security review item, not a config item.
• Delivery receipts create an inbound attack surface. A runtime-supplied callback URL means we operate a webhook endpoint that accepts unauthenticated POSTs. Requirement: verify vendor signature or shared secret, enforce idempotency on the receipt ID, validate and log, and never trust the body for state transitions without dedupe. Confirm whether the vendor signs callbacks at all — if not, treat receipts as advisory only.
• Scheduling has timezone ambiguity. scheduledAt('Y-m-d H:i:s') is a naked string. Confirm the vendor's assumed timezone (Smspoh is Myanmar-based; do not assume UTC), how it behaves across DST for recipients in other regions, and whether a scheduled message can be cancelled or amended. A silently mis-zoned "send at 09:00" is a user-visible defect.
• Unicode changes cost, not just capability. Non-GSM-7 characters drop segment size from 160 to 70, so one emoji can double per-message price. unicode() should be an explicit, reviewed choice per notification, not a blanket setting.
• Vendor dependency and compliance are unchanged: delivery, throughput, pricing, sender ID registration, and opt-out handling remain entirely Smspoh's. clientReference() helps our reconciliation and idempotency reasoning but does not make retries safe on the vendor side.

Key questions. Is Smspoh an approved vendor with a signed agreement, SLA, and per-message pricing we can model? What are the exact supported Laravel and PHP version constraints in v2, and does upgrading force a framework upgrade on us? What encryption algorithm and default key does encrypt() use, and can we supply and rotate our own? Does Smspoh sign delivery-receipt callbacks, and what is the retry policy if our endpoint is down? What timezone does the v3 API interpret scheduledAt in, and can scheduled messages be cancelled? Do we need multi-vendor SMS routing (failover, cost arbitrage, regional coverage)? If so, a vendor-agnostic abstraction should sit above this, not be bypassed. What are our data-handling obligations for phone numbers, message bodies, and encrypted payloads, and does Smspoh meet them?

Integration Approach

Stack fit. PHP/Laravel only, native notification subsystem required. composer.json version constraints are now the gating check: confirm the minimum Laravel and PHP versions in v2 against our current baseline before anything else. Non-Laravel PHP services and polyglot consumers still cannot use it directly. New in v2: we now also need an HTTP endpoint (receipts) and, if we adopt scheduling, a decision about whether we keep our own scheduler as the system of record or delegate to the vendor.

Migration path. Greenfield: add the dependency, publish config with key/secret/from, store secrets, add from() (not sender()) in message construction, stand up and secure the receipt endpoint, then gate rollout per notification type behind a flag. Brownfield v1 → v2: treat as a scheduled change window. Rename config keys and rotate credentials to the key/secret pair, replace sender() with from() across all message classes (grep first — the deprecation means it still works, which means it can hide), verify no behaviour change on a test notification, then deploy. Do the credential rotation and the code change in the same window so there is no state where config and code disagree. Brownfield from another SMS provider: unchanged advice — run both channels in parallel behind a flag, compare delivery receipts, cut over notification by notification, keep the dual path as a permanent kill switch.

Compatibility. Four checks now, up from three: Laravel/PHP version constraints; message-object field coverage (better than before — sender ID via from, body, scheduling, unicode, encryption, receipts, and reference are all exposed); conflicts with pinned versions of the parent notification package; and, new, whether encrypt() output is consumable by the vendor's v3 decrypt path under our key material. Anything still unexposed means upstream contribution or a fragmented direct-SDK call path.

Sequencing. (1) Vendor due diligence, v3 account provisioning, key/secret issuance into the secrets manager. (2) Read UPGRADE.md and pin the exact v2 version; resolve the Laravel/PHP constraint question. (3) Spike: one low-risk internal notification end-to-end in staging using v2 config. (4) Security review of encrypt()/encryptKey() and of the receipt endpoint (signature verification, idempotency, TLS, rate limiting). (5) Confirm receipt callbacks arrive and are logged — this closes the "silent delivery failure" gap the prior assessment flagged as unaddressed. (6) If already on v1: config/credential/method migration in one window. (7) Parallel-run against the incumbent on a non-critical notification. (8) Migrate transactional notifications one at a time. (9) Retire the legacy provider only after a soak period. Adopt scheduling, encryption, and unicode per notification, after the base path is proven — do not enable them as global defaults on day one.

Operational Impact

Maintenance. Still a small, stable-shaped package; day-to-day work is dependency bumps and Laravel major upgrades. The v2 release is mildly reassuring on lifecycle — it demonstrates active maintenance and support for the newest Laravel — but it also resets the abandonment calculus: we now depend on features (encryption, receipts) that would be unpleasant to reimplement if we forked, versus the previously trivial "one-file adapter." Revise the fork contingency upward — roughly 2–3 days per year plus a Laravel upgrade cost — and record the fork decision in advance. Track the config-key and sender() deprecations so v3 does not surprise us.

Support. Still two external channels: package issues (upstream, likely slow) and vendor support (contract-governed). Add a third, internal: the receipt endpoint is ours to operate, so inbound callback failures are our incident, not the vendor's. During triage, be explicit about which layer owns a symptom — outbound send rejection (vendor/package config), accepted-but-undelivered (vendor), accepted-and-delivered-but-not-recorded (our endpoint). The last one is new and easy to misroute.

Scaling. Throughput and rate limits remain Smspoh's constraints. Route sends through queued notifications with retry and backoff, never inline in request paths. Two new scaling dimensions: cost per segment now varies by message content, so model unicode/encryption overhead against projected volume rather than assuming 160 characters per message; and scheduled volume means messages can be handed to the vendor early and fire later, so vendor-side scheduled queue depth is a capacity signal we do not control and must ask about. Include a volume alarm — a runaway retry loop is still a real invoice, and encryption/unicode now make each message up to ~2.3× more expensive than a plain GSM-7 SMS.

Failure modes. Existing: credential/config errors (fast and loud, but the v2 key/secret change is itself a fresh opportunity to get this wrong — watch for a half-migrated config); vendor 4xx for invalid numbers or unregistered sender IDs (needs upstream validation); vendor 5xx/timeouts (retry with backoff and idempotency awareness — clientReference() now gives us a mechanism, but only if we populate it consistently per logical message, not per attempt); queue backlog with a dead-letter path and alert. New in v2: receipt endpoint downtime or misconfiguration, which recreates the silent-delivery-failure blind spot the feature was meant to close — so alert on absence of receipts, not just on errors; receipt replay or spoofing if callbacks are unsigned; scheduled messages firing in the wrong timezone, or firing after a key rotation and failing decryption; and encryption misconfiguration surfacing as a vendor-side 4xx that looks like a routing problem. The package remains a thin adapter — it will not normalize vendor error semantics, so error handling is ours.

Ramp-up. Still very low for a Laravel-fluent engineer; the via() pattern is familiar and a working send is hours of work. The new features are individually simple but each carries a decision that is not obvious from the API: which key material and rotation policy, which timezone, which notifications may use unicode, and who owns the receipt endpoint. Treat those four as design decisions to be recorded, not defaults to be accepted. The genuinely new knowledge remains the channel — deliverability, sender ID registration, consent/opt-out compliance, cost control — and vendor onboarding plus compliance is still the critical path. Before the first production send, ensure one engineer and one on-call rotation member understand the vendor console, the receipt pipeline, the encryption key location, and the kill-switch flag.