tianyouli

[mint glade]

Hi there

If the confirmation is happening client-side then we will fall back to the IP address.

However if you were creating a Subscription or something here, then it would have an unrecognized location

What integration are you using exactly?

Overall though, collecting an address is highly recommended

Ah actually ignore the client-side confirmation, that won't apply here

So yeah typically we will fall back to the IP assuming we have that info, but it is possible it wasn't collected and it is also possible that it isn't completely accurate (as we call out in the guide) so yeah not recommended to rely on that

[weary root]

hi, our use case is subscription. we will try to pass the billing details as much/accurate as possible on payment methods but do not want to run into invoice finalization failure issues

based on the details on the link, if we use Customer's addresses, then its very likely to run into a requires_location_inputs error even if there're typos on the addresses, so it seems using PM's billing details could cause less friction, even if sometimes it would fall back to ip-address geolocation

[mint glade]

Well we will fall back between each of the items in the list

So I would recommend collecting Customer Address and allowing a fallback to PM billing detail or even IP if necesssary

[weary root]

are you saying as long as we have the tax.ip_address collected on the Customer object, then if there're issues with Customers addresses or PM's address it will not throw requires_location_inputs error but just fall back to use the IP's geolocation? https://stripe.com/docs/api/customers/object#customer_object-tax-ip_address

[mint glade]

Yes it falls back down the chain in the doc to try to use any of those options

[weary root]

ok thanks

IP seems a safe-enough fallback option to ensure no error of invoice finalization