Easy Sms Laravel Package

Product Decisions This Supports

• Build vs. buy for SMS delivery: Treat overtrue/easy-sms as the commodity layer. It abstracts 30+ Chinese and regional SMS providers behind one send() call, so the team writes and maintains a single integration instead of per-provider HTTP clients, signing logic, and response parsing. A PM should assume "buy the abstraction, negotiate directly with the providers" rather than funding an in-house SMS gateway.
• Multi-provider failover as a product requirement, not an ops detail: The OrderStrategy and pluggable strategy system let you send through ['aliyun', 'yunpian', 'juhe'] and fall through on failure — this is what makes an "SMS always arrives" SLA credible for OTP, order notifications, and transactional alerts. Roadmap items that depend on message delivery reliability can be committed against this.
• Provider swap as a low-cost roadmap lever: Pricing negotiations, provider outages, and mainland-China compliance changes are a config change plus a small adapter, not a sprint. That materially de-risks any roadmap item touching notifications, marketing SMS, or international expansion.
• Channel/locale expansion: PhoneNumber with an international dialing code, plus dedicated Aliyun international and Chuanglan international configs, means "send OTPs to overseas users" is an incremental slice rather than a new subsystem.
• Notification taxonomy as a product artifact: Extending Overtrue\EasySms\Message lets each business event (order paid, verification code, refund) declare its own content, template ID, variables, and gateway preference in one place. This gives PMs a clean mapping from product events to customer-facing messages, and a single place to review copy and compliance wording.
• Observability and support tooling: The uniform return shape (gateway, status, result/exception per provider) plus NoGatewayAvailableException::getResults()/getExceptions()/getLastException() is exactly the data a support team needs to answer "did the customer get their code?" and to attribute failures to a specific carrier.
• Build-vs-buy for the notification channel: If the product is Laravel-based, the companion yl/easysms-notification-channel makes SMS a first-class Laravel Notification channel — worth evaluating before anyone proposes a bespoke notification microservice.
• Cost and vendor strategy: Because adding a provider is cheap, a PM can run multi-vendor (primary + backup, or per-region primary) without an engineering program. This is a lever for pricing leverage and for regulatory redundancy.
• Not a fit for: rich messaging (WhatsApp, RCS, push, email), inbound SMS handling, two-way conversational SMS, or marketing campaign management/campaign analytics. Those need separate decisions — do not let "we already have EasySMS" quietly become the answer.

When to Consider This Package

Adopt when most of the following hold:

• PHP 8.4+ and Composer in the stack; the README states PHP >= 8.4, so confirm your runtime before committing — this is the single most likely adoption blocker on legacy Laravel apps.
• Your delivery footprint is predominantly Chinese providers, or you need a mix of Aliyun/Tencent/Yunpian/Chuanglan-style gateways behind one interface. The supported list is overwhelmingly China-market; Western providers (Twilio, Vonage, MessageBird) are absent, so this is not a global-first SMS layer.
• You want provider redundancy — OTP flows, transactional notifications, or any flow where a single-carrier outage is a customer-visible incident.
• You send from a small number of fixed templates with variables, which maps cleanly onto template + data.
• You are on Laravel and want notifications to flow through the framework's channel system rather than custom service calls.
• Operational maturity signals are acceptable: MIT licensed, ~3.3k stars, an active release cadence (most recent release dated 2026-09-30 in the supplied data), and documented releases/README. Note the recorded Dependents: 0, which likely understates real usage in the PHP ecosystem — verify with your own dependency audit rather than treating it as a signal either way.

Look elsewhere when:

• You need Western/global carriers as first-class citizens. You could write a custom gateway via extend(), but at that point you are maintaining the abstraction for one provider — a thin direct client may be simpler.
• You need inbound/two-way SMS, delivery-receipt webhooks as a product feature, or campaign/broadcast management with segmentation and analytics. EasySMS is an outbound send abstraction; it does not model conversations or campaigns.
• You need guaranteed vendor support, SLAs, or a commercial relationship. This is a single-maintainer community package under MIT — no support contract, no indemnity.
• Your compliance posture requires a vetted, auditable vendor for message content and PII handling. Do a security review of the package and of each gateway's data flow; the abstraction does not add compliance guarantees.
• The team has no PHP depth or the service is polyglot and SMS is a shared platform concern — a language-agnostic internal service may be the better long-term call.
• You need advanced routing logic (cost-aware routing, per-country rules, A/B on delivery rates). Custom strategies are possible, but you will be writing and owning that logic.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We can add reliable SMS delivery without building or operating an SMS platform. overtrue/easy-sms is a mature, MIT-licensed PHP library that puts 30+ SMS providers — including Aliyun, Tencent Cloud, Yunpian, and Chuanglan — behind a single, uniform interface, with built-in automatic failover across multiple providers and one consistent result format for logging and monitoring. The business consequence: one integration instead of many, provider outages that degrade gracefully instead of taking down OTP and order notifications, and the ability to switch or add carriers on commercial or regulatory grounds as a configuration change rather than an engineering project. Cost is limited to provider usage and a small integration effort — there is no licence fee.

For engineering — what you are actually adopting:

• One EasySms client, config-driven gateways, send($number, $message, $gateways = null) with per-send gateway overrides.
• OrderStrategy by default; strategies are pluggable, so cost- or region-aware routing is an extension point, not a rewrite.
• Per-message classes extending Message encapsulate content, template ID, variables, and gateway preference — this is the natural home for our notification catalog and keeps copy/compliance review in one place.
• content/template/data accept closures receiving the gateway, so provider-specific template IDs and wording are handled without branching in our domain code.
• Uniform per-gateway result array; NoGatewayAvailableException exposes getResults(), getExceptions(), getException($gateway), getLastException() — wire these into our logs and alerting from day one.
• extend() covers any provider not in the list; PhoneNumber handles international dialing codes.
• Companion yl/easysms-notification-channel if we want SMS as a Laravel Notification channel.

Decisions and caveats to put in front of stakeholders:

• Verify the runtime requirement first. PHP >= 8.4 is explicit; if any service we intend to use is on an older runtime, that upgrade is part of the true cost and should be scoped before we commit.
• Scope is outbound, China-centric SMS. This is not our answer for email, push, WhatsApp/RCS, inbound messages, or campaign management. Those remain separate decisions — say so explicitly so the package does not get over-scoped later.
• Single-maintainer, community-supported MIT dependency. Mitigate with a fork-and-pin policy, a lockfile, a smoke test that exercises at least two gateways in staging, and a documented fallback if the project stalls. Review the AGENTS.md maintenance guidelines — minimal diffs, no public API changes, no new dependencies — as a signal that upstream expects conservative, reviewable contributions if we ever need to patch.
• Ask for a small, time-boxed spike before roadmap commitment: integrate two providers (primary + backup), demonstrate a forced failure and successful failover, confirm logging captures per-gateway results, and measure end-to-end OTP latency. That test converts this assessment into a defensible build-vs-buy recommendation and gives us the real numbers for the reliability claim.