Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

@ianbjacobs see https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-277902934 - basically what Nick describes there (trying to avoid summoning him again, so not putting in his username :)). 

We have the same requirements: with the "capabilities" in place, the question ("can make payments?") can be answered without needing to go wake up the service worker - however, it will need to hit the Payment Manager's Payment Methods database, which might require IO (so this still needs to be a promise, I think - tho the value could be cached, so could still be fast). 

On the other hand, "can I make an 'ACTIVE' payment?" needs to go do fancy things - like talk to hardware, network request, whatever)... and in the case of `show()`, the "can make payments?" question can also be answered quickly - before we spin up the service worker to actually handle the payment request.  

> I'm sorry but I'm not clear on what the third option would be.

In the the form of an API:

```JS
//During checkout form construction
// this would be fairly fast
if (await request.isCapable()) {
  // Build checkout form - show fancy buttons, but maybe disable
  // some of them until request.canMakePayment() actually confirms we can do stuff. 
  fancyPaymentButtons.forEach(button => button.disabled = true);
  if (await request.canMakePayment()) {
    // Ok, let's actually enable 
    fancyPaymentButtons.forEach(button => button.disabled = false);
  }
}
```


-- 
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/96#issuecomment-278851432