Re: [w3c/payment-request] "User accepts the payment request algorithm" needs to clarify where Payment Handlers are invoked (#476)

@marcoscaceres,

It seems to me that show() and canMakePayment() could address this topic in similar or even identical ways. This led me to compare the show() and canMakePayment() algorithms. I note that the show() algorithm steps 14.1-14.5 are more detailed than the similar steps of canMakePayment(), that is the single step 6.1. I am wondering whether those could be harmonized.

If so, then I think that the language of show() is pretty good for addressing this issue. It says currently:

"If the user agent has a registered payment handler that supports identifier, then check if the payment handler is authorized and capable of handling the payment request with data. If the check returns in the affirmative, then add payment handler to handlers."

In the case of canMakePayment() it might read at the end of the sequence of steps:

"If the user agent has a registered payment handler that supports identifier, then check if the payment handler is authorized and capable of handling the payment request with data. If the check returns in the affirmative, then resolve promise with true, and abort this algorithm."

Thoughts?

Also, I am inclined to add a paragraph (one sentence) to the start of 18.2 Payment Handler Matching. Something like:

"A user agent's payment handler matching algorithm takes into account the requirements of this specification as well as matching requirements defined in payment methods and other specifications."

Just to note a few of them here on GitHub:
 * Payment method specific capability matching
 * Payment method manifest authorization
 * Whether a merchant requires a 3DS flow (cf the 3DS task force; this is in development though it is still early days).

Ian





-- 
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/issues/476#issuecomment-361771240