Re: [whatwg] Additional details for invoking requestAutocomplete
Also, in response to something Ian wrote on another thread: > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a form > without using that API. That is true, but I don't know of a better way to convey this information from the page to browser. Additional attributes on the cc-number field? > Also, I don't understand how these are supposed to work. How is the > browser supposed to know the balance on my credit cards or bank accounts? > How is the browser supposed to know which of my cards are good for USD and > which are good for GBP? If the browser is just a dumb number memorizer, it probably won't, in which case it may return a card that denies the transaction. The new API doesn't /guarantee/ the returned card will work, it just increases the likelihood of a successful transaction. Conceptually, how the browser /could/ know the balance on the credit cards is if it pings some remote server to obtain this information, or if it remembers each card's credit limit (ignoring how much of the limit may have already been used), etc. -- Evan Stade On Wed, Apr 23, 2014 at 9:13 PM, Evan Stade wrote: > Specifically, Chromium would disable Wallet for transactions over a > certain limit (at the moment, that's $2k, but this business logic is > subject to change). When Wallet is disabled, users can still store/access > their data in Chrome/Chrome Sync. > > > -- Evan Stade > > > On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson > wrote: > >> This optional argument sounds reasonable to me (FWIW, I'm working on >> the requestAutocomplete implementation for Firefox). The transaction >> fields also seem sensible, but I have no experience with payment APIs, >> so I can't give feedback on how well this will work with payment >> providers in general (and whether any additional fields might be >> useful). Those working on Mozilla's payment APIs are aware of this >> thread, so hopefully they'll be giving feedback if they have anything >> to add. >> >> When I first read this proposal, I was under the impression that the >> browser would somehow detect whether transactions would put users over >> their card limits, but maybe you're going for something simpler than >> that. Could you elaborate on how Chromium will handle these >> transactions differently? >> >> - Brian >> >> >> On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: >> >> > Hi WhatWG. >> > >> > Currently, requestAutocomplete lets a user agent provide the same user >> > experience across multiple sites for common data input flows. A site >> > describes the data it desires (via a form and autocomplete attributes), >> and >> > the user agent uses this information and what it knows about the user to >> > expedite data input. For example, if one of the form elements has >> > autocomplete=”cc-number” the browser might provide an experience >> tailored >> > for a payment flow, or if there’s an element with autocomplete=”bday” >> the >> > browser might use an experience that’s tailored for sharing identiy. >> > >> > We’ve found that there are some details of the interaction which might >> > affect the UX which cannot be inferred from the data inputs. We propose >> to >> > add an optional argument to the requestAutocomplete method. Thus >> invocation >> > would look like: >> > >> > form_element. >> requestAutocomplete(details); >> > >> > This |details| argument would be an object where key-value pairs provide >> > additional details regarding the request. The spec should define a set >> of >> > keys and associated data types which are recognized. There are currently >> > two key-value pairs we would like to add: >> > >> > key: “transactionAmount” >> > value: number >> > description: For data that is going to be applied towards a >> > transaction, the /maximum/ value of the transaction. The browser does >> not >> > guarantee that the returned payment instrument will work, but keeping >> the >> > transaction under this amount will increase the likelihood of receiving >> a >> > valid card number. >> > >> > key: “transactionCurrency” >> > value: string >> > description: a valid ISO 4217 currency code that describes the >> > currency for transactionAmount. If not provided, the default is “USD”. >> > >> > Justification? There are upper bounds on certain payment instruments, >> for >> > example different credit cards have different credit limits; a debit >> card >> > is linked to a bank account with a certain balance. It’s a much >> preferable >> > user experience to be able to catch these problems earlier rather than >> > waiting for the merchant to attempt the transaction and have it fail (or >> > have a user’s account overdrawn). Concretely, Chromium wants to handle >> > transactions over $2000 differently from transactions under that amount. >> > >> > Does this seem reasonable? >> > >> > >> > -- Evan Stade >> > >> > >
Re: [whatwg] Additional details for invoking requestAutocomplete
Specifically, Chromium would disable Wallet for transactions over a certain limit (at the moment, that's $2k, but this business logic is subject to change). When Wallet is disabled, users can still store/access their data in Chrome/Chrome Sync. -- Evan Stade On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson wrote: > This optional argument sounds reasonable to me (FWIW, I'm working on > the requestAutocomplete implementation for Firefox). The transaction > fields also seem sensible, but I have no experience with payment APIs, > so I can't give feedback on how well this will work with payment > providers in general (and whether any additional fields might be > useful). Those working on Mozilla's payment APIs are aware of this > thread, so hopefully they'll be giving feedback if they have anything > to add. > > When I first read this proposal, I was under the impression that the > browser would somehow detect whether transactions would put users over > their card limits, but maybe you're going for something simpler than > that. Could you elaborate on how Chromium will handle these > transactions differently? > > - Brian > > > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > > > Hi WhatWG. > > > > Currently, requestAutocomplete lets a user agent provide the same user > > experience across multiple sites for common data input flows. A site > > describes the data it desires (via a form and autocomplete attributes), > and > > the user agent uses this information and what it knows about the user to > > expedite data input. For example, if one of the form elements has > > autocomplete=”cc-number” the browser might provide an experience tailored > > for a payment flow, or if there’s an element with autocomplete=”bday” the > > browser might use an experience that’s tailored for sharing identiy. > > > > We’ve found that there are some details of the interaction which might > > affect the UX which cannot be inferred from the data inputs. We propose > to > > add an optional argument to the requestAutocomplete method. Thus > invocation > > would look like: > > > > form_element. > requestAutocomplete(details); > > > > This |details| argument would be an object where key-value pairs provide > > additional details regarding the request. The spec should define a set of > > keys and associated data types which are recognized. There are currently > > two key-value pairs we would like to add: > > > > key: “transactionAmount” > > value: number > > description: For data that is going to be applied towards a > > transaction, the /maximum/ value of the transaction. The browser does not > > guarantee that the returned payment instrument will work, but keeping the > > transaction under this amount will increase the likelihood of receiving a > > valid card number. > > > > key: “transactionCurrency” > > value: string > > description: a valid ISO 4217 currency code that describes the > > currency for transactionAmount. If not provided, the default is “USD”. > > > > Justification? There are upper bounds on certain payment instruments, for > > example different credit cards have different credit limits; a debit card > > is linked to a bank account with a certain balance. It’s a much > preferable > > user experience to be able to catch these problems earlier rather than > > waiting for the merchant to attempt the transaction and have it fail (or > > have a user’s account overdrawn). Concretely, Chromium wants to handle > > transactions over $2000 differently from transactions under that amount. > > > > Does this seem reasonable? > > > > > > -- Evan Stade > > >
Re: [whatwg] Additional details for invoking requestAutocomplete
This optional argument sounds reasonable to me (FWIW, I'm working on the requestAutocomplete implementation for Firefox). The transaction fields also seem sensible, but I have no experience with payment APIs, so I can't give feedback on how well this will work with payment providers in general (and whether any additional fields might be useful). Those working on Mozilla's payment APIs are aware of this thread, so hopefully they'll be giving feedback if they have anything to add. When I first read this proposal, I was under the impression that the browser would somehow detect whether transactions would put users over their card limits, but maybe you're going for something simpler than that. Could you elaborate on how Chromium will handle these transactions differently? - Brian On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=”cc-number” the browser might provide an experience tailored > for a payment flow, or if there’s an element with autocomplete=”bday” the > browser might use an experience that’s tailored for sharing identiy. > > We’ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element. requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: “transactionAmount” > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: “transactionCurrency” > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is “USD”. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It’s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user’s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade >
Re: [whatwg] Additional details for invoking requestAutocomplete
Perhaps now is a more appropriate time for this discussion, given that requestAutocomplete is now published in the spec (!). -- Evan Stade On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=”cc-number” the browser might provide an experience tailored > for a payment flow, or if there’s an element with autocomplete=”bday” the > browser might use an experience that’s tailored for sharing identiy. > > We’ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: “transactionAmount” > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: “transactionCurrency” > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is “USD”. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It’s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user’s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade >
