Credit Card information is filled in at the wrong fields when using Stripe Checkout

fresswolf

Stripe Checkout is a popular payment solution that overlays CC forms on top of your website. What happens in my online shop is that customers who use 1Password cannot checkout, as 1Password messes with the cart form.
Here is a quick simplified demonstration of the problem.
https://jsfiddle.net/tgmt1xzs/1/

How can I prevent 1Password from filling out my input fields?

---

1Password Version: 6.3.1
Extension Version: 4.5.6
OS Version: OS X 10.11.5
Sync Type: Not Provided

fresswolf

Please note that to reproduce the issue, fill out at least one of the number fields in the above demonstration. For example, input 1 for the first number field and then try to checkout with a credit card. That value then changes from 1 to the month of your CC's expiry date.

rogerdodger

Hi @fresswolf,

I will admit that my knowledge here is limited but have you looked at the Agile Bits documentation on web design best practices for working with 1Password?
https://support.1password.com/compatible-website-design/

Someone from Agile Bits should respond with more intelligence soon but have a look at that document and see if it helps.

fresswolf

Hi @rogerdodger thanks for the answer. Yes I've looked at those guidelines. I've even set autocomplete="off" on the input fields, but 1Password seems to ignore those

rogerdodger

Hey @fresswolf sorry I wasn't much help. It seems like adding autocomplete="off" to the fields should accomplish what you need.

I am interested to see what Agile Bits suggests here.

AGAlumB

@fresswolf: I don't think I'm seeing what you're describing there. Maybe I'm misunderstanding, but when I fill credit card details they are filled correctly and the form rightly rejects the fake payment info:

Are you getting a different result? We'll get to the bottom of this!

fresswolf

@brenty: I can see right in the background of your screenshot (you have to zoom in): "How many computers you want to order?", then the value "09". I'm pretty sure that this "09" came from your credit card month, because if you would enter it by hand it would come up as "9".

So basically what happened here is that 1Password messed up the amount of items ordered. It's a serious issue for stripe users, as this popup "stripe checkout" form is just the authorisation. After that (assuming your CC wasn't rejected) the server backend handles the form. Let's say you select 1 "computers" in the form, then enter your CC details with 1Password and authorise the payment for 1 computer (not more). But 1Password alters that 1 to 09, so the backend will think the client cheated and wanted to buy 9 computers, but authorized the payment only for 1!

AGAlumB

@fresswolf: Thanks for clarifying what you meant! But I'm not sure what this has to do with Stripe exactly. We use Stripe both for license purchases in the AgileBits Store and 1Password Families/Team subscriptions and haven't seen anything like this. Is this a reproduction of some code Stripe is offering themselves? If so, can you point me in the right direction? I wasn't able to find anything like this in their documentation. It seems like the issue isn't with the payment portion of the form at all, but the inventory. Thanks in advance! :)

fresswolf

@brenty: On your page you use a custom form for the credit card. Stripe provides an "official" form, which is the popup thing shown in the example above. It's called Checkout: https://checkout.stripe.com.

The issue is when using Stripe's checkout and you have any kind of input field on the page with a value other than 0, 1Password fills out the CC month into that field.

When I look at past discussions, 1Password compatibility with Stripe's checkout form seems to be an on and off issue. As you can see in my demo I marked the number input fields as readonly while the credit card form is shown. Yet 1Password fills out those readonly fields. Can you tell your developers to at least ignore readonly fields? I understand why 1Password ignores the autocomplete="off" attribute, but I see no use case where someone wants a readonly field to be filled out! It would give us web developers some control.

AGAlumB

On your page you use a custom form for the credit card. Stripe provides an "official" form, which is the popup thing shown in the example above. It's called Checkout: https://checkout.stripe.com.

@fresswolf: Thank you so much for the additional information! I'm testing this some more and filing bug report for this.

The issue is when using Stripe's checkout and you have any kind of input field on the page with a value other than 0, 1Password fills out the CC month into that field.

Yep, I'm seeing that too. Just wanted to make sure we're on the same page here. I really appreciate it!

When I look at past discussions, 1Password compatibility with Stripe's checkout form seems to be an on and off issue. As you can see in my demo I marked the number input fields as readonly while the credit card form is shown. Yet 1Password fills out those readonly fields. Can you tell your developers to at least ignore readonly fields? I understand why 1Password ignores the autocomplete="off" attribute, but I see no use case where someone wants a readonly field to be filled out! It would give us web developers some control.

I'm really sorry for the trouble here. Indeed, browser filling is almost all grey area, and one change we make to improve things in one case can have unforeseen consequences in another. And of course the forms can change over time too. But unfortunately ignoring read-only fields completely isn't really an option. Many forms that 1Password users do want to fill will use this as a "trick" to prevent this from happening. Just because the user wants to do something doesn't mean the website's developer or owner want to allow it. But that doesn't mean we're giving up. We'll see if we can find abetter balance here. Thanks again for bringing this up! :)

ref: BRAIN-275

littlebobbytables

Hi @fresswolf,

Let's start with why we have trouble at all. The way that 1Password works at the moment is we attach code to every document - this is what allows us to interact with a page. It has to be added to each document which means each IFrame if applicable and so on, if we don't do this we can't interact with the contents of the IFrame and this is actually a problem we have in iOS that we need to work on.

When the user asks 1Password to fill a message is sent to each document and a description of the page is returned and passed along to 1Password. The issue is each frame is sent independently and analysed independently. This is why 1Password will correctly fill the Stripe modal dialog but then also attempts to interact with the document behind it. Despite this we can still achieve fairly reasonable success by ensuring 1Password behaves correctly with the page behind even if it's treating it as a unique page.

I'll skip the specifics but there are things I believe we can do better here but what we really need is something that can help you right now rather than an improvement to the filling logic that I can't offer an ETA on.

So I'm wondering, how much control do you have over your online shop? I was able to alter the example page so we didn't touch the fields. So depending on how closely it replicates your site and assuming the changes don't affect the site in other ways we could help tweak the code so that the not-as-intelligent-as-it-needs-to-be 1Password doesn't put you and your customers in the crappy situation that they're in right now. Obviously it's not great that resolving this quickly is by way of suggested alterations to the site but I'm thinking of what will help you right now rather than what is right which will take longer. We are sorry for the troubles 1Password has caused.

fresswolf

@brenty, @littlebobbytables: thank you both for the detailed answers!
@brenty: can you give me an example of a credit card form where a readonly field is used? I can't imagine anything like that, but I must be wrong. Because the browser prevents any editing of readonly fields it must mean that they use some javascript to fill the readonly fields with the input from other fields, which 1password can't access?
@littlebobbytables: I have full control over the forms. However, it should be a simple single page shop, where the product and the amounts are on the same page and are payed on the same page through the infamous stripe checkout button. You said you were able to alter the example page to prevent the filling, can you share that to me? That would be great!

littlebobbytables

Hi @fresswolf,

I'll contact you shortly with the details.

ref: ARH-28685-129

kevinranks

Hi @littlebobbytables,

I'm have a very similar issue as the one mentioned by @fresswolf, except I'm using Stripe Elements.

I have a Postal Code field followed by Stripe's Credit Card element. Stripe.js will replace #card with an iframe that contains the credit card inputs.

My form code looks like this:

<div class="modal-form__field materialize"> <input type="text" id="postal-code" name="postal-code" autocomplete="postal-code" class="validate" required aria-required="true" ng-model="modal.payment.postalCode"> <label class="materialize__label" for="postal-code" data-error="please enter a valid postal code">postal code <span class="req">*</span></label> </div> <div class="modal-form__field materialize"> <span id="card" class="stripe-field materialize__textarea"></span> <label id="card-label" for="card" class="materialize__label stripe-field-label" data-error="{{ modal.card_error_message }}">card <span class="req">*</span></label> </div>

If I fill out my postal code then use 1passwords credit card auto fill feature, it replaces the postal code value with the expiration month of my credit card. The credit card details do get filled out correct.

I can understand the challenged involved in creating an auto filler that covers edge cases, but shouldn't the autocomplete attribute be the final decider?

littlebobbytables

Hi @kevinranks,

Currently we only use the presence of the autocomplete field to help shape the decision made by the brain but I am hoping this will change. We're looking using this information to bypass all of our own filling logic but I can't offer an ETA as to when we will see it either in a beta version of 1Password and assuming all goes well, a stable. We agree though, we think we've not been aggressive enough in using this information and if all goes well in the future 1Password won't let anything override the autocomplete attribute without a specific exception added by us (just in case we find a site that either tags fields incorrectly or misuses it to try and stop autofill).

ref: BRAIN-340

kevinranks

Thanks @littlebobbytables,

In your previous comments in this thread you mentioned a possible work around for fresswolf... could that apply to my issue as well?

littlebobbytables

Hi @kevinranks,

I'm going to email you. Looking back I'm not sure what may have helped there will here so we may need to look into this in more depth. You should receive an email from us soon.

ref: ZZU-39229-719