EU VAT location of supply and invoicing rules require that certain data be captured and saved for legal reasons (see this overview). The precise requirements depend on the location and the transaction amount, and the pricing itself changes too (different currencies and potentially exclusion from EU VAT or other local taxes), so there is some sort of recursion at play.
You can cut the Gordian Knot by proceeding in a specific order so as to improve UX while making sure you get everything you need (including the all-important payment information handled by Stripe).
This entry belongs to a series of posts on EU VAT + invoicing requirements and (credit/debit) card payment + fulfillment using Stripe:
- legalities
- initial pricing and data capture
- computing the location of supply
- transactional payment and fulfillment
Initial price determination
The first step in the purchase process is presenting correct pricing info to the (still potential) customer. The full information will only be available later in the process, but as a first approximation we use the client IP address to determine whether to present “EU prices” (VAT included, in EUR – non-Eurozone EU customers will be charged in their respective currencies by Stripe with automatic conversion) or “international prices” (USD without VAT).
We use Maxmind’s GeoLite2 IP geolocation database.
The IP address is the one provided by the reverse proxy/load balancer in the
X-Forwarded-For
HTTP header or the remote address from the TCP socket.
Data capture
We then need to capture data until we have everything needed for invoicing and to determine the location of consumption.
In some circumstances, you can get away with less data than that required for the full “2 pieces of evidence + full invoice info” worst-case, allowing to improve UX by omitting things you’re not legally required to have. For instance, in our case, we can skip the customer name and billing address for sales to EU end-users under 400€. This is an optimization that only applies in a few cases, however, so we must implement the full-scale data entry process.
We capture data in this order:
- credit/debit card
- billing address and optional EU VAT number (for businesses)
We already have one piece of evidence at the start of the process, the client IP. Since we’re going to need the card info to perform the payment, by capturing it before the billing address, it’s likely we have the required 2 matching pieces of evidence, which would allow us to skip the name and billing address when simplified invoices can be emitted.
Card credentials
We capture credit/debit card credentials securely (“tokenize” them actually, because we never have access to the credentials) with Stripe’s Elements client-side API. Stripe’s Javascript gives you a token corresponding to the credit card which you can forward to the server in order to create a credit card object with the server API.
At this point, you can retrieve information about the credit card that includes the brand, expiration date and last 4 digits (to show display them in the UI), and the info we need for VAT purposes: the country of the bank that issued the credit card.
Billing address
With some luck, IP-based geolocation and (card) bank country match at this point, and we know whether it is possible to emit simplified invoices and skip customer name and full billing address.
In many cases, though, even a matching IP + (card) bank country are not enough to be 100% sure about the VAT rate, because of the territories related with EU countries where EU VAT rules do not apply and non-EU countries and territories are subject to EU VAT (e.g. Monaco paying VAT in France). The extra piece of evidence needed to know whether the customer is in such a territory is the postal code.
Thus,
- for most EU sales you’ll want to obtain the self-reported country of residence and postal code in order to know the actual VAT rate (even for simplified invoices)
- when simplified invoices won’t do (e.g. threshold exceeded or B2B sale with EU VAT number) you need the whole package: name + billing address
Keep in mind that some countries do not have postal codes so the UI has got to handle this.
EU VAT number
Corporate customers with a EU VAT number (provided by a national tax authority) will demand invoicing (and pricing) without VAT (“reverse charge”).
We check the VAT number with the VIES service.
The VIES service works by querying the (28, as of May 2019) national VIES components, and technical issues are not rare. It is possible to check whether the service is available (so as to provide more meaningful error messages in the UI) with the VIES’ testing facilities.
B2B supplies carry no VAT charge (the customer accounts for the tax with the reverse-charge mechanism) and are thus unaffected by the VAT location rules. So there’s no need to worry about non-conflicting pieces of evidence, etc. Still, it is a good idea to check that the member state that issued the VAT number (encoded in the 2-letter prefix) is the same as the self-declared country in the billing address (modulo anomalies like Monaco). There is a gotcha here: the prefix does not always correspond to the ISO 3166-1 country code; Greece uses “EL” instead of “GR”. Refer to these lists.