Re: [w3c/payment-handler] Ability to set default instrument for given handler (#173)

Hi all,

I just chatted with @adrianhopebailie to walk through his proposal. I found it useful during the discussion to write down the scenarios we have in mind, and illustrate how the two pieces of information (selectedInstrument and displayedInstruments) combine to give payment app developers information they need for a variety of potential user experiences.

Here are the scenarios when the user clicks the the payment app for bobpay.com.

1) User agent displays "bobpay.com" (with no information about any instruments displayed).
    In this case, selectedInstrument is null and displayedInstruments is empty.
    The payment app could behave in different ways depending on expectations set
    with the user. It might act immediately using the default instrument, or it might display all the
    available instruments.

2) User agent displays "bobpay.com Visa ending 1234".
    In this case, selectedInstrument is the instrumentKey associated with that card, and
    displayedInstruments is an array with one value (that same instrumentKey).
    The payment  app would presumably act immediately on the default instrument.

3) User agent displays "bobpay.com Visa ending 1234 (more)" where 'more' can be
    activated. The user agent might behave differently when 'more' is activated, 
    so let's examine each case:

    a) The user agent displays all of the payment app's instruments, then the user selects
         one. In this case, selectedInstrument is the key associated with that instrument, and
         displayedInstruments is an array with the keys of all instruments displayed by the
         user agent.

    b) The user agent invokes the payment app directly. In this case, selectedInstrument
         is null and displayedInstruments is an array with the key associated with the
         Visa card.
   
NOTES:

 * All of the scenarios above result in different data reaching the payment app.
   The goal was to ensure that payment app developers could understand the
    "display context" which I think this proposal addresses.

 * There is no proposal here that the browser do 3(a) or 3(b), only that whatever
   the behavior is, the user agent "commits" to sending the two pieces of information
   to the payment app.

 * We should define the behavior of user agents when the payment app has set
    a default instrument and when it has not. I think that when the payment app
    has not specified a default payment instrument, it's ok for the user agent to provide
    one (e.g., "most recently used) as long as it conveys the information to the payment
    app, as Adrian has proposed. If the payment app has specified a default instrument,
    we have to decide whether to require the user agent to display it, or something else
   (e.g., must not display any other instrument, but may display no instrument).
          



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373