- 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