A French company enters its VAT ID at checkout, Stripe applies reverse charge logic, and the invoice goes out as tax-exempt. Two days later, finance finds the number was malformed, VIES was unavailable during the request, and the customer now has the wrong tax treatment on a paid order. Fixing that after payment is slower, messier, and more expensive than validating the number before the charge is confirmed.
EU VAT validation is a checkout concern because tax treatment depends on it in real time. If the VAT ID is invalid, missing a country prefix, or formatted with stray spaces and punctuation, you can exempt tax when you should not, or charge tax when you should not. Both create avoidable support work. One ends in amended invoices and tax corrections. The other creates friction with legitimate B2B buyers who expect reverse charge handling to work on the first attempt.
VIES adds another production problem. It is useful, but it is not a service you should treat like a perfectly reliable dependency in the middle of payment confirmation. Timeouts happen. Member state endpoints can fail. Response formats can be inconsistent enough that brittle SOAP wrappers break on edge cases long before your tax logic does. A better pattern is to normalize the input first, validate against strict country-specific rules, call VIES with bounded retries, and cache both positive and negative results with different TTLs. Positive matches usually deserve a longer cache window. Transient failures do not.
That changes how checkout should be wired. Collect the VAT ID early, normalize it before any external request, and only mark the customer as tax-exempt after a successful validation state you can explain later in logs. If VIES is down, do not guess. Put the transaction on a fallback path: charge VAT, flag the account for revalidation, or let the buyer continue with clear messaging and reconcile before issuing the final invoice. The right choice depends on your risk tolerance, refund volume, and whether billing happens instantly or on account approval.
Stripe does not remove this responsibility. You still need a decision layer between customer input and tax handling. In practice, that means storing the normalized VAT ID, validation status, last checked timestamp, VIES response outcome, and the reason for any fallback. Those fields make retries safe, keep idempotency intact, and give support a clear audit trail when a buyer asks why VAT was charged.
If you want the billing side to stay sane as volumes grow, build VAT validation like infrastructure, not a one-off API call. That is also how teams handle VAT payments efficiently without turning every VIES wobble into a checkout incident.