- From: Danyao Wang <notifications@github.com>
- Date: Fri, 08 Feb 2019 11:36:46 -0800
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/pull/833/review/201752555@github.com>
danyao commented on this pull request.
> algorithm.
</li>
+ <li>Let <var>handlers</var> be a <a>list</a> of registered
+ <a>payment handlers</a> that are authorized and can handle
+ payment request for <var>identifier</var>.
+ </li>
+ <li>For each <var>handler</var> in <var>handlers</var>:
+ <ol>
+ <li>Let <var>hasEnrolledInstrument</var> be the result of
+ running <var>handler</var>'s <a>steps to check if a payment
In Chrome we're using the existing steps in the basic card spec to determine if a card should be considered "enrolled". For payment handler, I believe the equivalent is the CanMakePaymentEvent. In both cases, our rationale is that the new canMakePayment() method checks the existence of a payment handler for the specified method, and hasEnrolledInstrument() checks the actual "can-make-payment" property of the payment handler.
I think renaming "steps to check if a payment can be made" to "steps to check if the handler has an enrolled instrument" may be more clear in the long run, but it introduces a lot of changes to existing spec without changing any behavior. That's why I opted to reuse the existing language as much as possible.
--
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-request/pull/833#discussion_r255210394
Received on Friday, 8 February 2019 19:37:07 UTC