Registration: Should we support payee knowing user has payee-controlled payment app?

[ianbjacobs]

At times merchants will want to know whether the user has the merchant's own payment app.

The payee could do something at registration time to keep track of the payment app. But during payment initiation, how can the payee learn in a privacy-protecting way that the payer has installed the app?

Or does the payee really need to know at the start of payment initiation? What if the payee sends the relevant data through the API in case the payer has the app installed. Then if the user selects the App, communications can take place out of band between payment app and payee.

Ian

[adrianhopebailie]

I believe it will be a useful feature for payee's to be able to interrogate the browser on the status of an installed app but only get a response if the app is from the same origin as the payee's website.

Example:

If a user is on xyzstore.com the code on the website can issue a call like navigator.payments.isAppRegistered("xyzstore.com") and get a true or false however if the website calls navigator.payments.isAppRegistered("example.com") this will throw an error.

[ianbjacobs]

Hi @adrianhopebailie,

As Adrian Bateman pointed out to me, your above proposal assumes origin information is associated with the app. That might happen, or it might not.

I see use cases for why the merchant would want to know:

• If the person does not have the latest app they might suggest an update
• If the person has an app of a given version, they might send different types of information.

But at least in some cases, though suboptimal, the merchant could send data through that is usable by the app, and if the user has it, it gets the data.

So I'd love to hear the use cases people have of why the merchant needs to know if the user has their app installed.

Ian

[halindrome]

Oh - that's easy. The use case is that the merchant-provided payment app knows about loyalty programs and otherwise makes the checkout process more cohesive for the end user. Also, it may know about how to use a merchant-provided charge card in such a way that it provides a discount for the consumer and reduces transaction costs for the merchant (e.g., the merchant provides a Visa-branded credit card that is also tied to a user checking account, and the merchant provided app knows to use the debit mode because it is an ACH transfer for payment and avoids the fees Visa would impose).

[burdges]

Isn't it true that, if origin information is not associated, then the app is installed in the ambient system, and not just the browser extension. In that scenario, the app should deal with updates through the system, ala apt-get, PlayStore, etc. If the app is installed in the browser itself, then the browser already supplies hooks for this. If some browsers handle this badly, like by forcing the app to leak that it's installed, then maybe one should address that directly.

We actually have another sort of scenario : If you visit an exchange/bank/mint, then it may interact with the Taler plugin to enable withdrawal operations. It'd be lovely to avoiding leaking this 1 bit of identifying information, but achieving that without the W3C's help is infinitely easier than not leaking the same bit of information to a merchant checkout page, as a bank, etc. is a much more specialized entity. We're not worried currently.

[burdges]

@halindrome It's unclear that to me a merchant provided payment app should make the the checkout browsing process more cohesive for the end user, or that they'd want to do it in that way even if they could do so. It's annoying to hop back and forth between the payment app screens top level context and store top level context. Very hard to imagine that being a good user experience.

Update : We're not even talking about the checkout process here, but earlier activities on the site. I'm maybe missing something but this sounds like a distraction from actually doing the payments.

[halindrome]

@burdges people do this now and don't seem too bothered by it. It is how all of these payment apps work. In a push payment world, the user agent would just be a conduit that relayed information, but I would still want my payment app (e.g., paypal) to have the final say about shipping address, source of funds, etc. Then paypal (as a push payer in the future) would send a token to the merchant / merchant's payment processor to send the funds, and complete the Promise in the browser environment saying "payment complete" with a transaction token.

[burdges]

@halindrome It now sounds like your talking about stuff that happens after the user has completed their shopping and selected the payment app, so not sure I grok the connection to your earlier comment.

To answer @ianbjacobs question "how can the payee learn in a privacy-protecting way that the payer has installed the app?"

They cannot, except through initiating a changeof context to the payment app itself, like when making a payment, or obeying the same origin policy. If we silently leak even 1 bit per payment app, then installing any payment apps creates a risk to the user. See : panopticlick.eff.org Just fyi, we switch to the Taler extension context during both the purchase and withdrawal operations.

[ianbjacobs]

@halindrome,

I'm not sure you've explained why the merchant needs to know before the payment is initiated. If the merchant's payment app offers loyalty services, or discounts when you use their app,
then I will learn to use that app (if I choose) when I shop with that merchant.

What do you see the merchant doing differently because they know in advance I have their app?

Ian

[adrianhopebailie]

What do you see the merchant doing differently because they know in advance I have their app?

I see this as a huge motivator for merchants to implement the API. Being able to detect that a user DOESN'T have their app installed and prompting them to install it.

Merchants could do this by initiating a payment request with only their own payment method listed in the supported methods of the request and if the browser can't find a supported payment app (and returns an error) then prompt the user to install the app before trying again.

[ianbjacobs]

@adrianhopebailie,

You wrote:

I see this as a huge motivator for merchants to implement the API. Being able to detect that a user DOESN'T have their app installed and prompting them to install it.

But merchants may always want to prompt people. If not to install it, then to use it (and to highlight, before payment initiation) "today's deals" etc. So I'm not sure that merchants would be likely to "not show anything" if the app is already installed. I agree that they MIGHT adjust presentation based on the knowledge, but I would want to understand better how they would do so.

Ian

[adrianhopebailie]

I agree that they MIGHT adjust presentation based on the knowledge, but I would want to understand better how they would do so.

👍 we need more feedback from merchants and merchant PSPs on the implementation challenges and motivations and whether this is a requirement or not. The nice thing is it can be added/removed without much change to the API spec itself wrt the payments functions.

[mattsaxon]

From a merchant/PSP perspective, I think the distinction between encouraging the installation of a payment app compared to encouraging its use is important, I'd like to be able to tailor the experience between these to for example present messages such as;

"We notice you haven't used our payment application yet, do you know you get [insert incentive here]"

or

"You've used our payment application before, but we notice you have not installed it on your [insert device here]"

compared to;

"If you install our payment application you can get [insert incentives here]"

The API will should allow merchants to tailor this experience, after all, a stated objective is to streamline the experience and this API would give information to allow that.

[burdges]

Actually @adrianhopebailie true-false navigator.payments.isAppRegistered() call approximately covers those three cases since the merchant knows if they've seen the cookies on the device before.

It's unclear to me why navigator.payments.isAppRegistered() needs a string argument, either the app is the app from that TLD or not.

[msporny]

It's unclear to me why navigator.payments.isAppRegistered() needs a string argument, either the app is the app from that TLD or not.

The TLD may have multiple payment apps depending on the type of customer. One for business customers, another for retail customers, etc.

[msporny]

Should we support payee knowing user has payee-controlled payment app?

+1 to the concept, in general.
+1 to the navigator.payments.isAppRegistered(string pmi) approach (or something like it)

[ianbjacobs]

Issue also raised in payment app issues list:
w3c/payment-handler#6