Given the input so far, I am leaning toward this perspective: * canHandle() is designed for handling payment method specific filters. It is not designed as a general-purpose gate. * For use cases beyond payment-method specific filtering, payment apps may decline to make payments and in this case should message the user appropriately. (E.g., Merchant is risky, can't do international payment, etc.). The user would acknowledge the notification and the payment app would return a "fail". * When a payment app fails, the user agent may prompt the user to choose another (and Chrome does this today). I think this is preferable to silently failing to match. I agree with @tommythorsen that "it would be downright mystifying if a Payment App that I usually pay for things with all the sudden doesn't show up on a website." 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/webpayments-payment-apps-api/issues/92#issuecomment-274097944
Received on Friday, 20 January 2017 15:23:19 UTC