Vies Client Laravel Package

Product Decisions This Supports

• B2B onboarding / verification gate. Decides whether a business customer can register with a validated EU VAT number, or must be routed to manual review with documents. This package gives you the raw validity check as a callable primitive, which is the first half of a KYC-lite flow.
• Tax treatment at invoice time (reverse charge). For cross-border EU B2B invoicing, whether you charge VAT or apply reverse charge hinges on a valid counter-party VAT ID. This package is the mechanism by which that determination is made; the pricing and invoicing logic around it is yours to own.
• Launching into EU markets / B2B tier. If the roadmap includes EU B2B customers, VAT-aware onboarding and billing is a prerequisite, not an enhancement. Adoption decision on this package is effectively a decision to build that capability now vs. defer market entry.
• Marketplace / seller verification. If you run a multi-seller product, this is the tool for vetting merchant entities before they can list or receive payouts.
• Audit and compliance recordkeeping. EU rules require retaining the evidence of valid VAT checks. This package provides the response payload but not the persistence, retention policy, or audit trail — those are product decisions it merely supports.
• Build vs. buy vs. wrap. The package is thin (a SOAP client). The real product surface is retry, caching, downtime fallback, rate-limit handling, and storing results. The decision is therefore not "adopt or not" but "wrap this, fork it, or write ~100 lines ourselves."

When to Consider This Package

Adoption criteria:

• You are on PHP/Laravel and already have a SoapClient/WSDL stack you trust, or you're comfortable accepting one.
• Your VAT validation volume is modest (VIES has rate limits and regular maintenance/downtime; a per-check synchronous call in the checkout hot path is a bad idea — you'll cache regardless).
• You need a quick, typed starting point covering the WSDL request/response shapes and don't want to reverse-engineer them.
• You plan to vendor it, wrap it, and own the surrounding logic (caching, retries, fallback to manual review, audit storage).

Look elsewhere when:

• Maintenance risk is unacceptable. 6 stars, 0 dependents, a single small maintainer, and last release Feb 2025 is a signal that this is a reference implementation rather than a supported dependency. Treat it as a template you copy, not a library you pin.
• You need an SLA or vendor support — there is none.
• You need more than "is this VAT ID valid": status disambiguation (valid, invalid, service unavailable), name/address matching, per-country formatting rules, or VAT rate lookup. VIES returns a registration status, not a verdict on whether the counterparty is who they claim to be.
• You're not on PHP, or your stack is async/event-driven and you'd rather call VIES from a queue worker.
• VIES availability is on your critical path. Its periodic outages and maintenance windows mean a synchronous dependency here is a product risk; build the cache and manual-review fallback first.

How to Pitch It (Stakeholders)

To executives: EU customers buying from us cross-border expect us to validate their VAT number before we invoice them — it's both a compliance obligation and the thing that lets us apply reverse charge instead of eating 20% VAT on every B2B deal. VIES is the free EU service that does this. The question in front of us isn't whether to use VIES, it's whether to adopt this small open-source wrapper or write the equivalent ourselves in a day or two. Given the package's negligible adoption and single-maintainer risk, my recommendation is to use it as a reference and internalize the handful of lines it takes to call VIES, then invest our effort in the parts that actually matter operationally: caching results, handling the service's frequent downtime with a manual-review fallback, and retaining the proof of every check for audit. Net: low cost, no licence or per-call fee, and it unblocks EU B2B billing.

To engineering: Treat this as a typed SOAP client, not a solution. It hands you the WSDL request/response shapes; it does not give you retries, circuit-breaking, result persistence, rate-limit backoff, or a distinction between "invalid" and "VIES is down" — all of which we need. Proposed approach: vendor or copy the client, wrap it behind an internal VatValidator interface so the dependency is one file deep, cache successful validations with an expiry, log every attempt (timestamp, VAT ID, response, our user/org) for compliance, and fail closed to "pending manual review" rather than blocking checkout when the service is unavailable. That keeps the blast radius of a stale dependency at roughly zero.