inconsistencies filling credit card info

I'm using Firefox 65.0.2 (64-bit) with the extension and desktop app. (I didn't like 1Password X.)

Using 1P to fill in credit/debit card info seems to be a hit-or-miss enterprise, most of the time.

When I create a credit card entry, 1P provides me with a field called "expiry date", but populating this field doesn't necessarily mean 1P can use this information when necessary. Many websites call this field "expiration date". In fact, I don't remember EVER seeing the term "expiry date" on ANY website where I've been asked for payment info, but I digress. While you and I know that these two terms mean the same thing, 1P apparently does not, because it always leaves a field with the name "expiration date" blank. So I created a custom field in each of my card entries, titled it "expiration date", duplicated the information from "expiry date", and moved "expiration date" to be immediately below "expiry date" so I could tell for sure it is there any time I look at the entry.

Now, that may sound like a bunch of work, especially when repeated across several entries, but there's a good reason for that. It's because it is. So why did I go to the trouble of doing all that work? Because it works. Now, every time I visit a site that wants my card's "expiration date", 1P can fill it, and I can be happy.

That is, I can be happy until I encounter a website that doesn't have a field with either name. A fair number of websites have a category called "expiration date", which contains two fields--one for the month of the expiration date, and one for the year.

Some of you are already ahead of me. I can tell.

There's no consistent way that websites ask for these two data points. Some want the "month", while others ask for "MM". Some sites ask for the "year", while others ask for "YY" or even "YYYY". And even among sites that ask for the "expiration date", some use a two-digit year and others use a four-digit year.

But wait! There's more!

What's the first data point always, er, usually, um, sometimes requested for a card payment? That's right, it's the number, which 1P calls, appropriately enough, "number". 1P is so cool that when you enter the number as an unbroken string of 16 or 15 digits, 1P will group them as they are grouped on the card. How sweet!

At least it's sweet until you come across a site that isn't interested in your "number". It wants your "card number". Still another site wants your "credit card number". And today, I even found a site that asked for my first and last names in separate fields!

Therefore, a credit card entry in my copy of 1P now contains ALL of the following fields. Bold represents a 1P field name that I duplicated. Italics represent a field name that duplicates the closest bold 1P field name above it, which I added because 1P refused to populate the relevant field on the form until I did.

  • cardholder name
  • first name
  • last name
  • type
  • number
  • card number
  • credit card number
  • verification number
  • security code
  • valid from
  • expiry date
  • expiration date
  • MM
  • YY
  • YYYY

Now, the most intelligent websites don't ask for "type" because they can figure it out from the card number, but some still do, so it's good to have it there. And so far, I've never seen a site that asked for the "valid from" date, but that doesn't mean they're not out there, and it's probably convenient to have that information available, anyway, so I'm good with that.

Oh, but just you wait. It gets better!

1P's CC entry also has an entire section called "Contact Information". The first field in this section is "issuing bank". Immediately below this field are fields for three different types of phone numbers. Now, it's easy for the humans to assume that all three of these phone numbers correspond to the issuing bank named immediately above them. It may even be easy for the humans to remember that association upon later seeing the phone number fields, even without seeing the bank's name above them.

Easy for humans. For 1P, not so much. A growing number of websites now want the customer's phone number as part of the payment information. What does 1P drop in that field? You guessed it--the bank's number, not mine. My phone number isn't even part of a CC entry by default. So far, I haven't been brave enough to tempt Fate by adding it.

As if all the above were not bad enough, I found a website today that managed to confuse 1P with a date field, despite all the redundant data I added to mine. I was making travel arrangements on Orbitz. Understandably, Orbitz asks for my date of birth so it can pass this info to the airline, so they can use it to help verify I am me. How did 1P handle this situation? By placing my card's expiration month in the form's field for the card's expiration month, by placing my card's expiration year in the form's field for my year of birth, and by leaving blank the form's field for the card's expiration year. But since there's no way I was born in 2022, the form adjusted the input to show I was born in 1922. That would be the year my grandmother was born, not me. Oh yeah, and 1P made sure to overwrite my phone number with the bank's. Naturally.

So here it is, finally: the long-awaited question. Why?

Why, what, you ask? Why, everything, I reply. Why does 1P barf so egregiously with slightly differing field names? Why does printing my CC entry now require a roll of toilet paper? Why does 1P find it necessary to abandon the CC expiration year field that is exactly next to the CC expiration month it field 0.4 milliseconds ago and track down the year of birth field in a completely different section of the form, populating it instead?

Furthermore, since billing information is an extremely common part of the payment info forms on websites, why does 1P's CC entry not include this information, as well? I suppose that in a perfect world, 1P would match the cardholder name with the identity entry of the same name and borrow the data from there, but if this post is evidence of anything, this world's imperfection would be it.

For logins, of course, the solution here is easy. Not ideal, but easy. Manually create the login entry, and 1P takes it from there. But we can't do that with CC entries. There are way too many websites with way too many variants in their payment forms for that idea to be practical.

So here's a narrower and more practical question. Is there any way (apart from the hack-and-slash toilet paper-length entries I created) to get 1P to recognise different field names for the same data point? Even if it's a workaround, is there any way at all? If not, is it even possible that we could see this functionality down the road? Or have I simply wasted 90 minutes of my time writing this, and 10 minutes of yours reading it?


1Password Version: 7.3.661
Extension Version: 4.7.3.90
OS Version: Windows 10 Home v1803 OSb17134.648 (64-bit)
Sync Type: the who-what-huh??

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited November 2019

    Wow. Thank you for that. :)You're not wrong, but there are web standards for a reason. For every issue you (rightly) point out with 1Password filling payment information, etc., due to "creative" design decisions, resulting in you needing to enter some information manually, there are many people out there who literally cannot interact with the page at all because it is unusable with accessibility devices. So I do think it's worth keeping that in perspective and appreciating that we really need to push websites to do better too, even as we try to make 1Password more cable at working around the detritus.

    But regardless, it is frustrating as a 1Password user to have it fail to do something you wanted/expected, and that's not something we're okay with. We'll continue to work to make 1Password smarter, and we're constantly making improvements. Just consider that there are billions (trillions?) of websites out there that we have never seen, and 1Password does not collect information about where you go to send to us for privacy and security reasons. Very few websites are designed the same, so our focus is on improving what we can based on testing specific issues people notify us about, and on more general tweaks that help with more generic filling issues without breaking things in other ways.

    For example, while you didn't include any URLs where you're experiencing issues (feel free to contact us at support+extension@1password.com with the details so we can investigate), I have never in my life encountered a payment form that required my phone number. Perhaps that happens to be common to some of the websites you yourself frequent often, but I'd remember it since that would really give me pause -- I am really not keen to give out my phone number to companies, as I get enough spam calls already! ;) Anyway, I think that illustrates the fact that there's a lot out there that makes one person's experience very different from another's. We'll keep working to bridge those gaps, but we can best do it by hearing from people about the specific website issues they're encountering, since it isn't possible to test against them otherwise. Often, the solution, if one exists, is in the code. What you see is not what you get, as some of the most useful information in web forms is often hidden in the structure of the page -- not something visible to the user (though that can be useful too).

    Anyway, rather than a waste of anyone's time, I really enjoyed reading your chronicle of you working through all of this. I think it highlights a lot of the challenges we have with 1Password, but also that users have making use of it. Interestingly though, you seem to be simultaneously giving 1Password too little credit and too much. To address some of the specific points that jumped out at me:

    it always leaves a field with the name "expiration date" blank.

    I haven't found that to be the case, but I'm sure that happens on some sites. If you'll let us know the particular URLs we can try to improve this, because...

    So I created a custom field in each of my card entries, titled it "expiration date", duplicated the information from "expiry date", and moved "expiration date" to be immediately below "expiry date" so I could tell for sure it is there any time I look at the entry.

    That doesn't work. 1Password does not use custom fields for filling no matter what because it doesn't know their purpose, only that of specific default fields that it's programmed to use. Custom fields are just for "human consumption", for lack of a better term: they allow you to organize your data the way you want for when you access it, rather than it being for 1Password's benefit/purpose.

    Now, that may sound like a bunch of work, especially when repeated across several entries, but there's a good reason for that. It's because it is. So why did I go to the trouble of doing all that work? Because it works. Now, every time I visit a site that wants my card's "expiration date", 1P can fill it, and I can be happy.

    It really doesn't. 1Password will either fill or not, for example, an expiration date based on the default field; any custom fields you add, no matter what you name them, will not be used. If you inspect the web form, you'll generally find that the name you see superficially on the page (e.g. "expiration") is not what is coded underneath. Super confusing for a human who can think, and it's one of many reasons that 1Password -- not having the benefit of thought -- can struggle with forms, which often contain conflicting information.

    By placing my card's expiration month in the form's field for the card's expiration month, by placing my card's expiration year in the form's field for my year of birth, and by leaving blank the form's field for the card's expiration year. [...] and 1P made sure to overwrite my phone number with the bank's. Naturally.

    If you're using a Credit Card item, no phone number will be filled by 1Password at all. It simply only deals with pone numbers when using an Identity item. So if something like that really happened to you, and I am not misunderstanding, my guess is that you have your browser setup to autofill. We recommend disabling that for many reasons, one of which is that it can cause confusion like this.

    Why does 1P barf so egregiously with slightly differing field names?

    It depends entirely on how the website is coded. Some are structured logically, even if they don't really follow web standards. 1Password is generally pretty good with those. But when logic fails, 1Password just does a "best effort" guess. That's where you get things like this:

    Why does 1P find it necessary to abandon the CC expiration year field that is exactly next to the CC expiration month it field 0.4 milliseconds ago and track down the year of birth field in a completely different section of the form, populating it instead?

    What may be obvious to you, with eyes and a brain, may not be to a computer, which has neither. What you're describing, in my experience, is a result of the website displaying the field in one place in the window when really it's in another place in the code. Sometimes you can kind of see this as a user by tabbing between fields, and finding that that doesn't take you to what you think is the "next" one, but somewhere else entirely. But I'd need to see the specific page to know what's happening in the case you're describing.

    Furthermore, since billing information is an extremely common part of the payment info forms on websites, why does 1P's CC entry not include this information, as well?

    Mainly history and simplicity. I think it would be a good addition to 1Password to allow these to be combined...but only if it can be done reliably. If you're frustrated about 1Password filling some things incorrectly now, just imagine if we got it wrong when trying to have it deal with both of these at once, especially since there is some overlap in what you're proposing (phone numbers, for example). I do hope we'll be able to find a good way to do this though, as I'm sure you're not the only one who would benefit. :)

    I suppose that in a perfect world, 1P would match the cardholder name with the identity entry of the same name and borrow the data from there, but if this post is evidence of anything, this world's imperfection would be it.

    That's a really good point and a cool idea. :)

    Is there any way [...] to get 1P to recognise different field names for the same data point? Even if it's a workaround, is there any way at all? If not, is it even possible that we could see this functionality down the road? Or have I simply wasted 90 minutes of my time writing this, and 10 minutes of yours reading it?

    It's something we'd like to do in the future, but it would require a lot of work behind the scenes to build that framework, and then a lot more in all of the apps to support it. Right now our focus is on improving the new filling engine, but we've intentionally built a lot of flexibility in there so that we can add more functionality in the future, as we get to a point where that's possible.

    Seriously, thank you for bringing all of this up. You're clearly passionate about seeing 1Password get better in the browser, same as us. We'll keep plugging away at it, and if there are sites you want us to look at just let us know. Cheers! :)

  • AGAlumB
    AGAlumB
    1Password Alumni

    Likewise, thanks for getting back to me. :) I'm glad to hear that you're also passionate about accessibility! I didn't mean to suggest that you are not (I don't know you!), but it's an important part of the big picture that I don't want to leave out for anyone reading. Thanks for understanding.

    I'm sorry to say that I am not able to reproduce what you're describing with the phone number. Credit Card items do not even have a space for the credit card holder's phone number, and while you can manually add a custom field for that yourself, 1Password won't do anything with it because only you know its purpose. Backing up a bit, I'm not suggesting that you should not use custom fields; I just don't want you to go through the trouble to add them for a purpose they will not serve. They're nice for organizing information in your items for you own use though! Anyway, we'll return to that a bit later.

    Regarding websites issues, it's no problem if you don't happen to remember them now. If you do encounter further issues though, just let us know then. Obviously a session-based URL probably won't be usable, but any details like that can help us make sure we're looking at the right thing. For example, I had no idea what "Orbitz" was; I just remember having a drink years ago. We'll investigate that -- the website, not the drink! ;)

    And you're totally right that 1Password will sometimes be able to "fill" some dropdown menus, but not others. A lot of these are not actually webform dropdown menus, but rather something the designer concocted which just looks like a dropdown menu. But if we can find a way to make 1Password handle any kind of filling it's designed to do a bit better, everybody wins, so please let us know the specifics when you encounter something like that.

    Getting back to The Mystery of the Filling Phone Number, I really appreciate the additional details and screenshots. I had misunderstood you earlier. Since you'd been talking about creating custom fields with various variations on "expiry", etc., I thought you were still talking about that stuff later on with the phone number. To be completely clear, there is literally no code in 1Password that will do anything with a custom field. So it's impossible for those to fill. But it sounds like that's not what you're using after all. It should not be filling the bank's phone number from a Credit Card item either, so that would be a bug. I'm not able to reproduce it though, so I think we need some more information.

    It looks like you're using Firefox, and I tried that here myself with booking a flight at https://www.orbitz.com/ but was not only unable to get a phone number to fill from a credit card item (expected), it also didn't work on that page with an Identity item (bug), so we'll have to look into improving that. Thank you for bringing it up!

    But that still leaves the question of what's different about your setup compared to mine. Can you tell me the exact steps you're taking, the browser version, and if you encounter the same thing with other extensions disabled? Let me know and I'll see if I can figure out why this is happening.

    Finally, thank you for choosing 1Password in the first place! Open source is a great thing, and I use a lot of it on a daily basis (heck, most of the web runs on it!) But there is certainly something to be said for commercial software that makes our lives a bit easier -- even if imperfect. :chuffed:

  • AGAlumB
    AGAlumB
    1Password Alumni

    No worries. Doing some spring cleaning here myself, and we'll be here no matter what. Rock on! :sunglasses:

  • AGAlumB
    AGAlumB
    1Password Alumni

    @PellaAndroid: You don't look like an idiot at all. You were just ahead of your time. Actually...I guess that does tend to make people look a bit crazy, but you're in good company with Galileo and the rest of em at least. ;)

    I believe (95%) that the issue you originally reported was also reported by someone else fairly recently, and I was able to reproduce it in that case. I think you're maybe seeing something different now due to changes on the website itself.

    The bad news is that the Windows app is a bit behind schedule with some changes we've been working on, so an update that includes a newer filling "Brain" may take a bit. But the good news is that this does not seem to happen where we have the newer Brain, and I've got an issue filed for this to test specifically as we prepare future updates on Windows.

    TL;DR: You're not losing your mind -- it just feels like that sometimes with all of the complexities of various websites. But we're on the case. :sunglasses:

    P.S: And we definitely want 1Password to be able to make 1Password's filling more flexible too, to be able to fill multiple data types more seamlessly. We'll see what we can come up with in the future!

    ref: opw/opw#3930

  • AGAlumB
    AGAlumB
    1Password Alumni

    @PellaAndroid: :lol: Sorry, the spam filter got you. It's a common practice for spammers to post and then immediately edit to change the contents -- often to add links, so the presence of a link in the post is another one. You didn't do anything wrong, but we've gotta be on top of stuff like that to keep this forum tidy. Anyway, all good now. :)

    Probably not coincidentally to your having this issue now, we've been experimenting with some ways to allow 1Password to fill custom fields and have identified some side effects with that. I suspect this example is another one of them. Thank you so much for sharing it!

    Honestly, I wish we were at a point where this feature was "done", as it can be really cool when it works. I'm sure we'll get there. :)

    ref: xplatform/brain#126

  • AGAlumB
    AGAlumB
    1Password Alumni

    Wait...You're telling me y'all snuck some less-than-fully-documented enhancements into the code?

    @PellaAndroid: Yes. :lol:

    ...that I haven't proved anything at all?

    No, you've proved you're smarter than me, because it took you less time to discover it in this case. :lol:

    ...that you still think I must have hallucinated all the other times I imagined it happened, which I reported in the OP?

    I can neither confirm nor deny that.

    :lol:

    However, in all seriousness, it's entirely possible that some of the earlier things you reported were related, albeit not intended.

    I have no idea what side effects you could possibly mean. I don't see any secondary effects. I see only the effect I reported, defended, and verified--and, it appears, probably all for naught.

    When it works it works. Other times, it doesn't at all, or fills incorrectly. Definitely still work in progress, and not supported in all of the apps. So it isn't something we're going to have a parade for at this stage. I think it's pretty dang cool, but others rightly point out that it's not where we want it to be. Ah well. I'll be patient.

    P.S. Understood about the spam filter. Having never been a spammer or been in a position where it was necessary to guard against them, I'm unfamiliar with their tactics. It's much easier to fall into a trap when you don't know it's there or even what to look for. But hey, my new comment (in its edited version, even!) was preserved, and I didn't have to retype it from scratch. That's the most important part. Otherwise, I don't know for sure whether I would have retyped it or not.

    Oh totally. And I'm sorry for the scare. I would have been annoyed to lose a post too. I have, plenty of times, but because of a browser or connection issue. You don't need to worry about the spam filter, because you're cool. The only way you'd actually get a post nuked is if it's in fact spam or otherwise in violation of the guidelines, and both cases are mercifully rare here. On a related note, thanks for giving me something non-PTSD-inducing to find in the spam filter today! :)

    OTOH, it appears it would have made little to no difference if the comment had fallen into The Bit Bucket, so I'll go crawl back under my rock, stop hassling you good people, and leave you to your work. Good night.

    I'm really sorry if I gave you that impression. I just don't want either of us to get too excited about developments in this area because they're still very much at an early stage. If you encounter anything else weird, please let us know! Could be working as intended, but possibly a bug or something else that just needs to be improved. Seriously, thank you! :chuffed:

This discussion has been closed.