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 <estade@chromium.org> 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 <bnicholson@mozilla.com>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 <est...@chromium.org> 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
>> >
>>
>
>

Received on Thursday, 24 April 2014 21:58:29 UTC