#Mayhul
bleak saddle
autumn edge
Hi there
Yep you need to set the necessary address on the Customer to be able to have it work in test mode just like live mode
So you basically need one of https://stripe.com/docs/tax/customer-locations#address-hierarchy
analog hedge
Are there sample addresses available that I can use that will trigger an exclusive tax? I want stripe.invoices.retrieveUpcoming to return a nonzero value for tax
Additionally, does Stripe do any kind of semantic validation on the address passed in via the Address Element? Do we need to some kind of checking to see if the user is just entering random input into "line1" and "line2" of the address?
autumn edge
You should be able to use any actual address in testmode... most times you just need a country/zip and you can use https://stripe.com/docs/tax/supported-use-cases for where charges versus does a reverse charge
Yes AddressElement does handle validation errors for you: https://stripe.com/docs/elements/address-element?platform=web#use-address-element-with-other-elements
analog hedge
Got it! We're using Stripe Connect so I just needed to log in to our test Connect account & add tax registrations in Test mode there. It's working now
So do you have an example of when an "unrecognized_location" label would be added to a customer after they submit from the address element?
For example, if I enter an invalid zip code, would that result in the address getting saved, but the user having a "unrecognized_location" label. Or would that be validated earlier in the process?
analog hedge
Yes, but the addressElement and payment element are in different element groups.
Because we need to create the subscription before showing the payment element, which requires collecting the address for the customer first. let me know if I'm incorrect there
Our flow is: Customer enters address in AddressElement -> We create customer object with address -> Customer choose a pricing plan -> We create a subscription for them -> Show them PaymentElement using the PaymentSecret from the subscription
autumn edge
Yep thanks for clarifying
So AddressElement should validate up front if it is not a legitimate address
However, I would think it is still possible that tax location could fail even if the address is legitimate.
Though that shouldn't really happen.
Okay actually hold on getting some clarification as well
analog hedge
Got it, just so you know this is our current plan:
After the user confirms their address, we make a call to create/update their address in Stripe. After updating their address, we check the "automatic_tax" field for their customer obj in Stripe. If it shows "unrecognized_location" (which you're saying will be rare), then we return an error saying that their address is invalid. This error will prevent them from moving to the "choose pricing plan" screen, instead asking them to change the address they submitted
So I'm just trying to make sure that it makes sense to do it this way
autumn edge
Okay so let's back up a sec -- I think I led you a bit astray with talking about validation. AddressElement is going to attempt to auto complete an address with a legitimate address, and it will validate that the format of the address is legitimate. However, it will not actually validate that it is a real address. So, the customer could take the auto-completed address and change it and then it could become invalid but still be in the correct format.
So all in all, yes -- your proposed plan is correct. You should be checking on what is returned with the Customer when you set the Customer address and you should return an error and not proceed if it is unrecognized_location
analog hedge
kk, thanks! And just to double check, we will need to provide our own Google Maps API key for autocomplete, correct? Because we have a multi-step flow.
autumn edge
That's correct