Siru Php Sdk Laravel Package

Technical Evaluation

Architecture fit The package is a vendor SDK for a single upstream (Siru Mobile, carrier-billing / mobile payments), so its natural role is an isolated outbound payment adapter behind a domain-owned interface. It should not leak Siru DTOs, status enums, or HTTP exceptions into application code; wrap it in a PaymentGateway port with Siru-specific mapping in one adapter class. That keeps the blast radius small if the package is abandoned and lets you swap to a direct HTTP client or another PSP without touching checkout, order, or reconciliation logic.

A payment SDK also sits on a trust boundary: request signing, callback verification, and idempotency keys must be treated as security-critical rather than convenience utilities. Because the SDK is thin (typical Guzzle/curl client plus payload builders), assume it does not give you retry logic, idempotency guarantees, or webhook replay protection — those belong in your application layer regardless of what the SDK ships.

Integration feasibility Mechanically this is low-effort: Composer install, bind a client singleton in a service provider, expose a facade or inject the adapter. The real effort is not wiring but due diligence on the contract: which Siru API version the SDK targets, whether it covers the payment methods you need (initiate, status, refund, cancel, settlement report), and whether it implements the current signature scheme. A 2021 SDK against a live payment API is a genuine risk of speaking a deprecated version.

Technical risk

• Maintenance abandonment. Last release 2021-12-22, zero stars, zero dependents. This is effectively a single-vendor artifact with no community, no visible downstream usage, and no proof anyone else runs it in production. Treat it as unmaintained unless Siru confirms active stewardship.
• Dependency rot. PHP and Guzzle version constraints from 2021 may conflict with current Laravel skeletons or force you onto unsupported transitive versions — a supply-chain concern for a package that handles payment credentials.
• Low validation signal. A score of 0 with opportunity 21.98 reflects no adoption evidence; absence of tests/CI and no security disclosure process are the defaults you should assume until proven otherwise.
• Regulatory surface. Even for carrier billing (lower PCI scope than card acquiring), you still own auditability, log redaction of MSISDNs and tokens, and reconciliation evidence.

Key questions

1. Which Siru API version does the SDK target, and is it still current? Is there a changelog and a stated support/deprecation policy?
2. Does Siru officially maintain this repo, and will they accept security reports and patch releases?
3. Is the callback/webhook signature verification implemented, and is it constant-time and replay-safe?
4. What is test coverage and CI status? Are there recorded-fixture or sandbox integration tests?
5. Stated PHP and Laravel support matrix; are composer.json constraints PSR-4/PSR-18 compliant and free of abandoned transitive deps?
6. Does it expose idempotency keys, timeouts, and structured error types — or only raw HTTP responses?
7. Licensing/redistribution: MIT permits forking and vendoring, but confirm the code is Siru-authored and not third-party-derived.

Integration Approach

Stack fit Fits Laravel cleanly as a boundary adapter, not a core dependency: one SiruGateway class implementing your PaymentGateway interface, one service provider for config (SIRU_* env vars, credentials in a secrets manager not .env in prod), and no facade exposure to controllers. Keep the SDK out of domain models entirely so a future fork-and-vendor or replacement is a one-file change.

Migration path Plan for the SDK being a starting point, not a foundation. Two paths:

• Preferred: vendor/fork the package into app/Support/Siru or a private VCS repo. You gain MIT-licensed code you can patch, pin, and audit without upstream cooperation.
• Fallback: reimplement a ~300-line client against Siru's documented REST API using Laravel's HTTP client, keeping the same adapter interface. Given the package's size, this is often cheaper than inheriting an unmaintained dependency.

If Siru later publishes a maintained SDK, the adapter interface makes the swap a contained change with no schema or UX impact.

Compatibility Verify before committing: PHP constraint vs. your runtime, Guzzle/PSR-7/PSR-18 versions against your lockfile, and whether Laravel's HTTP client and the SDK can coexist without duplicate Guzzle major versions. Check for illuminate/* constraints that pin you to an EOL Laravel. Run composer why-not and a dependency audit (composer audit) as a gate.

Sequencing

1. Spike (1–2 days): read the source end-to-end, map endpoints to Siru's public API docs, confirm signature scheme and API version.
2. Sandbox proof: obtain test credentials, execute initiate → redirect → callback → status → refund against Siru's test environment, capturing payload fixtures for contract tests.
3. Adapter build: wrap in the interface, add idempotency keys, timeout/retry policy, structured error mapping, and log redaction.
4. Hardening: webhook signature verification, replay protection, reconciliation job against Siru settlement/status API.
5. Staged rollout: feature-flag behind a second gateway, low-value transactions first, then widen. Keep the legacy/manual path live through at least one settlement cycle.

Operational Impact

Maintenance Ownership sits with your team, not the vendor. Budget an ongoing patch-and-audit cadence: quarterly dependency review, composer audit in CI, and a documented fork point. With no upstream activity since 2021, assume you will be the maintainer; treat any future upstream release as a diff to review rather than a version to adopt. MIT licensing makes this legally clean, but it is still real engineering time.

Support Two support surfaces: Siru's merchant/technical support (SLA, escalation path, incident comms) and your internal on-call. The SDK itself provides no support channel — no issues activity, no dependents to consult. That means payment incidents have no community fallback: your runbook must include how to call Siru's API directly when the SDK misbehaves. Confirm merchant support terms, sandbox availability, and a named technical contact before go-live.

Scaling Payment traffic is low-volume relative to typical web traffic, so the SDK's performance is rarely the constraint; correctness and idempotency are. Scale risks are:

• Synchronous calls inside checkout requests — enforce timeouts and circuit-breaking so a Siru slowdown degrades gracefully rather than exhausting PHP-FPM workers.
• No built-in connection pooling or retry backoff — add jittered retries only on idempotent operations.
• Webhook bursts after an outage — queue and process asynchronously with deduplication on Siru's transaction reference.
• Carrier-billing-specific limits (per-operator caps, currency and MSISDN rules) are business logic you must enforce above the SDK.

Failure modes

• Silent acceptance of unverified callbacks — highest-severity risk; validate signatures and reject unsigned payloads.
• Duplicate charges from retries without idempotency keys, or from webhook redelivery treated as new events.
• Lost state when redirect completes but callback never arrives — requires a reconciliation poller, not just webhook handling.
• Version drift — Siru changes an endpoint; the frozen 2021 client fails at runtime with opaque errors. Mitigate with adapter-level contract tests against sandbox on a schedule.
• Credential leakage via verbose SDK logging of full request bodies.
• Dependency compromise from an unmaintained transitive package in the payment path.

Ramp-up Low code ramp-up (small, readable surface), moderate domain ramp-up. Engineers need: Siru's payment lifecycle and settlement model, carrier-billing constraints (operator coverage, refund windows, currency), your reconciliation and refund workflows, and the incident runbook. Plan roughly a week for a mid-level engineer to be productive against the sandbox and two to three weeks to own the integration confidently. Document the adapter's contract and the fork rationale in an ADR so the next engineer does not re-litigate the build-vs-SDK decision.