Vies Client Bundle Laravel Package

Product Decisions This Supports

• EU B2B checkout and invoicing. Validating a buyer's VAT number at the point of sale is what determines whether you charge domestic VAT or apply the intra-community reverse charge. That is a direct revenue and pricing decision, not a nice-to-have.
• Self-serve business onboarding. Gating "business account" signup on a valid VAT ID, and auto-filling the registered legal name and address from VIES, cuts manual review and fraud.
• Tax calculation inputs. Feeding a verified tax status into order, invoice, and credit-note logic. This is a small but load-bearing dependency of the billing path.
• Marketplace / vendor verification. Screening suppliers and sellers, and periodic re-validation of stored VAT numbers as a data-hygiene job.
• Build vs buy scoping. This package covers exactly one thing: the SOAP transport and response mapping. It does not cover caching, retries, rate limiting, evidence retention, or fallback — those are the actual product work.

The caveat that should shape the roadmap: VIES returns a point-in-time answer. VAT compliance requires you to retain evidence of the check at the moment of supply — timestamp, request, response, and the number checked. This package gives you none of that. It is a supporting component, and it should not be used to justify a "we are now VAT compliant" claim. Plan the audit-log and evidence-retention work as a separate, non-negotiable deliverable.

When to Consider This Package

Consider it when:

• You are on Symfony and can consume the bundle as intended (service definitions, config tree, DI). This is a Symfony bundle, not a Laravel package, and the name says so.
• Volume is low, or this is internal tooling, a spike, or a proof of concept where 4 stars and 0 dependents do not matter.
• You are already in the Prometee / Sylius ecosystem.
• You want a thin, unopinionated wrapper over the public VIES endpoint with no vendor lock-in, and you are prepared to own the failure modes.

Look elsewhere when:

• You are on Laravel. You will fight the bundle's Symfony wiring. Bypassing it and depending on the underlying client — or writing a ~100-line client yourself — is likely less total work than bending the bundle into a Laravel service provider.
• This sits on a production checkout path with an SLA. The VIES SOAP service has recurring per-member-state outages and rate limits. Commercial providers add caching, retries, circuit breaking, and validation history. If a failed lookup means a blocked checkout, pay for that.
• You need a validation history or audit trail. Open-source VIES clients are uniformly weak here; assume you build it.
• You need VAT rates or US sales tax, not just validity. Different problem, different package.
• Bus factor is a concern. 4 stars, 0 dependents, single maintainer, and a recent release date — treat this as a dependency you may have to fork and own.

Adoption checklist: confirm it targets the current VIES endpoint (the REST API is now the recommended path; SOAP is legacy), confirm it distinguishes invalid VAT number from service unavailable, confirm you can inject a PSR-18 client so you control timeouts and a circuit breaker, and confirm you can stub responses — you cannot hit VIES from CI.

How to Pitch It (Stakeholders)

Executives: This is a small, free, single-purpose library for one EU tax check — validating a business customer's VAT number so we can apply the reverse charge correctly. The library itself is cheap to try; the compliance evidence, monitoring, and fallback behavior around it are our work, roughly one sprint. Recommendation: a one-week spike behind an internal interface, not a production commitment. Treat it as build-vs-buy-lite — if we need reliability guarantees on the checkout path, budget for a commercial VAT validation API instead.

Engineering: A Symfony bundle wrapping the VIES SOAP client. Two viable paths: consume the bundle properly in a Symfony service, or — on Laravel — skip the bundle and depend on the underlying client behind our own VatValidator port. Either way: keep it behind an interface, cache results with a short TTL, model "unavailable" as a distinct state rather than collapsing it into "invalid," persist request/response with timestamps as compliance evidence, and test against recorded fixtures since VIES is not available in CI. Bus factor is high — pin the version and be ready to fork.