Smpp Client Bundle Laravel Package

Product Decisions This Supports

• SMS transport strategy: direct SMPP bind vs. HTTP aggregator API. This package exists to answer one question cheaply: “do we hold a persistent SMPP session to an SMSC/aggregator, or do we call Twilio/Vonage-style REST endpoints?” It supports that decision by making the SMPP path a low-friction thing to try, inside an existing PHP codebase, rather than something that requires standing up a separate service. A PM should treat it as a spike tool, not an architecture commitment.

• Build vs. buy on messaging infrastructure. A thin wrapper over a known-good protocol library (onlinecity/php-smpp) is the “assemble” option: you own session lifecycle, retries, and queueing; the vendor owns the SMSC and the carrier relationship. The package itself is evidence for the “buy/assemble” pole — it demonstrates how little glue is needed on your side once a library exists, and how much of the real work (connection, DLR correlation, reconnection) is operational rather than code.

• Unit economics and margin at volume. SMPP binds are the lever for per-message margin, throughput per connection, sender-ID control, and native delivery receipts. If the roadmap includes OTPs, transactional alerts, or notification volume where per-message cost is a line item, prototyping this path gives you real numbers to negotiate with, instead of assumptions. That’s a decision a PM can defend with data.

• Reliability and failover architecture as an explicit design commitment. SMPP forces decisions PMs usually defer: reconnect/backoff policy, DLR correlation, multi-vendor failover, dead-letter handling. Standing up even a prototype surfaces those as roadmap items with owners and timelines rather than surprises post-launch.

• Roadmap gating: platform modernization. The package targets PHP 5 / Symfony 2. In a Laravel context that is already the wrong stack. Adopting it is a decision about not modernizing whatever service it lands in — a legitimate short-term call for a frozen legacy service, but one that must be recorded as technical debt with an exit date.

• Sourcing and risk posture. With 4 stars and 0 dependents, this is a single-team fork of a fork. The PM decision it informs is whether to vendor/pin and own it internally, or treat it strictly as a throwaway spike. Either way, the package itself is a reference implementation, not a dependency you inherit.

When to Consider This Package

Consider it (narrowly, as a spike) when all of the following hold:

• You have a running Symfony 2.x / PHP 5.x application you cannot upgrade this quarter, and you need an SMPP bind in that codebase rather than in a new service. If you are on Laravel (any modern version) or PHP 7.4+/8+, this package is the wrong artifact — go straight to the underlying library or a maintained alternative.
• You already hold SMPP credentials from an SMSC or aggregator that offers a direct bind, and the aggregator supports the capabilities you need (throughput tier, sender ID, DLRs).
• Your use case needs capabilities HTTP APIs often abstract away: persistent sessions, high throughput, sender-ID control, raw DLRs, multipart/long SMS, UDH and data_coding handling.
• You can run a long-lived worker or daemon (Symfony command, supervisor-managed process, or any queue consumer) — SMPP is a socket session, not a request/response call, and PHP-FPM’s model is fundamentally hostile to it.
• You accept owning the fork: pin the commit, audit the socket and reconnect logic, write tests around submit_sm / deliver_sm, name a maintainer, and put it behind an internal MessageSender interface so the transport is swappable.

Look elsewhere when:

• You are on Laravel / PHP 8+ / modern Symfony. The bundle’s DI wiring and PHP 5 idioms don’t carry over. Use onlinecity/php-smpp directly (or a maintained fork), and write your own Laravel service provider — you’ll get the same capabilities with a fraction of the legacy surface.
• You need maintained upstream support. 4 stars, 0 dependents, and a fork-of-a-fork mean a bus factor of roughly one. No security response, no PHP version tracking, no issue activity.
• Your volume is low or bursty (a few thousand messages/month). A commercial HTTP API with retries, status callbacks, and a support contract is cheaper than operating a bind, once you price in on-call.
• You need multi-channel (SMS + WhatsApp + RCS + push) behind one abstraction. An aggregator SDK or CPaaS gives you that; an SMPP bundle does not.
• You want queue-native, async delivery. Regardless of library, the right pattern is: enqueue messages, run the SMPP session in a dedicated consumer. This package doesn’t change that shape and doesn’t make it easier.

How to Pitch It (Stakeholders)

To executives: We are evaluating how we send SMS — through a per-message HTTP vendor API, or over a direct SMPP connection to a carrier or aggregator. This package is a low-cost way to prototype the direct path inside an existing PHP app so we can measure real throughput, delivery-receipt behavior, and per-message cost before committing to a multi-year vendor or build decision. The strategic upside is margin at volume and sender-ID control. The risk is that the code itself is an unmaintained Symfony2 fork with effectively no community — so we would treat it as internal, owned, and temporary, never as a dependency we lean on. Recommendation: run a two-to-four week spike behind an internal MessageSender interface, capture measured cost and delivery quality, and then choose between a maintained open-source client, a commercial SMPP aggregator, or a CPaaS. Do not let it become permanent infrastructure by default.

To engineering: This is a Symfony2/PHP 5 bundle wrapping onlinecity/php-smpp — a genuine SMPP 3.4 implementation (bind_transceiver, submit_sm, deliver_sm for DLRs and MO, enquire_link keepalive, UDH/multipart). It is not a Laravel package and is not adoptable on a modern stack — the container, config, and event wiring have no Laravel equivalent, and the PHP 5 syntax will break on PHP 8. If we pilot it: vendor and pin the source, extract the underlying SM\* classes and discard the Symfony bundle glue, wrap them in a Laravel service provider, isolate behind a transport-agnostic interface, and run the session in a supervised long-lived worker or queue consumer — never in a web request. Instrument reconnect/backoff and DLR correlation explicitly; those are where SMPP integrations fail in production, and this bundle is not going to give them to us. Budget the follow-on now: reimplementation on PHP 8 with a maintained client or a managed SMPP vendor, with the bundle serving only as a protocol reference during the spike.