#mkoenke-paymentelement-postalcode
quartz badge
thick gyro
mkoenke-paymentelement-postalcode
@elfin nimbus for the postal code it's based on the country dropdown in PaymentElement. So if you choose USA we show it, if you choose Germany we don't
The old Elements used to rely on a card's number to guess the country but it was a real issue for people with a card from Canada living in the US (the format was different). That's why PaymentElement has the country dropdown
How is the customer’s locale and location determined?
based on their browser settings and IP address
Does the currency of the payment intent created have an effect, due to the fact that we are passing the client_secret to the Elements instance?
No I don't thinkcurrencymatters today (other than it already filters out supported payment methods based on that information on PaymentIntent creation)
elfin nimbus
ok very interesting, so the payment element will detect a users ip address and browser settings, and dynamically render country specific methods of payment. But if we create the payment intent with BRL, for example, any methods of payment that do not accept BRL will be filtered out?
we were previously using the card element, and once the credit card information was entered, we would update the currency in which we decided to charge the customer. so were trying to figure out if this is still possible with the payment element, and how the payment element will change if we update the payment intent's currency
thick gyro
But if we create the payment intent with BRL, for example, any methods of payment that do not accept BRL will be filtered out
yes that happens on PaymentIntent creation already
we were previously using the card element, and once the credit card information was entered, we would update the currency in which we decided to charge the customer. so were trying to figure out if this is still possible with the payment element, and how the payment element will change if we update the payment intent's currency
no that is impossible with PaymentElement, you should decide the currency upfront
elfin nimbus
what if we were to use PaymentIntent.update on the backend and then refresh the payment element on the frontend (https://stripe.com/docs/js/elements_object/fetch_updates) ?
thick gyro
yeah that would work, but you can't do that after card details collection
elfin nimbus
i see, if we refresh, I am assuming we would lose any information the user already entered?
thick gyro
yes
The thing you need to understand is that your flow only makes sense for card payments
elfin nimbus
gotcha, makes sense
thick gyro
like I get entering a card number and then trying to detect their currency from the card's country before confirming
but with iDEAL or Klarna, you get redirected before the payment, so there's no "breakpoint" in the middle
We do have a beta though https://stripe.com/docs/payments/accept-a-payment-deferred that matches what you were after and might be a good fit
thick gyro
of course! But if it were me I still wouldn't use that beta. I've worked with hundreds of developers integrating PaymentElement. Many devs who migrate from CardElement they want to keep their existing flow at all cost, but they don't realize the benefits of switching off of it
elfin nimbus
I hear you, what stand out to you the most about the benefits of switching?
thick gyro
The code in my experience becomes a lot simpler. You create/configure a PaymentIntent for payment, client-side you use PaymentElement to collect payment method details, and then they do and the payment completes automatically. You don't need a roundtrip to your server, you don't need extra validation, and it makes adding new payment methods a lot easier over time
elfin nimbus
makes sense, in that case we would not be able to allow updates to the purchase during the time of checkout such as promo codes, or selecting a different frequency (like an annual or monthly subscription with different prices for the frequency). We would need to have all of that set before rendering the payment element, correct?
thick gyro
lol of course you also do recurring billing on top of all of this 😅
elfin nimbus
absolutely, of course lol
thick gyro
Sorry, this has been a theme lately on Discord
elfin nimbus
hehe
thick gyro
So you mostly only ever do card payments I assume? You collect card details, then later you offer the promotion code box and the different payment options?
elfin nimbus
that is the only thing we currently accept
yes exactly
except the only payment option is credit card right now
thick gyro
So yeah I think mostly the problem you have is you have one payment flow and you are trying to throw the PaymentElement in the middle of it. And sadly, you can't. You mostly have to really rethink your entire payment flow/checkout process to fit around the value of PaymentElement
Like offering the payment options and promotion code before collecting payment method details
elfin nimbus
yep, I see what you mean.
thick gyro
even with the beta I shared, you'd end up having to "re-do the payment" if you changed the currency after the confirmation (except for card) so I do recommend taking a hard look at the flow and considering a different process first
elfin nimbus
when you say 'after the confirmation' do you mean after the confirmPayment call to stripe?
thick gyro
not exactly, I was talking about the beta which has a different flow, but yes basically you don't want to "collect payment method details and later take a payment" because many payment methods require a redirect in the middle which map to a certain amount/currency
elfin nimbus
ok, I am going to read up and talk with the team and see how much we are willing to reconstruct lol, it would be nice to set ourselves up to make this easier in the future
thick gyro
yeah you can also ask access to the beta
it's kind of being released publicly soon so it won't be a beta for long
thick gyro
ah yeah someone on your team must have asked for access then
elfin nimbus
ok great, thanks so much! Always helpful!