-
Notifications
You must be signed in to change notification settings - Fork 42
Proposal 20170130
ianbjacobs edited this page Mar 9, 2017
·
107 revisions
This is a running summary of key issues being discussed by the payment apps task force. Resolutions are expected to be folded into the specification before the March 2017 face-to-face meeting. See also code examples.
- 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).
Permission (#94)
- The user must grant permission to an origin before that origin can handle payment requests for the user.
- (Note from Marcos' model: Developers request permission through a "window.PaymentManager", which is then used to manage the payment method support.)
- 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)
- To handle payments, an origin has at least one and possibly 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.
- 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.
- There is consensus that the specification should provide support for origins to register individual Options.
- QUESTION: Should we require the user agent to display these Options? There has been pushback to always requiring display of options (e.g., on a mobile devices). User agents can incrementally show options. Or user agents can return an empty option ID and it becomes the payment app's job to display options to the user.
- 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 multiple 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 developers to build payment apps in a variety of ways, we decouple the registration (and subsequent display) of options from how payment handlers respond to paymentrequest events. However, the user agent is responsible for communicating the user's selection in the event.
- Users agents may wish to enable the user to select individual displayed Options, in essence launching the payment handler that registered that option. The payment handler would receive information about the selected option and could, in essence, begin to take action (thus eliminating the extra click to open the payment
app and then select the option).
- QUESTION: Should we require that, if displayed, individual Options must be selectable? Or should we allow flexibility that Options may be displayed, but selecting any one invokes all registered payment handlers?
- 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 in a submenu.
- 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 origin to respond "match" or "no match". However, this would provide information to the origin about the transaction before the user has selected the origin (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 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.
- 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.