I’m finding that the autofill credit card feature doesn’t work as desired the majority of times.
It seems to wig out when sites ask for credit card expiration dates in MM/YY format instead of MM/YYYY format. Sometimes it fills out a credit card’s expiration as 01/20 and sometimes I’ve even seen it fill it out as 20/23. When it asks in MM/YYYY format, I’ve never seen it not work as expected.
Is there a workaround to get this to work correctly?
PR #3768 apparently only addresses the problem when it is caused by the presence of Cyrillic characters in the expiration date placeholder.
@southerndoc Can you provide some examples of where the MM/YY format is not correctly filled? Perhaps if these can be diagnosed, someone will be able to do another PR to fix the issue on additional sites.
I DM’d you a website. Unfortunately the URL gives away my location.
The expiration date for my card is 03/2027. It entered the expiration as 20/27. I have a screen shot but I do not see where I have an option to post it.
I have a similar issue with the postal code/zip code field in the credit card file never auto filling. I may try to create a custom field based on a few fieldIDs to see if that solves the problem.
Based on testing, it seems like the auto-filling of credit card expiration dates requires the site to use a parameter named placeholder in the HTML code for the input field. This would have a value like placeholder = "MM/YY" to signal the expected format. If this is not present, then Bitwarden cannot determine how to properly format the expiration date.
So I believe the issue is not specifically related to the MM/YY date format (for example, this format is autofilled correctly on DoorDash.com and other sites), it is just a problem when the credit card form does not include the placeholder template that is required for the auto-filling to work correctly.
It’s not that a few sites has problems. I’d say 9/10 sites fills our credit card information wrong, and it’s not just Bitwarden that has issues, not even the built-in auto fill in iOS works.
It’s often the date, but quite often it’s also the security code. Occationally even the card number itself.
First I thought it was a language issue (since I purchase things in Swedish sometimes), but it’s not. It doesn’t even work with standard pages such as Paypal. And it’s not system/browser specific or tied to a certain card type. It’s simply just a globally broken feature that needs a complete overhaul.
This is an issue caused by how the payment form has been coded by the web developer for the site you are visiting. For example, many payment forms do not label or activate the expiration date input fields until after you have manually placed the cursor into the card number field and started typing.
The only solution would be to build a very large database of heuristics to try on each payment form (rules for identifying expiration date fields and methods for circumventing website controls that prevent those fields from being filled), but this would invariably cause the autofilling to be delayed, and likely also cause false positives (filling of expiration date data into fields that are not meant for that purpose).
If you have a few payment forms that you use frequently, then you may be able to use custom fields to solve the autofilling problems, but this is not a scalable approach (for the same reason that having Bitwarden build a list of custom rules would not be scalable).
I’ve found that a work-around that solves autofill problems on many payment forms is to autofill once, then click into the card number field (or for stubborn cases, click into all input fields), and then autofill again. This process can be completed fairly quickly using the new keyboard shortcut for autofilling card data — which must be defined by the user (I use Ctrl+$)…
For me, bitwarden’s credit card autofill does not work on a LARGE MAJORITY of web sites … but my browser’s own credit card autofill does work. So I really doubt this is purely a problem with “how the payment form has been coded by the web developer of the site”, as a general explanation for this problem. Maybe it’s an issue with a few sites here or there, when when bitwarden fails at this for nearly every site, while Firefox and Chrome do fine on most of them, it’s obvious that bitwarden is missing things in these forms that browsers are able to find, and I don’t think blaming the web sites is right.
Just one question, maybe im dumb but why not building a little checkmark function into the client, where you can choose if your creditcard has a long or short expiry date and then everyone could just make two credit card entries, one in long one in short form. If you then visit a site with credit card field you can just select the one with the correct form from the dropdown field.
That could be implemented until the root cause is found. I just don’t understand why such issues roam the forum for over two years unsolved…
Interesting theory, though the site I was using today DOES have said placeholder “Expiry MM/YY” and yet Bitwarden still doesn’t fill that field properly?
The issue I had mentioned two years ago is still there, I believe, but there seems to be a new bug present in the recent browser extension versions which is somehow scrambling the date values — thus, the problem you are experiencing is unrelated to the constraint I had described.
By the way, it would help if you shared the actual expiration date of the card you were trying to autofill. My guess is that is somewhere in the range 01/2026–09/2026, correct?
08/2026 … thanks … and it does seem to be a new bug given the increase in frequency (I had already added a +1 to that post!).Appreciate you taking the time to look into it.
If it was the earlier issue, you would have seen the expiration date entered as 26/08 (for a field that was expecting MM/YY). With the new bug, you are seeing a complete scrambling of the date information, resulting in 02/60.
What seems to be happening is that for a month value {m1,m2} and a year value {y1,y2,y3,y4}, an MM/YY field is being autofilled with “{y2,y3}/{y4,m1}”. It doesn’t seem that such a reproducible bug should be that hard to track down (but I have not attempted to examine the relevant parts of the code base).