#thomasv_checkout-address
hollow citrusBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1508954563540025516
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
wise storm
Hi there,
I understand what you are saying and where you are coming from. But it's an intentional tradeoff. Not everyone who uses customers, needs a valid address or use automatic tax. So yes, for tax validation reasons an address is in most cases a hard requirement, but again not every use cases includes tax.
So in your case I would recommend validating on your end, that an address exists on the customer before createing the checkout session
coarse mist
hi Vegvisir,
Thank you for the prompt response. The initial cause of this is users setting "State" to teh value of other administrative partitions ("regions" in Frrance, or "County" in Ireland, etc.)
Would be great if the design choice is explicit, to maybe have a programatic way to validate a given address meets the "schema expectations" of more restrictive endpoints
My address payload was
"address"
: {
"city":
"Massy",
"country":
"France",
"line1":
"Jean Giono 73700",
"line2":
"",
"postal_code":
"73700",
"state":
"Ile-deFrance",
}
The non-validity here comes from the fact that "state" is not empty with a country that's not US/Canada/Australia it seems. Which makes the validation on my side a lot less straight-forward than just checking emptiness
wise storm
How are you collecting the address? I'm only asking because if you are using the Address Element to collect customer data, it only renders the necessary fields. Like for France, it does not show an inout field for state.
hollow citrusBOT
shy timber
thomasv_checkout-address
Hey @coarse mist the problem is country should be a 2 letter code, so FR
It's a longstanding issue that our API doesn't properly validate this. It's just not an easy fix as it could break a large portion of our users
coarse mist
@wise storm : it's coming from my software (user input), it's pretty standard international schema, but it's not very constrained either.
@shy timber : thanks for jumping in! I have no doubt that it's not a quick fix at this stage. I'd give the 2 letter code alpha-2 a chance (it's documented actually, my bad)
shy timber
yeah we document it but never enforce it and then it breaks Tax in that really weird way. We're working on a Country name -> Country code logic that could alleviate this. But we looked at the data and people put a lot of stuff in there. Some are easy like United States -> US but when the country name is in a different language it's much harder to do reliably 🙁