Preventgo Bundle Laravel Package

Technical Evaluation

Architecture fit. v2.0.1 does not change the headline finding: mpp/preventgo-bundle is a Symfony bundle, and this release is the clearest possible confirmation of that. A patch whose entire content is "Symfony 7 compatibility" tells you the package's compatibility surface is defined by, and moves in lockstep with, Symfony's release cadence — not Laravel's. Bundles ship a Bundle class, a DependencyInjection\Extension, a Configuration tree, and service definitions wired into Symfony's kernel lifecycle. Laravel has no equivalent; it uses service providers, facades, and a config repository. Nothing here is designed to be booted by Illuminate\Foundation\Application. The TPM framing is unchanged and should be restated to stakeholders: this is an API client with a Symfony delivery vehicle. The reusable asset is the HTTP client, request builders, and response DTOs — not the packaging.

Integration feasibility. Still feasible, still a re-homing exercise rather than an install. The three paths remain, in ascending effort and descending risk:

1. Use the bundle's classes directly inside a Laravel service provider, bypassing the Symfony container. Works only if the client class has framework-neutral dependencies (PSR-18 HTTP client, PSR-17 factories). If it pulls Symfony\Component\HttpClient or the container, this path collapses.
2. Fork and refactor into a framework-agnostic library with a thin Laravel provider/facade on top. Preserves the vendor's request/response contracts and gives us a maintained artifact we control.
3. Rebuild a thin client against the PreventGo API docs, using this repo as reference implementation and field-level schema documentation.

Path 2 remains the recommendation. v2.0.1 slightly improves the odds that Path 1 is viable for a quick spike — Symfony 7 alignment implies fewer legacy API usages inside the client — but it does not resolve whether the transport is container-coupled. Keep that as the go/no-go gate.

Technical risk. The headline risk profile is essentially unchanged, but this release adds three data points that a TPM should weigh honestly rather than dismiss:

• The maintainer responded to an external contribution. PR #3 was merged and shipped, which is the first evidence of any responsiveness in this repo's history. Upgrade the maintenance assumption from "effectively zero" to "low and unverified." That is a real, if modest Improvement — it does not manufacture a community, but it does mean an issue filed with a reproducing bug is not guaranteed to rot.
• Symfony 7 compatibility shifts our own compatibility matrix. Laravel 11 and 12 ship Symfony 7 components; Laravel 10 ships Symfony 6.4. If v2.0.1 widens the constraint to ^6.4|^7.0, this is a clean win and slightly de-risks the composer spike. If it narrows to ^7.0, it silently drops Laravel 10 compatibility and pins us to 11/12. We do not know which, and it matters. Check composer.json before anything else.
• A compatibility change shipped as a patch (2.0.0 → 2.0.1) is a mild semver smell. Adding Symfony 7 support is arguably a minor-version feature; removing Symfony 6 support is arguably a major. Shipping either as a patch suggests the project does not treat semver as a contract. That is an argument for pinning an exact version or commit SHA, not an argument against adoption.

The underlying weaknesses stand: score in the low 2s, 0 stars, 0 dependents, no external validation, no security disclosure channel, a single point of failure at the vendor, no observable test or coverage signal, and unknown handling of credentials, retries, and idempotency. This remains a first-party SDK built for one consumer's use case, not a package designed for third-party adoption.

Key questions for the vendor / repo review (updated for v2.0.1):

• What exactly does the dependency constraint say now — ^6.4|^7.0, or ^7.0 only? This single line determines whether Laravel 10 is in or out of scope and is the highest-value thing to read in the repo today.
• Did the Symfony 7 fix touch runtime code, or only composer.json and deprecation signatures? Review the diff before accepting the "compatibility" framing.
• Was PR #3 community-authored or maintainer-authored? A community merge is a stronger signal than a maintainer patching their own repo.
• Is there CI, and did it run green on the merged PR? Even a trivial workflow would change how much we trust future bumps.
• What is PreventGo actually used for — sanctions/PEP screening, fraud prevention, something else? If it sits in a regulated decision path, the SDK's error semantics become a compliance concern, not just an engineering one.
• Authentication model: static API key, OAuth2 client credentials, mTLS? Where are credentials expected to live?
• Are PSR-18/PSR-17 abstractions used, or is the transport hardcoded to Symfony's HttpClient?
• Synchronous request/response only, or also webhooks/async callbacks for long-running checks?
• Is there idempotency support (client reference keys) to make retries safe?
• Data residency: EU/French endpoints? What does the vendor do with submitted personal data?
• License terms — does forking and redistributing internally remain permitted?
• Minimum PHP version now implied by Symfony 7 (PHP 8.2+)? Does it support 8.3/8.4 cleanly?
• Written API contract, sandbox environment, named support contact?

Integration Approach

Stack fit. Narrow the stated target from "Laravel 10/11/12" to Laravel 11/12 on PHP 8.2+ as the primary target, with Laravel 10 conditional on the constraint question above. This is a change in emphasis, not architecture: v2.0.1 aligns the package with the Symfony 7 component set, which is what Laravel 11/12 already resolve. The recommended shape is unchanged — a first-party PreventGoServiceProvider binding a PreventGoClient interface, a published config/preventgo.php (base URL, credentials, timeout, retry policy), an optional Facade for ergonomics. Transport should be Laravel's Http client or a PSR-18 implementation, not Symfony's HttpClient. Domain objects (screening request, result, status enum) stay plain PHP with no framework imports.

Migration path. No data migration — this is greenfield integration. The "migration" is from Symfony bundle to Laravel-native package, and it remains a deliverable, not glue:

• Week 1: fork at tag 2.0.1, read the #3 diff, strip the DI extension and bundle class, extract the HTTP layer, confirm it runs standalone against a sandbox.
• Week 2: wrap in a Laravel provider + config + facade, add contract tests against recorded fixtures.
• Week 3: integrate into a single low-stakes flow, feature-flagged.

If the vendor is unresponsive or the license blocks forking, fall back to Path 3 and use the repo purely as documentation of the wire format. Note that v2.0.1 does not change this fallback — a Symfony 7 fix adds no value to a Laravel-native rewrite, so the fallback cost is unchanged.

Compatibility. The dependency-resolution spike is now the first task, not an early one, and it should be run twice: composer require mpp/preventgo-bundle:2.0.1 into a scratch Laravel 11 app and a scratch Laravel 12 app, then inspect resolution on symfony/http-kernel, symfony/config, symfony/dependency-injection. If the package declares ^7.0 exclusively, expect a clean resolve on 11/12 and a hard conflict on 10. Record the outcome explicitly in the decision log — it is the fact most likely to be misremembered six months from now. Also confirm the package does not register global container behaviour that would be inert-but-confusing under Laravel.

Sequencing.

1. Vendor/API validation first — credentials, sandbox, confirm response schema and rate limits. Do not write integration code before this.
2. Constraint inspection — read composer.json at tag 2.0.1 and the #3 diff. Five minutes, and it sets the target matrix.
3. Isolation spike — prove the client instantiates outside a Symfony kernel. Single go/no-go gate.
4. Adapter build — provider, config, DTOs, error mapping.
5. Non-critical rollout — one flow, behind a flag, with logging and a manual override path.
6. Expand only after a full quarter of stable operation.

Operational Impact

Maintenance. Assume upstream maintenance is low but no longer zero. v2.0.1 is the first evidence of an actively merged change, so the realistic posture is: we own the integration, but the vendor is not entirely absent. Budget accordingly — pin an exact version (2.0.1) or a fork commit SHA, review diffs before any bump, and do not enable Dependabot auto-merge on a package with one maintainer and no security process. v2.0.1 is also a useful cheap test of that process: it is a small diff, so run it through our review workflow now and find out whether the workflow holds before a larger bump forces the question. Ongoing hours are low — small surface area — but permanently ours.

Support. Still no community, no Stack Overflow corpus, no issue-tracker precedent to search. Escalation runs through the commercial relationship with PreventGo, not through GitHub — a merged PR is not a support channel. Confirm that a named contact and SLA exist before the integration lands in a production path.

Scaling. Unchanged. Throughput: the package almost certainly makes synchronous HTTP calls, so anything on a user-facing request path inherits PreventGo's latency and availability. Push screening to queued jobs where the domain allows, set explicit connect/read timeouts, cap retries. Volume: check rate limits early; per-user-per-day is trivial, per-transaction is not. Cache repeat checks (same subject, within a validity window) as both cost and latency control.

Failure modes. Enumerate deliberately — the wrong answer here is a business incident, not a bug:

• Vendor outage — does onboarding/checkout block or degrade? Decide fail-open vs fail-closed per flow and document it. Compliance screening is usually fail-closed; convenience checks can fail-open with a queued retry.
• Timeout / partial response — retry with idempotency key; never double-submit.
• Auth expiry or key rotation — needs an alert, not a silent 401 swallowed by a try/catch.
• Schema drift — the vendor changes a field, the DTO deserializes to null, and "no match" becomes indistinguishable from "error." This is the most dangerous failure mode in screening software. Enforce strict deserialization and alert on unknown/unmapped fields.
• Constraint narrowing on upgrade — newly relevant. A future Symfony 8 compatibility patch could drop the platform we run on, exactly as 2.0.1 may have dropped Symfony 6. Our fork strategy must be able to sit on a pinned version indefinitely without upstream movement.
• Rate limit / quota exhaustion — a distinct, alertable error class, not a generic exception.
• Silent misconfiguration — missing base URL or credentials should fail at boot, not at first request.

Error mapping stays first-class in the adapter: VendorUnavailable, VendorRejected, RateLimited, AuthFailed, UnexpectedPayload. Every one logged with correlation IDs and dashboarded.

Ramp-up. Low for a Laravel developer — small codebase, familiar concepts. The real cost is institutional knowledge: with zero public references, the only people who understand this integration are the ones who built it. Write an internal runbook covering credential rotation, vendor contact path, error-code meanings, the pinned version and why, and the fail-open/fail-closed decision per integration point. Assign a named owner. Treat the package as a small piece of proprietary infrastructure rather than an open-source dependency, because that is what it functionally is.