Registration: How is registration information updated?

[ianbjacobs]

The user installs a payment app, which support payment method C. The user does not register any payment instrument during registration but does so later in the payment app. How does the browser know the user now has a payment instrument? (relates to issue 110 [1]).

Similarly: what if the payment app does not support method Z at registration time, but the user
later updates the software and now the payment app does support Z. How does the browser learn about this?

Ian

[1] #110

[adrianhopebailie]

On the surface this need for apps to communicate with the browser regularly to update the set of supported methods seems complex due to SOP restrictions etc but in practice it is not really.

When a user is updating a payment app (example: adding a new payment instrument) this is most likely going to be happening during an authenticated session between the user and the app publisher.

At this time it makes sense for the app to simply make an API call to the browser to update the set of supported payment methods. Very similar process to registration of the app.

[webpayments]

But what if the payment app does not operate within a "browser". E.g., it
is a stand alone application. It won't have a obvious channel to the
"browser" to update this information.

On Wed, Mar 9, 2016 at 5:07 AM, Adrian Hope-Bailie <notifications@github.com

wrote:

On the surface this need for apps to communicate with the browser
regularly to update the set of supported methods seems complex due to SOP
restrictions etc but in practice it is not really.

When a user is updating a payment app (example: adding a new payment
instrument) this is most likely going to be happening during an
authenticated session between the user and the app publisher.

At this time it makes sense for the app to simply make an API call to the
browser to update the set of supported payment methods. Very similar
process to registration of the app.

—
Reply to this email directly or view it on GitHub
#111 (comment).

-Shane

[adrianhopebailie]

But what if the payment app does not operate within a "browser"

browser = mediator

A non-browser scenario will have to define a mechanism for apps to do this.

[ianbjacobs]

Proposed:

• There is no dynamic query mechanism for updates
• An app may reregister to provide updated information to a mediator/browser.

Ian

[rsolomakhin]

There is no dynamic query mechanism for updates.

It would be nice for user agent settings to have a button to "Refresh payment apps."

An app may reregister to provide updated information to a mediator/browser.

+1

[adrianhopebailie]

It would be nice for user agent settings to have a button to "Refresh payment apps."

This seems impractical because if the user agent is calling out to the app publisher they need to do it using an authenticated session.

I think we should leave it to app developers to figure out a way to get users to visit their webpage when an update is available so that the app publisher can invoke the API to update the app.

Bare in mind that the publisher likely has a relationship with the user so they can send them an email or message to encourage them to update the app.

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?

[ianbjacobs]

@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

[adrianhopebailie]

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.).

An easy way to do this would simply be to make an HTTP GET request to the same URL that the payment requests are submitted to via HTTP POST. It's pretty trivial for the app issuer (as a remote HTTP server or local ServiceWorker) to differentiate between the two.

[ianbjacobs]

Migrated to payment app spec repo:
w3c/payment-handler#36