-
Notifications
You must be signed in to change notification settings - Fork 42
Proposal 20170130
ianbjacobs edited this page Feb 23, 2017
·
107 revisions
Hi all,
Thanks all for contributing to the recent active threads about payment apps. This proposal includes:
- A proposed way forward
- Issues where we have not yet converged (and commentary on current discussion)
- Suggested resolutions to issues (based on point 1.)
Thanks AdrianHB and Marcos for helping to shape this and to all whose comments I hope are reflected here. I look forward to discussing this as the 31 Jan meeting of the payment apps task force.
Ian
- A payment app is a Web application that manages payment requests on behalf of the user by supporting one or more payment methods.
- The task force specification adds new capabilities to the Web platform for handling payment requests. There is some support in the task force for renaming the specification to more closely reflect the features it adds to the Web platform (e.g., "Payment Handler API").
- Payment apps make use of many other Web technologies. In particular, we use service workers to connect user agents with payment apps and manage payment app lifecycle (such registration, update, invocation, and removal).
- The user must grant permission to an origin before that origin can handle payment requests for the user.
- It is not a requirement that the user agent prompt the user to grant permission to the origin for each new
supported payment method.
- A origin's capabilities may thus evolve without requiring additional user consent.
- Registration involves:
- Declaring supported payment methods
- [Optionally] identifying conditions under which the origin supports a given payment method, called "capabilities." These are compared to the merchant's capabilities as part of determining whether an origin matches. See filters below.
- Providing information that the user agent can display to facilitate user selection of payment Options; see discussion of Options below. AdamR is writing a proposal to leverage existing Web platform mechanisms and provide new mechanisms for our new needs.
- There is consensus for a fine-grained registration API.
- There is no payment app manifest file; Options are registered through the API.
- Payment method manifests may include information about payment apps; see the Payment Method Manifest Specification for details. The current discussion about payment apps should inform that proposal.
Invocation (#99)
- An origin has zero or many service worker registrations. A service worker registration has zero or one payment handler.
- A payment handler supports zero or many payment methods.
- When the user selects an Option, the user agent fires the paymentrequest event in the service worker whose registration included the payment handler that provided that Option.
- The paymentrequest event includes some information from the payment request object as well as additional information (e.g., origin and selected Option).
- On (#99) we have consensus not to reuse the request and response objects that are defined in PR API. See AdrianHB's summary.
Display of Options (#90)
- At a minimum, we expect user agents to display an icon and label for each matching origin to help the user make a selection.
- In some contexts (e.g., a desktop browser) it may be possible to improve the user experience by offering additional detail to the user. For example, if the user's "bank.com" origin knows about two credit cards (thus, two potential responses to the same payment method "basic-card"), the user agent could display each credit card's brand and the last four digits of the card to remind the user which cards the origin knows about. The user agent could furthermore enable the user to "select" one of the cards, in essence launching the payment app with knowledge about a preferred Option, eliminating a click.
- There is consensus that the specification should provide support for origins to register individual Options.
- There is also consensus not to REQUIRE the user agent to display these Options (e.g., on a mobile device it might complicate the user experience).
- We have identified several use cases where the same origin may wish to group options with more flexibility than merely "by origin". Use cases include:
- White label wallets - one origin provides wallet services for multiple vendors
- Multiple user profiles with a single provider (e.g., business wallet vs personal wallet)
- Multiple instruments held with a single provider
- We have started to use the word "wallet" to refer to a grouping of Options for display.
- There has been some discussion about whether an origin can offer "multiple payment apps." (#98)
- Yes, an origin can offer multiple wallets and multiple code bases.
- Please note, however, that permissions are granted on a per origin basis.
- It has been pointed out that parties that wish to distribute multiple payment apps may do so using different origins (e.g., business.bank.com and personal.bank.com). However, AdamR has indicated that he does not think it is realistic (or scalable) to demand that DNS be provisioned in very specific ways to satisfy partitioning.
- To enable payment app developers to build payment apps in a variety of ways, we decouple the registration (and subsequent display) of options from how the payment app responds to paymentrequest events. However, the user agent is responsible for communicating the user's selection in the event.
- JakeA made an interesting suggestion for handling Options: the user agent (e.g., on a mobile device) could first display the app-level icon/logo. Upon selection, the user agent could display the Options, essentially treating them as a submenu of the payment app.
- When a payment app needs to open a window for user interaction, this must be done in a way consistent with the payment flow, so as not to confuse the user.
- For example, there is consensus that we don't want a payment app to open in a new tab.
- There is support for defining a new openClientWindow method on the event instead of using clients.openWindow with context-sensitive advice.
- Action: Marcos and Tommy to draft a proposal for openClientWindow.
- To achieve the best user experience, we would like to take into account merchant-provided filters at the moment when the user agent is matching merchant-accepted and user-supported payment methods. One way to do this is to fire an event and allow the payment app to respond "match" or "no match". However, this would provide information to the payment app about the transaction before the user has selected the payment app (to preserve user privacy).
- At the 14 Feb 2017 task force call, there was consensus to adopt a proposal from IanJ. The task force agreed to use the proposal from AdamR regarding string set matching as a starting point. AdamR will write up the portion of the proposal that affects the payment app spec.
- See discussion of browser-based filtering.
- We have clarified that there are two use cases:
- The merchant wants to make it easy for the user to install a payment app
- The merchant wants to express a preference for ordering or otherwise highlighting preferred payment apps, if the user happens to have already registered those payment apps. (The merchant does not, by virtue of the API, know which payment apps the user has registered.) For example, the merchant may make special offers through that payment app.
- The consensus of the group seems to be that we should not address the first use case by including recommended payment apps in native browser chrome. Security issues have been raised and the case has been made that in-browser-chrome recommendations are riskier (and less expressive) than in-page recommendations. One idea for making in-page recommendations was to do so after receiving an error message via PR API that there are no available payment apps.
- We have not yet reached consensus on whether to accommodate the second use case via the API. One way to do so would be for the merchant to provide an ordered list of origins. The browser could use this information to adjust payment app order or otherwise highlight a payment app to the user as merchant-preferred.
- Marcos requested that review the privacy consideration.
- There is no longer payment app manifests or payment app identifiers, so this issue is moot.
- Permission is required by origin (as with other Web features); the spec needs to be updated accordingly.
- Where we want rely on other features of the Web platform we need to have a good understanding of implementation status. We need to learn more about how browsers that don't support features we expect to reference will behave.
- Where features of the platform we need are not yet widely deployed, we will need (at some point) to decide whether to wait for them or to design the specification so that there is a cascade of options, with a preference for the specification when it is widely supported.