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 <bnichol...@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 > > >