W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Re: [w3c/webpayments] Registration: App supports method but user has no instrument for that method (#110)

From: Tommy Thorsen <notifications@github.com>
Date: Fri, 27 May 2016 02:59:52 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>, Comment <comment@noreply.github.com>
Message-ID: <w3c/webpayments/issues/110/222108429@github.com>
@adrianhopebailie 
Now that I read the proposed text again, it does indeed allow for this case, but maybe the text could be clearer in stating that an instrument does not necessarily have to be registered for a method for it to be put in the enabled list, as long as it's easy to do so on the fly.

Another thing that I think might be confusing with the current text is that it mentions the `supported` state of a payment method as if it was a concrete state, but it's not. `supported` is an entirely abstract concept, meaning that the payment method is not in the `enabled` list, but it could potentially have been, if the user had configured it so.

Let's look again at (part of) the original question:
> Merchant supports C.
>
> Does browser match on C and display it, even though the user has no relevant payment instrument?

If we take "Merchant supports C" to mean "C is `supported`, but not `enabled`", then matching on C is impossible, as `supported` payment methods are not actually listed anywhere and can't be matched on by the mediator.

I'll try to make a PR that makes these things a bit clearer.

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/110#issuecomment-222108429
Received on Friday, 27 May 2016 10:00:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 May 2016 10:00:46 UTC