-
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 renaming the specification to more closely reflect the features it adds to the Web platform.
- 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 the payment app's origin before that origin can handle payment requests for the user.
- The user is not required to grant permission to the origin for handling individual payment methods.
- A payment app's capabilities may thus evolve without requiring additional user consent.
- Payment app registration involves:
- Declaring supported payment methods
- [Optionally] identifying conditions under which the payment app supports a given payment method, called "capabilities." These are compared to the merchant's capabilities as part of determining whether a payment app matches. See filters below.
- Providing information that the user agent can display to facilitate user selection of the payment app; 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.
- A payment app registers event listeners for the paymentrequest event, which is fired when the user selects the payment app.;
Display of Options (issue 90)
- At a minimum, we expect user agents to display an icon and label for each matching payment app to help the user select one to pay.
- 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" payment app 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 payment app 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 payment apps to register 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.
Information provided to the payment app (#99)
- Marcos has made the case that we should reuse the payment request and response objects that are defined in PR API, stripping out information specific to payment methods that are not supported by the payment app. However, JakeA indicated that a new payment app request object might make more sense.
- AdamR points out that this question also relates to the issue of who collects billing information.
- See AdrianHB's summary, which suggests that if PR API remains as it is, we adopt new objects for payment app input and output data rather than reuse Payment Request objects. See Marcos' willingness to go with this and request to collaborate on writing code to illustrate it all.
- 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.