#jo_best-practices
south boltBOT
đ 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/1355175494936428765
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
crimson ingot
Is there any event I did not find yet that returns the entered zip code when using the https://docs.stripe.com/payments/payment-element payment element and typing into the zip code field?
strange plaza
Hi, you can attain the billing details from wallet payment methods under PaymentIntents and billing details. We attain that information from GooglePay/ ApplePay
As for the zip validaiton, we validate the length/format based on the country selected (so if you choose US we want 5 digits).
After that, all we do is give it to the bank and then the bank can tell us whether it's valid or not. We document this here: https://docs.stripe.com/disputes/prevention/verification#avs-check
As the document suggests, you can use Radar to block these if you'd like.
crimson ingot
Is this reliable? As in 100% reliable or do we need some sort of fallback if the zip code can't be retrieveved through the wallet? Maybe the user does not have it set, or blocked due to privacy...
Are there any best practice fallback methods or is it normal to just rely on the wallet response?
I did a test with an American credit card using Google Pay and under transactions on the stripe dashboard I did not see the zip code that I thought would show up. So I did not use the card element but rather the Google Pay one. Do I need to enable this somewhere that this data is always collected? What is the best practice there?
strange plaza
Hmm, I have not seen an instance when it was blocked. Can you share an example please?
It is the current behavior that merchants rely on the wallet response? However, if you'd want to collect this data, you can on your UI.
Alternatively, you can use Address Elements: https://docs.stripe.com/elements/address-element as well
Can you share that example where you did not see tha data?
crimson ingot
We would prefer to keep it as lean as possible and not show the entire address element. We really only need the zip code. With it being "blocked" was just an assumption/question. If this is the best practice method then we will use that one. Thank you
strange plaza
Sounds good
crimson ingot
And for the card element the regular best practice way to grab zip code is just enabling zip code with mode auto. Then using the default validation and if we would like to have even higher security then using radar?
Is there any way to grab the entered zip code from that element? Any event? Where we could use that information and validate it further if needed?
I am talking about this input field.
Is it common that merchants would accept such a payment even with an invalid zip code that passed validation? Just want to follow best practices here.
One more question: Does it need to be enabled somewhere for all payment methods that address (zip code) will be collected from the customer when using anything else than card payment or is that automatic?
strange plaza
We would pass that information to the issuing bank. They ultimately make the decision whether the zip is valid or not. Even if you 'validate' that on your end, it's possible that the issuing bank still declines it as the zip is different than what is on their card's billing data. When using Radar, you can make the decition to be more rigirous and block these payment methods if the issuing banks says that the zip does not match for instance.
What is your underlying issue?
Yes, we send Elements events and we document them here: https://docs.stripe.com/js/element/events
crimson ingot
My issue is that I was able to create a free trial subscription with an invalid zip code of 11111. IMO this should not be possible.
strange plaza
Then you'd want to use Radar to block them.
crimson ingot
Okay I will take that back to discussion internally. I am just curious how most merchants are handling this case.