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 >
