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

I usually abstain from the Payment Apps discussion since I'm not taking an active role in driving it, but say my name three times and like a titular movie ghost I will be summoned. Anyway, if it will help you reach consensus here's how Apple Pay discovery in Safari currently works.

In Apple Pay today, we have two functions. One is `canMakePayments()`. This is analogous to a hardware check - does the user have hardware capable of using the feature. In many cases you could figure this out already from the user agent. Anybody can call this method.

The second, more complex function, is `canMakePaymentsWithActiveCards`. This tells you that the user both has capable hardware and an active payment instrument on that device. What it *doesn't* tell you is anything about that instrument other than it exists - indeed, it's possible that this function returns true but the user still be unable to make the payment on your site (perhaps, for instance, your site doesn't take American Express, but that's the only instrument the user has on their device).

So when @adamroach says...

> these Apple Pay methods are very limited, and effectively provide the application hints (not promises) about whether there is some kind of payment instrument registered.

...he's correct, and that's by design to protect the privacy of the user. Indeed, the user may have chosen to turn this discovery off in Safari entirely in which case it will always simply return true.

But as @marcoscaceres suggests and our documentation confirms:

> This method asynchronously contacts the Apple Pay servers as part of the verification process. You can only call this method if you want to default to Apple Pay during your checkout flow, or if you want to add Apple Pay buttons to your product detail page.

We perform some checks that the domain is currently validated for Apple Pay (for security merchants who take Apple Pay must prove ownership of their domain), and to make sure site owners aren't mis-using or abusing the API. So yes, it's an asynchronous call (it actually returns a promise)[1].

Like I said at the start, I'm going to abstain from any kind of recommendation, but I will say that it's a very real case that some payment apps will need to perform asynchronous work to establish whether they're available or not. Sometimes that might be for security - like Apple Pay - other times, though, it might not even be a network request, it might be something like talking to a connected piece of hardware.


[1]: For those interested you can see what's actually going on between these two calls here:  https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/applepay/ApplePaySession.cpp#L472

-- 
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-277902934