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 <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 04:14:13 UTC