Product Decisions This Supports
- Payment-method expansion (carrier / direct operator billing): This package is a PHP wrapper around Siru Mobile's payment gateway API. It directly supports the decision of whether to add mobile carrier billing as a checkout option alongside cards and wallets — useful for low-ticket digital goods, in-app purchases, donations, and audiences with low card penetration or prepaid SIMs.
- Build vs. buy at the integration layer: The gateway (Siru) is the buy; this SDK is the glue. Adopting it means we buy telco connectivity instead of negotiating carrier contracts and maintaining per-operator integrations ourselves — a multi-quarter build we almost certainly should not own.
- Checkout architecture and abstraction: Because the SDK is a thin PHP client, it lets us validate a payment-rails abstraction (gateway-agnostic interface, webhook handling, idempotency, reconciliation) without committing to a strategic payment partner.
- Roadmap input for pricing/geo expansion: Choosing Siru affects which markets we can sell into, currency/tax handling, refund flow support, and settlement timing. That constrains regional launch sequencing more than any feature backlog item.
- Risk decision, not just a feature decision: Zero stars, zero dependents, and no release since December 2021 is a material signal. This assessment also supports the "do not adopt / defer" outcome — a legitimate and often correct PM decision.
- Use case triage: Good fits — one-off micropayments, SMS/mobile confirmations, digital content in Siru-covered markets. Poor fits — card-first markets, high-volume subscription billing with dunning and proration, or anything requiring a mature dispute/chargeback workflow.
When to Consider This Package
Consider it when:
- We already have (or are actively evaluating) a commercial agreement with Siru Mobile; the SDK is only valuable as a shortcut to their API.
- The product needs carrier billing in Siru's covered markets (confirm current country and operator coverage directly with the vendor — do not infer it from this repo).
- The stack is PHP/Laravel and the scope is modest: initiate payment, redirect/confirm, handle callback, reconcile.
- We are willing to vendor the code: MIT license means we can fork, patch, and pin it internally. Treat it as sample code, not a maintained dependency.
- We can absorb compliance ourselves — PCI scope, PSD2/SCA where applicable, refunds, and reconciliation remain our responsibility regardless of SDK quality.
Look elsewhere when:
- The business is card-first, or needs wallets, BNPL, or multi-acquirer routing — use a mature provider SDK or an abstraction layer (e.g., Omnipay-style, or the provider's own first-party SDK).
- We need active maintenance: PHP 8.2+/8.3 and Laravel 10/11 compatibility, security patches, and a responsive maintainer. A package untouched since 2021 will not provide this.
- Subscription billing is core: recurring charges, retries, dunning, proration, and revenue recognition are not what a thin gateway wrapper solves.
- Volume or uptime requirements are high: zero dependents means zero production evidence. We would be the first meaningful user, and we would find the bugs.
- We want vendor neutrality as a hard architectural requirement — pinning to a niche gateway's SDK increases switching cost later.
How to Pitch It (Stakeholders)
Executive summary: We evaluated sirumobile/siru-php-sdk, an MIT-licensed PHP client for the Siru Mobile payment gateway. It is a small, forkable integration shim — not a payments strategy. Its value is speed: it could let us test carrier billing in Siru-covered markets in days rather than months, potentially unlocking prepaid and under-banked customers who cannot complete card checkout.
The honest caveats: the package shows no community adoption (0 stars, 0 dependents) and no release since December 2021. That is a maintenance and continuity risk. We should not treat it as a supported dependency, and we should not let it become our only payment rail. Compliance obligations — PCI scope, SCA, refunds, reconciliation — stay with us either way.
To engineering: the SDK is thin and MIT-licensed; plan to vendor/fork it, pin it, add our own error handling, idempotency, and callback verification, and keep it behind a gateway interface so it is replaceable. Budget a short, timeboxed spike (roughly 3–5 engineer-days) including a sandbox end-to-end test; that spike is the real go/no-go gate, not this review.
Recommendation: approve a timeboxed evaluation spike behind an abstraction layer; do not commit to Siru as a strategic payment partner, and do not build a roadmap dependency on this package until the spike and the commercial terms both clear.