#karsh-tax-id
1 messages ยท Page 1 of 1 (latest)
Hi there ๐ I think the closest thing we're going to have is an endpoint that allows you to create a Tax ID:
https://stripe.com/docs/api/customer_tax_ids/create
It's worth noting that we don't perform validation on all types of tax IDs. The list of ones that we do validate can be found here:
https://stripe.com/docs/billing/customer/tax-ids#validation
Thanks Toby. In the first link I still need to give ther 'type' by myself. So I think that confirms that I need to write my own logic that decides which type it has to be?
Based on address/country input?
Well it's basically this table I think: https://stripe.com/docs/billing/customer/tax-ids#supported-tax-id
You'll likely want to have a way for your customers/users to tell you what type of tax ID they're providing. If you look through that table you'll notice there about 6 types that expect to receive a 9-digit number, so scenarios like that would make it difficult to parse the type of tax ID you're being provided from the ID alone.
I see... so I'm trying to replicate Stripe Checkout's logic. I see it asks for Country or region, and then the VAT ID:
However if I change it to US, the vat info dissapears altogether:
So if I understood correctly: Stripe Checkout has got logic that checks information it needs depending on:
- Location of the customer
- Location of the seller
So in both examples the location of the seller is the Netherlands.
In example 1, the buyer is also in the netherlands (but if I change this to other european countries the form stays the same).
Now it doesn't show the full billing address input fields, beacuse as per https://stripe.com/docs/tax/customer-locations - we don't need more than a Country for other places than the US and Canada.
Correct?
Secondly, in example 2: the country is set to US. So it does 2 things:
- Ask for more billing information (beacuse of the last doc link)
- REMOVES the 'I'm purchasing as a business' checkbox.... Why is this? Because the seller country the Netherlands and thus already we don't need to do anything with US taxes, so it skips this question altogether?
And last question: this logic that Stripe Checkout has... this is all NOT available in the api in any way. correct?
The only thing available is tax id validation, which happens when you add BOTH a tax ID type and value to a customer or order?
Correct, the information that we must collect fluctuates based on geographies and Checkout Sessions take this into account.
This I'm not certain of off the top of my head and would need to look into it further.
If it helps, here's a quick video showing what I'm doing:
If you pass incomplete information for a scenario, then the API should raise an error indicating that it does not have enough information to complete the request successfully, but you're correct that there is not an endpoint which would allow you to query exactly what information you'll need to collect for a specific scenario.
Thank you, but my suspicion is that it's a matter of tax policy. My (possibly naive) guess currently is that US companies can't be exempt from EU VAT, or that cross-border transactions of that nature incur a different type of tax, but I'm not entirely sure.
Ah okay, so either way - whatever the policy behind this. There is again logic made by Stripe Checkout, which I'd have to replicate by myself. This logic is not avialable for us to use?
So basically summarised, it's not that simple to use Orders api and make sure all tax information is conforming to regulations. As the payment element doesn't ask for extra info when stripe tax is enabled. Only Stripe checkout makes that easy?
Within the Order object, there is an automatic_tax.status hash that I think would be beneficial to this flow, as it indicates whether additional location information is needed:
https://stripe.com/docs/api/orders_v2/object#order_v2_object-automatic_tax-status
But yes, as far as I know you will need to build flows to handle these various pieces of logic.
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.