Smspoh Laravel Package

Product Decisions This Supports

• Market entry / localization for Myanmar: If the roadmap includes Myanmar users (payments, delivery, marketplaces, fintech onboarding), SMS deliverability through a local aggregator is usually materially better than routing +95 numbers through global providers. This package makes that a configuration decision rather than a custom integration project — and v2.0.0's explicit Unicode support (unicode()) removes a real prior blocker: Burmese-script messages, not just transliterated English, can now ship as a first-class feature rather than a workaround.
• OTP and transactional notification features: Unlocks the standard set — phone verification, 2FA, order/delivery status, payment confirmations — inside Laravel's existing Notification system, so no new queue, template, or logging infrastructure is needed to ship the first version.
• Security-sensitive notifications (new in v2.0.0): encrypt() / encryptKey() plus clientReference() move this from "generic alerts" into the fintech-adjacent use case: OTPs, balance and transaction alerts, and anything where interception or replay is a real threat model. That expands which features can be built on this channel — but pushes key management, rotation, and audit into our scope, not the package's.
• Build vs. buy: The build alternative has grown. Against v1 it was ~100–200 lines of channel code; against v2.0.0 the honest comparison includes scheduling, encryption, Unicode, delivery-receipt plumbing, and client-reference tracing — call it 250–400 lines plus tests, plus owning crypto correctness. Adopting is still roughly a half-day to one-day integration; writing and maintaining our own is now 4–6 days plus ongoing ownership. Buy (adopt) wins unless we need behavior the channel doesn't expose.
• Delivery observability becomes actionable (new in v2.0.0): deliveryReceiptUrl($url) lets us register a per-message webhook at runtime instead of configuring callbacks in the vendor dashboard. That makes per-message receipt capture a code-level, environment-parameterised concern — a prerequisite for per-message cost attribution and suppression-list hygiene. The receipt endpoint, verification, and reconciliation logic remain ours to build.
• Channel expansion sequencing: Establishes the pattern (mail → SMS → push/WhatsApp) so future channels are cheap. Scheduling support additionally unlocks reminder-style features (appointment, renewal, delivery window) without a cron/job-per-reminder design in our app.
• Provider abstraction / de-risking roadmap: Because it plugs into Laravel's Notification facade, it becomes one swappable driver behind our own thin SmsSender interface. This lets us pilot SMSPoh for Myanmar while keeping Twilio/Vonage for other geographies — a multi-provider decision we can defer until volume data exists. clientReference() makes that abstraction cleaner, since we can carry our own message IDs across providers.
• Risk budgeting: MIT license, small code surface, zero runtime infrastructure. v2.0.0 is a meaningful maturity signal (modern key/secret credentials, documented upgrade path, current Laravel support), but it does not change the fundamental shape: worst case (package abandoned) is vendoring a fork — a bounded, reversible cost, not an architectural commitment.

When to Consider This Package

Adopt when:

• The stack is Laravel (the package now targets current Laravel including 13.x) and the team already sends notifications through Notifiable models or Notification::route().
• SMSPoh is already chosen (or being trialled) as the Myanmar delivery route — pricing, sender ID registration, and coverage have been validated with the vendor — and the vendor has confirmed API v3 access, since v2.0.0 of the channel requires v3 key/secret credentials, not a v1 token.
• The feature set you need is transactional/OTP-scale: verification, 2FA, status updates, scheduled reminders, sensitive alerts. Unicode and encryption now cover the Myanmar-language and security-sensitive cases that previously pushed teams toward custom work.
• The team is comfortable with community-maintained dependencies (laravel-notification-channels has a consistent, well-understood package shape: credentials in config, a message class, a routing method).
• You are starting fresh, or you can absorb a small, well-documented upgrade. Greenfield adopters should start on v2.0.0 directly — there is no reason to build against v1.

Look elsewhere when:

• You need global SMS in one contract (Twilio, Vonage, AWS SNS) — or an enterprise SLA, named support contact, and contractual uptime.
• You need richer channels (WhatsApp, RCS, MMS) or a vendor-side template/consent management layer. Scheduling here is per-message, not a campaign manager: no audience segmentation, no scheduling UI, no send-time optimisation.
• Compliance or procurement requires a supported commercial dependency. Adoption remains narrow (single maintainer, small star count, few known dependents) — treat it as "small glue code we own the risk on," not "a platform."
• You need hardened key management for encrypted messages and cannot own that yourself; the package transmits with your key, but custody, rotation, and audit are yours.
• You're not on Laravel, or you'd rather call the SMSPoh HTTP API directly from a small service (entirely reasonable at low volume).
• Requirements include advanced delivery-receipt processing, per-message cost attribution, or multi-provider failover logic — build that in our layer, not in the channel. v2.0.0 gives us the receipt hook; it does not give us the reconciliation system.

Upgrade note (existing v1 integrations): v2.0.0 is breaking — token becomes key + secret, sender becomes from, and SmspohMessage->sender() is deprecated in favour of from(). Budget this as a scheduled, coordinated change: env-var renames mean credential rotation with the vendor and a deploy that touches secrets management, not just application code. Pin v1 until the upgrade is planned, then pin v2.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed adapter that lets our Laravel application send SMS through SMSPoh — a local Myanmar gateway — using the notification system we already have. The new v2.0.0 release closes most of the gaps that would previously have justified building our own: scheduled messages, encrypted sensitive alerts, Burmese Unicode text, and per-message delivery receipts are now supported out of the box, and the package tracks current Laravel. Integration cost remains on the order of one engineering day, adds no new infrastructure, and is reversible: the code is a thin driver we can fork or replace. It's the lowest-cost way to test whether SMS notifications move the needle in Myanmar before we sign a larger multi-country contract.

For engineering: Standard laravel-notification-channels pattern — credentials (key/secret) and from in config/services.php, a message class, a routing method on the notifiable, and compatibility with Notification::fake(). v2.0.0 adds fluent options on the message: scheduledAt(), encrypt()/encryptKey(), unicode(), deliveryReceiptUrl(), clientReference(). No SDKs, no daemons. Two things to plan for: (1) the v1→v2 upgrade is breaking at the config and ENV level, so sequence it with a credential rotation and avoid a half-migrated deploy; (2) our recommendation stands to wrap it behind an internal SmsSender/SmsChannel interface from day one so Twilio or a second regional provider can sit alongside it without touching product code. Add our own logging around send attempts and our own receipt endpoint behind deliveryReceiptUrl() — including signature/authenticity checks, idempotency on clientReference, and persistence — so observability and cost attribution stay provider-independent, and so encryption key custody remains an explicit, reviewed decision rather than an implicit one.

Caveats to state up front: low adoption and a narrow maintainer base still mean we should pin the version, vendor the package if it goes quiet, and avoid depending on it for anything beyond message dispatch and receipt emission. Treat SMS cost per message, sender ID registration, opt-out/compliance obligations, and — for encrypted messages — key management policy as vendor and legal/security workstreams, not engineering ones.