Re: [w3c/webpayments-payment-apps-api] Recommended payment apps (#74)

I have experimented a bit with how to do Payment App recommendations outside of the Payment Request API. You can try out my approach by first installing an [Android client with support for Payment Apps](https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/clients/README.md) and then heading over to my [dummy online shop](https://tommythorsen.github.io/webpayments-demo/merchants/clothing/).

If you select to pay with TommyPay on this merchant page, it tries to call `PaymentRequest.show()`, while intercepting the NOT_SUPPORTED_ERR exception. If this payment method is not supported, it redirects to the signup page for TommyPay. This code looks something like this:

```javascript
request.show()
.then(function(paymentResponse) {
    // handle successful payment
})
.catch(function(error) {
    console.log("show() error: " + error);
    if (error.code == DOMException.NOT_SUPPORTED_ERR) {
        window.location.href =
            "https://tommythorsen.github.io/webpayments-demo/payment-apps/tommypay/signup/?redirect_url=" +
            encodeURI(window.location.href);
    }
});
```

Since we pass the url to the current page as `redirect_url` to the signup page, the signup page is able to redirect back to the merchant upon successful signup, so that the checkout process can continue seamlessly.

Does this meet the needs of a recommendation system, or are we missing something important? It would certainly be possible for the merchant to show some intermediate UI, asking the user if they want to install TommyPay before redirecting there.

There's one use-case that is hard to support in this way: you may have noticed that I have separated the payment actions into individual buttons for the individual payment methods. For some merchants, this may not be desirable - they may wish to have one payment button that contains all their supported payment methods. In such a secnario, since most user agents have native support for `basic-card`, `PaymentRequest.show()` will never throw a `DOMException.NOT_SUPPORTED_ERR". This leaves the merchant no opening to do recommendations, even if they would really prefer to nudge the customer to use something other than `basic-card`. This case would have worked better if the user agent could display both the set of installed payment methods, and the set of recommended ones simultaneously.

This example does not make use of `PaymentRequest.canMakePayment()`. Depending on how we want this function to work, we may open up more possibilities for merchants to do recommendations in other ways.

-- 
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/74#issuecomment-278941318