Re: [w3c/payment-handler] Use payment method manifest for registration-time validation? (#248)

> if a payment app supports N payment methods and is "not authorized" for one of them, should the entire registration be scrapped, or should the payment app still be able to register for the other payment methods (either open or authorized)?

We can store the registration on disk, but warn in developer console about the payment methods that were not permitted. We can re-check the permissions at the time of payment and re-print developer console warnings at that time as well. Such behavior would benefit web developers the most, IMHO.

> Suppose the FooApp supports basic card and Alipay but is not authorized to support Alipay.
The merchant accepts both payment methods, so FooApp matches. FooApp controls the
user experience of selection within the handler, so the browser can't prevent the user
from selecting Alipay. The browser can only complain once Payment Handler API returns.

If FooApp is not authorized to handler Alipay, then the browser should not pass Alipay's payment method name into FooApp through CanMakePaymentEvent and PaymentRequestEvent. At that point, FooApp has no way of knowing whether the invoking website requested payment via Alipay. As a precaution, the browser should verify that the payment method identifier in FooApp's response is one of the authorized payment methods for FooApp. Otherwise, the browser should behave as if FooApp returned an error and print an error message to the developer console explaining what happened exactly.

-- 
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/248#issuecomment-363824698