From our discussion with merchants we have gather some feedback on PaymentRequest API. Detecting if a merchants can use a particular native payment app for completing the checkout resulted as one of the highly requested API. For large volume merchants it is important for them to control end-to-end checkout flow and without such provision adopting to standard API will take longer for these merchants.

Introduce paymentRequest.validate() or canMakePayment() kind of API to the PaymentRequest spec to achieve,

1. Parity with Apple pay
2. Better user experience
3. Merchants wants it

W3C payments working group have discussed this issue in length and decided not to add such an API. In this document, I’m trying to give my reasoning and requesting WG to re-consider their decision.

Github issue covered some discussion around this problem: https://github.com/w3c/browser-payment-api/issues/247

Some concerns expressed over user privacy,

1. Websites can probe which payment methods user supports
2. Some users may not want websites to know about payment apps

The alternate proposed by Issue-247,

• Merchants to use PaymentRequest behind "Checkout" button with payment method merchants wants to use
• You call show() and wait for the promise that is returned to settle.
• If the browser can't satisfy the payment request, say because the user doesn't have any matching payment apps or instruments, then the promise is rejected with a NotSupportedError. When you see this result you redirect the user to the fallback flow.
• If the browser can satisfy the request then the payment request continues until either the user cancels or the promise resolves with the payment response.

Theoretically this flow could work but from merchants point of view this is not how they intend to present page to the users. Instead of displaying “Checkout” button, merchants want to show “Pay with Bob Pay” button.

There are few reasons why,

• Better conversion rate: The button appeals to users as safer and quicker option to checkout
• Match behavior from iOS : Apple Pay provides “canMakePayment” API and merchants wants to match this same behavior.
• Better user experience: If BobPay is not available for payment, users are not presented false impression of BobPay as an option and instead they can present checkout experience with basic card payments. (more details on this below)

We can already see merchants like Shopify adopting this behavior as it provides above benefits. These merchants present “Pay with Android Pay” behind PaymentRequest API without knowing AndroidPay availability so they could match their iOS behavior. For example,

(iOS vs Android behavior)

If we would follow WG alternate proposal described in Issue-247, and merchants follow "Pay with X App" flow, user experience would not be on par with how iOS + Apple Pay users would experience it. It is up to merchants to decide the behaviour here but it is possible to fix this behavior that would result in better user experience.

(Falling back to traditional checkout if payment type is unsupported)

Above example on iOS would have better user experience because merchant ends up displaying “Pay with Apple Pay” button only if the app is exists.

Let’s address working group concerns and alternate proposals for each,

User-agent can delegate decision on if a merchant can check payment app availability. Payment apps can decide to pass this information based on existing relation with the merchant.

• Step1: Merchant X creates a relation with payment app Y. Payment app Y validates the merchant and provides necessary certificate and merchant ID
• Step2: Merchant site on user-agent calls “validate()“ or “canMakePayment()” along with payment app Y’s PMI
• Step3: User-agent checks if payment app Y exists on the device and initiates async call with merchant-X “data” field along with domain name of merchant X. If payment app does not exist, user-agent resolves promise with ERR.
• Step4: Payment app Y verifies domain name, merchant ID. If Payment App Y trusts the merchant X and has existing relation with merchant X, it provides information back to user-agent. If it doesn’t, returns ERR
• Step5: User agent resolves promise with information from payment app Y.

If payment app trusts the merchant, there is also possibility to pass more information like card art or if user can with merchant gift card that user saved in Payment app. These small user experience improvements could result in much better conversions for merchants.

Allow website X.com to check availability of it’s own native payment app X. If payment app X has relation with merchant Y, merchant Y could embed a secured & authenticated iframe from X.com domain, X.com iframe can then get result back from user-agent.

• Step1: Website bobpay.com calls “validate()” or “canMakePayment()”
• Step2: User agent checks if there are any native apps installed to handle bobpay.com
• Step3: If there is, user-agent resolves promise with success
• Step4: If there is no such app, user-agent resolves promise with failure

This is not ideal but if none of above solution resolves the privacy issue, user-agent can display permission prompt to user to allow sharing payment app availability data with merchants.

User-agent could provide a global level setting to users to not allow websites to check availability of payment apps. Safari on iOS follows similar paradigm.

• Please note that above proposals only address mobile checkout experience
• Assumes platform support for required communications between user-agent and payment app (like in Android OS)
• Proposal excludes “Basic Card” PMI

Note that payment apps today can achieve “validate()” or “canMakePayment()” api behavior by following below steps,

• Step 1: User has opened PaymentApp X, PaymentApp X launches browser with x.com domain
• Step 2: X.com website saves a cookie that does not expire or installs service worker along with payment app information
• Step 3: Merchant sites embed secured and authenticated x.com iframe.
• Step 4: x.com domain checks existence of the cookie/service worker and queries X.com for more details like card art or gift card information if it wishes to
• Step 5: Merchant website displays appropriate information based on x.com iframe data

So in conclusion, “Validate()”/”canMakePayment()” APIs are not introducing any new communication between merchants and payments apps that is not possible already, but it would make it more convenient for user by not having user visit payment app website and would avoid extra network calls to get basic information like card art.