Is there a way to stop the zip code field showing from the CardSection component about react-stripe-elements

[atty-stripe]

@ultran the card Element collects postal code based on the country where the credit card is from. So if you're using a US-based Stripe test card (such as 4242424242424242), you'll see it collect ZIP code. If you try one of our Australian cards (such as 4000000360000006), it won't.

You can see the rest of our test cards here: https://stripe.com/docs/testing#cards.

Does that help?

[jenan-stripe]

CardElement accepts all the options as defined in Stripe.js reference, so you can set hidePostalCode=true. That said, we still recommend collecting postal code in the UK, and CardElement is smart -- it will only collect zip/postal for credit cards from US, UK, and CA. Hope that helps!

[AnonymousArthur]

Thank you, but it's collecting postal code in AU, and using validation rules of US, which is very annoying.

[edschofield]

@atty-stripe @jenan-stripe : The "smart" zip code validation makes the incorrect assumption that every US card is associated with a 5-digit US zip code. In the case where a US credit card has a registered billing address and postcode in another country (e.g. for an Australian subsidiary of a US company), this causes Stripe to require a 5-digit US zip code, when none exists. This can lead to valid payment attempts being rejected.

Is there a workaround for this other than always setting hidePostalCode=true?

[jenan-stripe]

@rjbrown I'm not sure I fully understand your question, but:

1. You can read the postalCode on change events. See here.
2. If you use hidePostalCode: true and you collect it elsewhere, you can pass the postal code when creating a token or source.

[rjbrown]

I agree that it is useful to collect. But have a question on how to access it from the frontend because its an iframe. I am integrating this into an app, on the UI/UX on the orderform we have our own billing and shipping fields. So if we use the CardElement with this option turned on then the user has to enter their billing zip twice, once in the orderform fields and then again in the CardElement field. If we remove it from our form, and use the CardElement ability to target an element we can visually put it back in the same location as our zip field but now we break features like, shipping same as billing options that populate the shipping fields since we no longer have access to read the user data inside of the CardElement iframe. Want want to use the CardElement zip so US AVS works, but is there a better way to do this or read what the user types in so we can copy it to the shipping zip?

[rjbrown]

Thanks Jenan, just overlooked that. Exactly what I needed. TY.

[twobitfool]

Note: If you are using React, then the hidePostalCode needs to be passed into the options property, like so...

<CardElement options={{hidePostalCode: true}}/>

[atty-stripe]

@ripexz the Amex test card has a US BIN, and is thus intended to be represented as a US card. The Card Element only allowing numeric characters is expected here.

To be clear, the behavior today is the Card Element does a BIN lookup against the entered card number, and based on the country, places the appropriate restrictions and translations on the postal code field. We are exploring ways to loosen these restrictions without compromising conversion and user experience.

[BojidarStanchev]

Can you just introduce a variable that completely shuts off this ZIP code feature, so we can use Stripe properly while you "actively work on the problem" for a few fucking more months??? Most people who pay something online have already completed an address/billing form. I don't need part of my payments blocked because you decided that you need to collect ZIP codes for some reason.

[BojidarStanchev]

Postal code is visible for US cards even with this property set to "true". I had already tried that.

[NateWithArsenal]

I am still having this issue as well. Specifically, Canadian customers that have alpha characters and can't enter them.

Hiding the Postal Code also creates issues with Billing vs. Shipping zip codes. We prefer the simplicity of having one address input and reducing checkout friction, so if we hide the credit card zip code we create additional problems. Why can't the zip input simply be set to a max # of digits and allow alpha and numeric characters?

[TimvdLippe]

I just tried to order online, only to discover it wasn't accepting my credit card. Turns out that I was using my American credit card (intended!) but wanted to enter my UK zip code (also intended!). Now I am a web developer so I know what to look for (which is how I found this thread). However, for a non-developer customer this was a very confusing experience. Whenever the autocomplete would finish, it would remove all non-numeric characters! Only after I entered my UK credit card and UK postcode, it allowed me to finish the transaction.

[asegestam]

I am also having this issue. A Canadian customer can't enter their ZIP because theirs is 6 character alpha-numeric and once you put in a Canadian cc number you are limited to 5 digits numeric.

I also replicated the issue with this randomly generated cc info

Issuing network:
Visa
Card number:
4801769871971639
Name:
Anna Oliver
Adress:
681-5094 Luctus Avenue 58
Country:
Canada
CVV:
656
Exp:
07/2025

hidePostalCode doesn't have any effect on this

I also have this issue with several CA customers, the card element asks for American ZIP and not CA Postal code. Is there any way around this?

[sgdoerfler]

"... a customer not submitting their card information because of postal code validation, which is an extremely low occurrence according to our metrics."

What metrics could you possibly have on this? Suppose a customer types in his US card number, but can't submit his payment because the Zip field won't allow the foreign postal code that matches his billing address. So he goes to a competitor to buy the product.

To Stripe it would look the same as any other abandoned transaction. You'd have no way of knowing that he gave up because of Stripe's longstanding design flaw, or of counting how many times per month Stripe's design flaw cost your merchants a sale.

Likewise, how could Stripe possibly know how many additional declined transactions would result if you changed the current client-side checking of zip codes for US cards? Again, it seems quite implausible that Stripe has any way to measure this hypothetical value, so claiming that you've compared two metrics you cannot actually measure is hard to accept.

Why doesn't Stripe simply provide a way to collect the zip/postal code as usual, but disable the misguided validation? Then you would have some actual metrics, an actual count of declines based on people incorrectly typing letters when asked for their zip codes. My guess is that if you really measured this, you'd discover that hardly anyone ever does that.

And if Stripe's JavaScript displayed a suitable message when it noticed the customer was typing alpha characters in the zip code field ("Please enter a 5-digit Zip code unless your card's billing address is outside the US") that metric would drop to pretty much zero.

[EwanValentine]

Ahaaa perfect, thank you!

[atty-stripe]

@edschofield this is a known problem unfortunately, and something we're actively working on addressing! One reason it happens is because we show postal code based on a dataset mapping card numbers to countries, but the dataset is sometimes wrong. And in some cases even if the data is correct, as you point out, the actual address might be a different country.

Could you share the first 6 digits of the card you're talking about if you don't mind? You can also email me directly at [email protected].

[rogerrogers]

I'm getting the same problem here. Maybe the postcode should be a required field, but lessen the format validation rules?

We've lost transactions due to a US card holder having a Canadian postcode.

[atty-stripe]

@rogerrogers can you share the first 6 digits of the card number please? Feel free to post here or email me at [email protected]. The first 6 digits are safe to share publicly.

[rogerrogers]

Hi @atty-stripe, in fact, you can use any of the US cards in the stripe test cards, e.g. 4242424242424242 and then try entering a Canadian postcode, which is made of letters, numbers and a space (similar to UK postcodes).

That said, I may be posting this in the wrong forum. I'm using the Stripe Elements and having this problem, not the react library.

[jez]

@rogerrogers 4242 is specifically a US test card. We have a number of international test numbers here:

https://stripe.com/docs/testing#international-cards

when you try with the Canadian test card, do you see the same issue?

4012888888881881

[rogerrogers]

@jez The specific case we're trying to resolve is where the card is a US/USD card, but the postcode is Canadian. Because the card is US the Elements form will only allow an all numeric US zipcode, even though the card's billing address is linked to a Canadian postcode.

[atty-stripe]

@rogerrogers I understand! Elements specifically shows US zipcode entry for cards we think map to the US. If you can share the specific BIN (first 6 digits) of the card that's mismatched, I'd love to dig further. Sometimes it's a US card that uniquely has a Canadian billing address, but other times it's actually a CA card that was mismatched to the US.

[rogerrogers]

Hi @atty-stripe. I don't actually have the card number, so I can't tell you the first digits. Sorry about that. I was simply told of the situation by a donor (the scenario is a donation form) who couldn't donate because the US card had a Canadian billing address. We ended up having to process the donation via a PayPal form, which was a bit frustrating given we just switched from PayPal to Stripe! :/

[atty-stripe]

@rogerrogers got it! I'm sorry that experience was frustrating. We're actively working on addressing this issue and will let you know once we have a fix.

[rogerrogers]

Thanks @atty-stripe, look forward to the fix and thanks for the quick response!

[rogerrogers]

Hi, adding to this thread, I've now got a complaint that an AMEX card in Australia isn't accepted because Stripe won't accept a 4 digit Australian postcode. This seems like a pretty major issue. Again, I'm not sure if I'm posting this in the correct thread. We're using the JS elements card form provided by Stripe.

[atty-stripe]

@rogerrogers rest assured, we're working on it and will have a fix out soon. Our AMEX data set is being upgraded to fix it quickly, and we're also looking at more long term fixes. Will keep you posted!

(react-stripe-elements basically wraps Stripe.js and Elements. In the future, the best place to get support is via email, chat, phone, or IRC. See more here: https://support.stripe.com/.)

[rogerrogers]

@atty-stripe Thanks for clarifying, glad I'm in the right place. I assume this thread will be updated when the fix has been committed? Cheers!

[atty-stripe]

Yep, we'll post here!

[cbruhns]

Yep, also finding that a customer cannot complete checkout because they have a US based Credit Card which has a Canadian billing address. I understand that stripes masked zip formatting is trying to be helpful, but in this case it is not and it is costing sales. Looking forward to a resolution.

[davidpatters0n]

Is there any update on this ?

[atty-stripe]

@davidpatters0n @cbruhns is there a specific BIN (first 6 digits of card number) that you're seeing mismatched?

[ripexz]

@atty-stripe Seeing same issue here as @cbruhns even using the AMEX test card - 3782 822463 10005 - it only allows numeric characters so Canadian post codes are not allowed (using stripe.js + elements directly, without react)

[davidpatters0n]

Hi @atty-stripe - Here's an example of a live amex bin card: Amex: 379517

[atty-stripe]

@davidpatters0n that BIN points to the US in our database. Are your customers saying that their card matches to a different country?

[djw27]

@atty-stripe just to add that we're experiencing a similar issue with a customer in Ireland who has a US Mastercard and hence they're being asked for a US ZIP code which they don't have. They claim the card is decades old so not sure if this is some sort of historic issuing which didn't require a US ZIP to be associated to the card? I can email the BIN?

[atty-stripe]

Hi @djw27, yes please email with the card BIN. It's possible the card is mismatched, or it is a US card, but the customer lives in Ireland and does not have a US billing address. For now you can ask them to pass in a fake US ZIP (such as "12345") as well, assuming your Radar rules don't decline the card.

[jingtra]

Did you guys fixed the AMEX issue?

[rcy]

@atty-stripe I still have this problem, I have a US card with a Canadian billing address, and a fake US ZIP (12345) doesn't work.

[fmvilas]

@atty-stripe are you working on a solution for this? It's blocking donations on opencollective.com and you know how crucial a single donation can be for open source projects :/

[atty-stripe]

@fmvilas can you share the BIN (first 6 digits) for the card number that's having an issue? We do not yet have a long term solution here. You can always choose to not collect postal code info (although we don't recommend it) by passing in hidePostalCode: false, or can build your own postal code input as well.

[timhowell01]

Any update on this? We have users with US based cards but Canadian mailing addresses who are unable to enter the Canadian postal code because of the validation rules Stripe uses.

[atty-stripe]

We're continuing to think about this, but no update to share at the moment.

Separately, I've recently switched teams and no longer work on Elements, so please reach out directly to [email protected] with any BIN-specific questions.

[mfhholmes]

I have an Australian credit card but live in Germany, and I can't pay for anything online at all because everyone uses Stripe and this stupid validation rule exists. Happy to provide BIN numbers and "postal code"

[atty-stripe]

@BojidarStanchev you can use the hidePostalCode option: https://stripe.com/docs/js/elements_object/create_element?type=card#elements_create-options-hidePostalCode.

[okaris]

I am also having this issue. A Canadian customer can't enter their ZIP because theirs is 6 character alpha-numeric and once you put in a Canadian cc number you are limited to 5 digits numeric.

I also replicated the issue with this randomly generated cc info

Issuing network:
Visa
Card number:
4801769871971639
Name:
Anna Oliver
Adress:
681-5094 Luctus Avenue 58
Country:
Canada
CVV:
656
Exp:
07/2025

hidePostalCode doesn't have any effect on this

[zlatianiliev]

I can also confirm that using options={{hidePostalCode: true}} doesn't help with allowing MasterCards that have letters for their zip codes to be able to pay. Can you please provide an update if and when are you planning to work on this?

[blackarcanis]

I confirm there's often an issue with CA customers. Having the American ZIP asked and not the CA Postal code... Any updates ?

[hofman-stripe]

Let me try to recap: there are really 2 cases where the postal/zip code prompted by the combined card element might not match the card holder's expectations:

• Stripe's BIN -> Country mapping is not up to date for the card
• The card holder holds a card from one country with a billing address in another country

Regarding the first case, we've improved our country mapping data, and another update will be going out soon to Stripe.js Elements. We're also working on a solution by dynamically looking up the country of the card, avoiding cases where new card ranges are mismatched in Stripe.js. However all this still relies on a correct data set from the card networks. There could still be gaps and errors in that data, and if you get a user report of a card which is misclassified, please let us know, and we'll work with the card networks for them to update that data.

On the second case, the postal code will in most cases be ignored by the networks/banks during verification. A lot of international card holders are aware of this limitation with their card, and will enter a random value (e.g. 00000). If you are concerned about this degraded user experience, there are 2 solutions:

• use the split card Elements instead of the combined card Element
• use the hidePostalCode=true option on the combined card Element

With either option, you can then collect billing information yourself and include that data when creating a token, source or payment method.

I have modified the example fiddle to show how this would work for creating a token with the combined card element: https://jsfiddle.net/n23g0mzh/1/

To answer specific questions:
@mfhholmes and @TimvdLippe: have you experienced any cases where entering a random postal code matching the format of your card's country resulted in an unauthorized transaction?

@BojidarStanchev: the example above shows that the postal code is disabled with hidePostalCode. Could you share a reproduction where the ZIP code field is still shown?

@NateWithArsenal: The billing address and shipping address may be different. The postal code for the payment method may be verified by the card's bank with the billing address on file, so you usually want the billing details to be collected from the user. Using the shipping information as billing details raises the chances that the card may not authorize.

@twobitfool and @zlatianiliev: The options prop is for our new react-stripe-js wrapper library . For react-stripe-elements you can use the hidePostalCode prop directly as shown in the fiddle.

@okaris: that random card number is in a US BIN, so prompting for a ZIP is valid behavior. Could you share the first 6 digits of that canadian card number so we can verify if that BIN is correctly mapped in our data?

@asegestam and @blackarcanis: are those cards US or CA cards? Could you share the first 6 digits of the card by any chance?

[asegestam]

@hofman-stripe I can confirm that atleast the one customer we had did use a US card with a CA billing address, so wasn't a issue with the country mapping there.

Thanks for the clarification and the different options to solve the issue. We collect billing details beforehand so I will try to use the hide postal code option and include that data in the payment method!

[mfhholmes]

@hofman-stripe Thanks for the feedback. But, are you seriously suggesting that the solution for this problem is to tell our customers to lie about their address and "invent" a postal code instead of using their actual postal code?

The banks know where their customers live. They will validate the postal code for the transaction against the record they have for the customer, surely? Asking our customers to "invent" a postal code that matches the formatting rules you're imposing is lowering security, not improving it.

The problem here is that your code is enforcing a postal code format for the customer's address incorrectly based on the country their card comes from, because you're incorrectly assuming that everyone lives in the same country that they have a bank account/credit card for. The solution is clearly to remove the validation of the postal code field (or provide a switch to turn it off). What's so hard about that?

[hofman-stripe]

@mfhholmes, could you clarify why the hidePostalCode option or using split card Elements doesn't satisfy your needs if you want to allow your customers to input a postal code not tied to the issuing country of the card?

The vast majority of customers have a card from the country where they live, and client side validation helps catch mistakes that would ultimately result in declined transaction. This is a much more prevalent case than a customer not submitting their card information because of postal code validation, which is an extremely low occurrence according to our metrics.

We are always exploring ways to improve the user experience, and welcome any ideas that would solve use cases that the hidePostalCode option doesn't.

[okaris]

Hello @hofman-stripe,

As you can see above where I wrote in May and @blackarcanis confirmed in August, hidePostalCode option is not realy working for our cases. I believe it might be a frontend bug. We would be happy if you can check that out. Sadly I don't even remember now all the steps I have tried before writing here.

Best

[mfhholmes]

@hofman-stripe As a developer using your product, I can circumvent your broken-by-default design using the methods you suggest, yes.
But I'm also a member of this "less prevalent" group, and the fact that the default way your product works is broken for me is a major pain in the neck. The fact that for the vast majority of cases it isn't broken doesn't help me. Please fix it so all the sites using it are fixed. Because a process that works in 99% of cases is still broken.

[blackarcanis]

@hofman-stripe Here you go with the first 6 digits of the card "451992" 👍

[hofman-stripe]

@blackarcanis I've verified that the BIN is correctly associated to Canada, and that the Card Element asks for a Postal Code. Could you clarify under which circumstances your customers were asked for a Zip?