Laravel Vat Laravel Package

Technical Evaluation

Architecture fit

• Thin Laravel service-provider wrapper around a PHP VAT validation/rate library. It fits naturally into Laravel’s service container and config-publish pattern, making it a low-ceremony dependency for checkout, invoicing, or B2B onboarding flows that need EU VAT number checks or VAT rate lookup.
• Small surface area is an advantage: a TPM can treat it as a commodity adapter rather than a platform component, provided the business only needs validation/rate lookup and not full tax determination.

Integration feasibility

• Composer install with Laravel auto-discovery is straightforward on supported framework versions. The main constraint is the archived status and 2022 release date, which likely means no Laravel 10/11 support and stale dependency constraints.
• Feasible as a short-term or internal-only dependency; not advisable as a long-term strategic dependency without a fork-and-own plan.

Technical risk

• High maintenance risk: archived repository, last release September 2022, zero dependents. No upstream security patches, no Laravel compatibility updates, and no fixes for VIES endpoint or certificate changes.
• Domain risk: VAT rates and VIES behavior change; a stale package can produce incorrect tax calculations or validation failures. MIT license permits forking, which is the primary mitigation.
• Compliance risk: silent fallback behavior (e.g., treating an unvalidated VAT number as valid or defaulting to zero-rate) must be explicitly controlled in the integration.

Key questions

• Do we need VAT number validation only, VAT rate lookup only, or full tax calculation?
• Which countries and transaction types are in scope, and is VIES the required source of truth?
• What is our current Laravel/PHP version, and does the package’s composer constraints allow it?
• Are we willing to fork and own the package, or should we replace it with a maintained alternative or direct VIES integration?
• What is the acceptable failure mode when VIES is unavailable — block checkout, queue for later validation, or allow with manual review?

Integration Approach

Stack fit

• Best fit for Laravel 8/9-era applications on PHP 7.4/8.0/8.1. Confirm composer constraints before committing. If the product is on Laravel 10+, assume incompatibility until proven otherwise.
• The package should sit behind an internal VatService interface so the underlying implementation can be swapped without touching checkout or billing code.

Migration path

• Preferred path: wrap, don’t embed. Introduce the package behind a first-party abstraction, evaluate it in a spike, then decide whether to fork or replace.
• If incompatible with the current framework, fork the package, update composer constraints, and run the existing test suite against current Laravel. If the underlying VAT library is also stale, replace that dependency or call VIES directly.
• Maintained alternatives or direct VIES SOAP/REST integration should be evaluated in parallel; the package is small enough that replacement cost is low.

Compatibility

• Verify PHP version, Laravel version, and dependency constraints first. Also verify VIES API compatibility: endpoint, TLS/certificate handling, and response format.
• Check whether the package caches VAT rates or validation results; if not, add caching at the application layer to avoid per-request VIES calls.

Sequencing

1. Discovery spike: confirm scope (validation vs rates), current stack compatibility, and VIES requirements.
2. Build a thin internal VAT interface and implement an adapter using the package.
3. Add caching, timeout, retry, and fallback policies around VIES calls.
4. Shadow-mode compare package outputs against VIES directly or a maintained alternative for a sample of VAT numbers.
5. Feature-flag rollout; retain the ability to switch providers without a release.

Operational Impact

Maintenance

• Ownership must be assigned. If adopted, assume fork ownership: dependency updates, VIES endpoint changes, VAT rate refreshes, and Laravel upgrade compatibility.
• Budget a small but recurring maintenance line item; this is not a “set and forget” dependency.

Support

• Community-only support via GitHub issues, with no SLA and an archived upstream. Internal runbooks and an escalation path to the owning team are required.
• Document known limitations, especially around VIES availability and rate staleness.

Scaling

• VIES calls are the scaling bottleneck: network latency, rate limits, and downtime. Cache validation results per VAT number with a defined TTL and cache VAT rates locally.
• Avoid synchronous VIES calls in hot checkout paths; use async validation or queue-based revalidation where business rules allow.

Failure modes

• VIES outage or timeout: define whether to block, queue, or allow with manual review. Never silently treat unvalidated numbers as valid.
• Stale VAT rates: can cause incorrect invoices and compliance exposure. Refresh rates on a schedule and monitor for divergence.
• Dependency rot: framework upgrades will eventually break the package; the fork plan must include a compatibility test in CI.
• Certificate/TLS changes at VIES: can break validation without code changes; add health checks and alerting.

Ramp-up

• Low technical ramp-up: small codebase, familiar Laravel patterns. The real ramp-up is EU VAT domain knowledge — reverse-charge rules, VIES semantics, and evidence requirements.
• A TPM should pair engineering with finance/tax stakeholders during the spike to validate business rules before rollout.