-
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. Payment apps will use many capabilities of the Web platform.
- There is some support for narrowing the title of the specification to those features it adds to the Web platform.
- For a payment app to receive payment requests, the user must grant permission to the payment app's origin.
- A payment app declares support for payment methods through service worker registration.
- We identify payment apps in at least these two contexts:
- As a recommended payment app (see below)
- Within a payment method manifest (see below)
- We don't need special identifiers to refer to the code of a payment app.
- Web features such as ordinary links and "start_url" in Web App Manifest are used to facilitate discovery of payment apps.
- The user grants permission to the origin of the payment app to handle payment requests.
- The payment app does so via event listeners registered for events defined in the payment apps spec (i.e., canHandle and paymentRequest).
- The user is not required to grant permission to the origin for handling individual payment methods.
- Thus, the payment app's capabilities may evolve without requiring additional user consent.
- To enable the app to appear as a matching app, the payment app must also have registered support for at least one payment method.
- There seems to be consensus to define fine-grain functions to get/set payment methods and filters, rather than a monolithic function to set/get all information associated with a payment app. (However, see below for open question on granularity for providing information about payment method support.)
- As with other Web applications, the origin owner provides information about the payment app.
- There are no manifest files associated with payment apps. However, 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 discussion about the Payment Method Manifest Specification.
Display of options (issue 90)
- A user may have several options available for a given payment method. For example, if a payment app supports "basic card", the user may provide information about multiple cards to the payment app.
- The Working Group is still discussing different use cases and how they might impact the level of detail of options, and how the user agent displays options to the user for selection.
- A given origin may wish to provide more than one user experience, such as a "business" service and a "personal" service for the same customer, or for a white label payment app provider to provide services to multiple users from the same origin.
- Note: The task force specification includes a payment option ID. We lose that feature if we reuse the same objects for Payment Request and Payment App. In that case, we may need an extension to the Service Worker registration and management flows for additional invocation granularity (e.g., specific to payment method). As JakeA points out this is analogous to the subscriptions API in many respects.
- 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.
- There seems to be support for payment apps providing option-level information. We have not yet decided at what level of granularity. Some use cases:
- White label wallets
- Multiple user profiles with a single provider (business vs personal)
- Multiple instruments held with a single provider
- There is also consensus that if we do support options, that user agents not be required to present this information to the user.
- User agents might provide different experiences when presenting options, including merely displaying information to inform the user, to making options active.
- It has been pointed out that on mobile it makes sense to provide less information. Currently, native payment apps integrated into Chrome for Android are not displaying option-level information, for example. Finer grain options may be more relevant for a larger-screen experience.
- AdrianHB has suggested that service worker scope could be used to build a "wallet" within a payment app. See his code example.
- Marcos has pointed out on approach where the app manages what information to display according to context.
- Action: Andre is going to write down use cases to support the discussion.
- A payment app responds to paymentRequest events.
- A payment app rely on one or more service workers. Previously we had said that "Payment apps are service workers" but that is not accurate.
- For instance, each supported payment method may be handled by a different service worker.
- See Tommy's Payment Apps and Service Workers
- QUESTION: If a payment app results in multiple service workers registering to handle payment events, what can be done to ensure a single response? Marcos' first pass answer to this question is: "first handler to .respondWith() wins"
- 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.
Setting payment method information (#95).
- There is support for fine-grain ability to set/get payment method support information.
- Action: AdamR to write a proposal for fine-grain access. The proposal will also take into account Mathieu's desire to make it easy to set the complete current state of payment method support.
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. Rouslan will write up the portion of the proposal that will affect the payment request API.
- We can point out that the Web app is responsible for providing information that can be shown to the user about the Web App. We can point to how the Web app can do so (e.g., show the example in the Web App Manifest spec that shows how to use a combination of a manifest file and link elements for backwards compatibility).
- Action: AdamR to write a proposal for providing icons and labels for different granularities.
- We have heard several use cases:
- Merchant prefers certain payment apps and wants to highlight (e.g., visually or in order) those payment apps that the user already has registered. For example, the merchant may have a special offers through that payment app. One proposal was to enable the merchant to express preferences (a list of identifiers including origins for Web-based payment apps) and thus to enable the user agent to do useful things with that information.
- Merchant prefers certain payment apps that the user has not yet registered, and the merchant would like to make it easy for the user to register those payment apps. However, security issues have been raised about merchant-supplied icons and label, expressing concerns about displaying untrusted logos/labels in native user agent UI, deemed risker than in-page display of that information.
- We need to bootstrap the payment app ecosystem (cf 7 Feb 2017 discussion).
- It has been noted that there other ways outside of PR API to support merchant recommendations, such as in-page recommendations (e.g., after receiving an error message via PR API that there are no available payment apps).
- AHB also notes that with a permissions framework, merchants can query permission state (as can code from app distributors embedded in merchant sites). This means that the merchant can also use this information to tailor recommendations to the user.
- Issue 79 is on hold while we figure out issue 74.
- Payment apps are identified by origin. Origins are responsible for providing access to code (e.g., via links to pages that run code, or using "start_url" for discovery from the origin alone).
- There is no payment app manifest.
- Having provided rationale, propose to close and allow the payment app to receive the line items.
- Permission is required by origin (as with other Web features)
- Permissions are granted by origin.
- White label payment app providers can provide service to multiple merchants using these techniques (and possibly others):
- Single payment app with logic to determine context
- Allocate a subdomain per merchant customer)
- 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.