[w3c/payment-handler] CanMakePaymentEvent handling algorithm unclear (#330)

The current specification for `CanMakePaymentEvent` handling in the Payment Handler API is unclear in light of the `canMakePayment`/`hasEnrolledInstrument` change in Payment Request API [1][2].

First, the new `canMakePayment` is meant to represent the existence of support without checking available instrument. So perhaps `CanMakePaymentEvent` should not be dispatched at all in this case.

Second, if `CanMakePaymentEvent` should be dispatched for `hasEnrolledInstrument`, the current algorithm [3] is unclear about the return value when the steps are terminated early:
> 4.3 Handling a CanMakePaymentEvent
Upon receiving a PaymentRequest, the user agent MUST run the following steps:
> 1. If user agent settings prohibit usage of CanMakePaymentEvent (e.g., in private browsing mode), terminate these steps.
> 2. Let registration be a ServiceWorkerRegistration.
> 3. If registration is not found, terminate these steps.

Chrome's current implementation returns `true` if the early termination is triggered from step 1 or if it is triggered for just-in-time installable payment handlers from step 3. This will be the wrong answer if the website's intention is to check `hasEnrolledInstrument`.

I think it will make more sense to clarify in the spec these two changes:

- `CanMakePaymentEvent` is only dispatched when website queries `hasEnrolledInstrument`
- Implementations should return `false` when `CanMakePaymentEvent` cannot be dispatched, either due to private browsing mode or if the payment handler is not installed.

[1] https://github.com/w3c/payment-request/pull/806
[2] https://lists.w3.org/Archives/Public/public-payments-wg/2018Nov/0018.html
[3] https://w3c.github.io/payment-handler/#handling-a-canmakepaymentevent

-- 
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/330