W3C home > Mailing lists > Public > public-payments-wg@w3.org > June 2016

Re: [w3c/webpayments] Registration: How is registration information updated? (#111)

From: ianbjacobs <notifications@github.com>
Date: Wed, 22 Jun 2016 09:51:42 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>, Comment <comment@noreply.github.com>
Message-ID: <w3c/webpayments/issues/111/227806283@github.com>
@adrianhopebailie wrote:

"Perhaps the best thing to do is simply record the URL of the page the user was on when they registered the app and then when they look at a list of their installed apps in a "settings" page of the user agent they have the option to revisit that page to get updates?"

While I don't object to that, it seems to me that the responsibility for updates likes with the payment app distributor and the user. Therefore, I think that payment apps should manage prompts to (reregister to) update information.

But this points to another toipc we've not discussed much: how user's interact with their payment apps when they are not in the "checkout" experience? For native apps there is a known pattern, but for Web-based payment apps it would be clunky if people had to bookmark them, etc.

Therefore, I think that browsers should support the ability for people launch (at least Web-based) registered payment apps. This sounds close to what you are saying, but not focused only on "updates". Rather: the browser would invoke the payment app but not pass it any (payment request) information. The user could do whatever they want with the app (updates, add new payment instruments, etc.).

Does this seem reasonable? It would be another part of "payment app lifecycle", and the requirement on user agents would be to enable the user to launch a registered payment app outside of payment request API flow.

Ian


---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/111#issuecomment-227806283
Received on Wednesday, 22 June 2016 16:52:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:17 UTC