#sai_rez - setupintent billing details
fallen wolf
You can make the confirmSetup call without billing details like address and postal code. Are you currently getting an error when not including them?
fickle glade
Yea so I'm rendering the component with these props, as I don't want to show the country and postcode fields, however I get errors when making the confirmSetup call
<PaymentElement onChange={(e) => setIsFieldsComplete(e.complete)} options={{ fields: { billingDetails: { address: { country: 'never', postalCode: 'never', } } }} } />
I wanted to know if it must be included in the confirm call if I set it to never on the options?
fallen wolf
Do you have a request ID (req_123) from a time that you tried this? Certain payment methods may require those fields
That should have been my first answer, I was thinking in too general of terms here
fickle glade
This is the message I get
fallen wolf
Do you have the ID of the setup intent that you got that error on?
fickle glade
Unfortunately no, we don't send any requests to stripe if we have errors from the frontend
fallen wolf
Right but your server is creating a SetupIntent here and sending the secret off client-side right?
What payment method are you trying to set up here? That should be enough for me to test this
fickle glade
So currently I am trying to integrate PaymentElements and migrate from our previous cardElements integration. I'm testing things out atm
I think this is a request ID for the setup intent
req_g4wliZv5wXB8Qz
fallen wolf
Perfect thank you
So yes, it looks like you will need to pass in data for those fields if you disable them for card payments.
Are you trying to not collect/provide those completely or is this something else?
Which countries would trigger the optional state and postal code fields when using PaymentElements?
https://stripe.com/docs/payments/quickstart
I think we can discuss this question in this thread too.
Do you have a country that you know triggers the state requirement? I honestly did not realize that that was required sometimes but am looking in to it
fickle glade
Ah fair enough, so the issue is that with our previous integration, we had a custom country selector dropdown and we require that data(country/state) to use elsewhere on our platform and backend, however with the stripe country selector, the value isn't exposed for me to get so ideally I would like to omit it from paymentElements and carry on using our custom dropdown. However for countries like UK, we never collected postcodes which would now be required to pass into confirmSetup
I can integrate postcode field for the UK in our custom dropdown. This is what lead me to my second question, I would like to know if there is a list of countries which trigger postcal code field or is it only the UK
If I switch my VPN to america, the zip field appears, for UK it's postcal code
glossy jolt
Hi 👋 jumping in as my teammate needs to step away. Am I right in understanding that part of your flow requires you to collect a customer's zip/postal code?
fickle glade
Yes, I would like to know which countries trigger the second field as shown from the picture
glossy jolt
I don't have a list of the countries that cause that field to be presented, and since that list of available countries could expand I don't think hardcoding that list would be a good approach.
If you need the zip/postal code, then I would recommend adding a form to your flow to collect it and instead configure the Payment Element to never ask for it.
https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-fields-billingDetails-address-postalCode
fickle glade
Yea haha that's exactly what I'm trying to do atm, but I need to know which countries to present the optional field so I can collect it and pass it to confirmSetup call
glossy jolt
Sorry, I think I might be confused. Do you always need to collect the zip/postal for your flow?
fickle glade
Before we didn't but as we require it now for the confirmSetup call, I need to collect it using our custom country dropdown
glossy jolt
So if you need to always collect it, then why does that collection need to be country dependent?
fickle glade
I only need to collect where appropriate, it'll have to be country dependent as different countries require different information, US requires Zip code, UK requires postal code, Canada requires postal code etc..
I can go through the list in the link above manually to find out, was hoping there was a list to save time, it's fine if there isn't
glossy jolt
If you want to rely on our logic for when to collect zip/postal code, why not let the Payment Element handle that collection?
fickle glade
Because the values aren't exposed and we need to use the information in other areas of the platform and backend, it's where my whole issue started haha
glossy jolt
Please let me know if it seems like I'm overlooking a detail, but to me it seems like there are two paths:
- You let the Payment Element collect the customer's zip/postal and retrieve that information from the related Charge or Payment Method objects.
or
- You design your flow to always collect zip/postal, and then always provide the collected value to us when confirming the call (regardless of country).
fickle glade
The second option seems to most feasible, only issue is that what if for some countries, postal/zip code isn't applicable, it might confuse users
Have to jump off now, I'll have to think deeper through this to figure it out, thanks for our help and being patient!
glossy jolt
Happy to do so!