Vies Bundle Laravel Package

Technical Evaluation

Architecture fit

The package is a Symfony bundle, not a Laravel package — this is the first thing to resolve, because the brief frames it as a Laravel/PHP dependency and it is not. What it actually provides is narrow: a Symfony DI extension, configuration tree, and service definitions that wire the underlying sandwich/vies client into a Symfony container. None of that container plumbing is portable to Laravel's service container. The domain logic — a SOAP call to the EU VIES service and a response object — lives in the underlying library, which is framework-agnostic PHP and is the only part we would realistically consume.

Release 2.2 does not change this. It adds Symfony 6 container support (PR #15, first-time contributor), which is a constraint bump on the bundle's Symfony components range and touches nothing in the domain layer. In a Laravel application the bundle's Symfony constraint is dead weight either way, so the release has zero effect on architecture fit. Architecturally this remains a thin adapter over a legacy SOAP endpoint: no persistence, no queueing, no caching, no resilience layer. In a Laravel codebase it belongs behind our own VatValidator contract, with the library as one swappable adapter implementation.

Integration feasibility

Low technical effort, moderate governance effort — unchanged. MIT license, small API surface, pure PHP. We install the underlying library, bind it in a service provider, and expose it through a facade in well under a day. The bundle itself should still not be installed in a Laravel app; 2.2 makes it installable on newer Symfony, which is not a reason to install it. Pulling in a Symfony bundle for container wiring we will not use adds a dependency for zero benefit and creates confusion for future maintainers.

The one integration-relevant fact to verify: a Symfony 6 constraint implies PHP 8.0+ in the bundle's own CI, which is suggestive but not proof that sandwich/vies is compatible with our runtime. Confirm the underlying library's PHP constraint directly rather than inferring it from the bundle's release.

Technical risk

The risk here is not code quality, it is project health and upstream volatility. The 2.2 release moves one signal but not the conclusion:

• Abandonment risk (high, marginally softened). 2 stars, 0 dependents, and a release after roughly a two-year gap on 2.1 (February 2023). The release is a single drive-by PR from a first-time contributor with no linked issue discussion or roadmap — that is the signature of a one-off compatibility patch, not renewed maintenance. The package is still effectively a single-maintainer project with no visible consumer base. Treat it as vendored code we own; do not read one patch release as a support commitment.
• Transitive risk (high). The real risk sits one level down in sandwich/vies. Release 2.2 says nothing about the underlying client — no companion version bump, no changelog entry — so we cannot tell from the notes whether the client has moved. If that library lags PHP versions or stops tracking VIES SOAP changes, the bundle cannot compensate.
• External service risk (high, and unavoidable). VIES is a federation of 27+ national systems with no SLA and frequent member-state outages. Any design that assumes synchronous availability will fail in production.
• Compliance risk (medium, but the one that matters). VAT number validation feeds reverse-charge decisions on cross-border B2B sales. The evidence trail — timestamp, request, raw response, and the VIES consultation number — is what auditors ask for. Most thin wrappers do not surface or persist the consultation number, and 2.2 does not address this.

Key questions

1. Does the wrapper expose the VIES consultation number and the raw response, or only a boolean? (2.2 does not answer this.)
2. How does it distinguish "invalid VAT number" from "member state unavailable" / MS_UNAVAILABLE SOAP faults? Collapsing those two into false is a correctness bug in a billing path.
3. What are the PHP and sandwich/vies version constraints now that the Symfony range has moved? Does the underlying client clear our minimum PHP, or has the bundle simply widened its own constraint around a stale dependency?
4. Does it handle the post-Brexit cases correctly — GB numbers no longer validating via VIES, and XI (Northern Ireland) numbers that do?
5. Is there any timeout, retry, or caching support, or is that entirely on us?
6. Is there evidence of sustained maintenance beyond 2.2 — open-issue response times, a maintainer of record, a stated support window — or is the release an isolated patch?

Integration Approach

Stack fit

Poor as packaged, adequate as a library. Do not install sandwich/vies-bundle in the Laravel application, including 2.2 — the Symfony 6 support is the only change and it is the part we do not want. Install the underlying sandwich/vies client instead, or evaluate a maintained alternative before committing. A short build-versus-buy spike remains warranted: a hand-rolled SOAP client against VIES is roughly 150 lines and removes the dependency risk entirely; a commercial VAT validation API removes both the dependency and the availability risk at a per-call cost.

Migration path

1. Define a framework-neutral VatValidator interface returning a result object with status (valid / invalid / unavailable / malformed), normalized VAT number, member state, consultation number, and raw response.
2. Implement a ViesValidator adapter wrapping the underlying library. If we later build our own client or buy a provider, only this class changes.
3. Bind the interface in a VatServiceProvider, configured from config/vat.php (timeouts, cache TTL, driver).
4. Add a caching decorator keyed on normalized VAT number, with a short TTL (24h is typical) and never caching unavailable results.
5. Add a fallback driver so the interface can switch to a paid API or a stored-evidence lookup without touching call sites.

Compatibility

The bundle's Symfony constraints are irrelevant in Laravel, and 2.2 only widens them. The underlying library's PHP constraint is what matters — verify it against our runtime before the spike, and do not assume the bundle's Symfony 6 compatibility implies it. Laravel already ships Symfony components, so no conflict is expected at the component level.

Sequencing

Spike (half day, now also confirming the sandwich/vies PHP constraint post-2.2) → interface and result DTO (half day) → adapter plus tests against recorded VIES fixtures (one day) → caching and fallback decorators (one day) → integrate at the single call site that needs it. Ship the interface first even if the adapter is temporary; the abstraction is the durable asset, the dependency is not.

Operational Impact

Maintenance

Assume we own this. A single compatibility patch after a two-year gap does not change that: no dependents means no downstream pressure to fix anything, so plan to fork or vendor the adapter if it breaks. Budget a small recurring line item for dependency review each PHP upgrade cycle, and add the package to whatever policy we use for unpinned or unmaintained dependencies. Record 2.2 in the dependency log as "compatibility patch only — no functional or compliance-relevant change," so the next reviewer does not mistake it for a health reset.

Support

No commercial support, no maintainer SLA, no published support window. Escalation for VIES itself does not exist either — the European Commission publishes status per member state, which is the best signal available. Our on-call runbook should point at that, not at the package.

Scaling

VIES is synchronous SOAP, typically hundreds of milliseconds to multiple seconds per call, with throttling under burst load. Never call it inline on a checkout or registration request without a hard timeout and a defined degraded behaviour. The realistic pattern is: validate asynchronously on capture, cache aggressively, and re-validate only on a schedule or at the point of invoicing. Read-heavy workloads are fine once cached; write-heavy onboarding flows need a queue.

Failure modes

• Member-state outage returning MS_UNAVAILABLE — must not be treated as an invalid VAT number.
• Full VIES outage — needs a documented fallback: accept-and-flag for later verification, or defer the reverse-charge decision.
• Timeout or throttling under load — needs a timeout budget and circuit breaker.
• Upstream library rot after a PHP upgrade — the strongest argument for the interface boundary, and not mitigated by 2.2.
• Regulatory drift — EU VAT rules and member-state participation change; no package in this category keeps up automatically, so a periodic re-verification job is a product requirement, not an engineering nicety.

Ramp-up

For the team, negligible — a competent Laravel engineer is productive with the adapter in a day. The actual ramp-up cost is domain literacy: understanding that "valid VAT number" and "valid evidence for a zero-rated supply" are different things, and that the audit artefact needs to be stored, not just checked. That is the part worth a TPM-owned decision record and a review with finance before we wire this into a billing path.