WPWG FTF Feb 2016 Requirements

This purpose of this document is to help structure discussion at the February Face-to-Face meeting of the Web Payments Working Group. This document does not reflect group consensus.

The document includes a list of requirements. The group has not agreed to these requirements. In some cases, there is a set of related requirements, some of which are mutually exclusive. The goal of this exercise is to discuss the requirements at the face-to-face meeting and determine where there is consensus (or not). This is not an exhaustive list of requirements but is intended to cover some of the issues the group has been discussing.

Also note that this is not the only tool that the Working Group will use to determine a path forward. See also the flows, developer considerations, etc.

Goal:

• Requirements are the basis of testable assertions.

Web Payments Working Group participants are invited to add to this document.

Questions? Ian Jacobs <ij@w3.org>

General assumptions about user agent

• The user agent stores information securely (at least as well as it does for passwords and other sensitive user information).
• The user agent stores information in a way that is inaccessible to web content without user consent.
• How the user agent stores information securely is an implementation detail.
• The user agent can present a trustworthy UI for payment.
• User agents should distinguish themselves on the quality of the user experience.

General design goals

• Streamline the checkout experience.
• Striking a balance between giving merchants tools to improve the retail experience while empowering users to make informed choices --with enhanced usability-- for their purchase decisions. ** How will we gather data to demonstrate that the API does so?
• For the first version, keep the API to the minimum viable API to address common ecommerce transactions.
• Limit API capabilities to those that are useful independent of which payment application the user selects.

General requirements

• The API (Implementation of the API?) must not expose user-provided data without user consent (including consent to reuse information for recurring payments, etc.) ** See advice from the Privacy Interest Group ** See EU privacy-by-design ** See TAG advice on long-lived identifiers ** Is there a requirement here related to identity providers? ** ACTION: Ian to work with Wendy to get Privacy Interest Group feedback on user data protection.
• The merchant must be able to request user data.
• The user must always be able to cancel a payment request before it is carried out.
• Merchant knows how to handle response data from any accepted payment method.
• Payment apps determine the security mechanisms used to secure data outside the API.

Payment Scenarios

Requirements

• It must be possible to use the API to establish a payment obligation without a specified amount. ** E.g., flag that says "this is just an authorization" ** ACTION: Vincent to share info with the group about how ISO20022 discusses payment obligations.
• It must be possible call the API prior to knowing the final amount.
• It must be possible to register a payment instrument independent of a specific transaction.
• It should be possible to specify prices that vary based on payment method and potentially currency (Consensus 2016-02-24)
• It must be possible to specify a recurring payment via the API without providing any details about the nature of that recurring payment.
• It must be possible to specify a recurring payment via the API, where the API is how the user gives consent to the obligation details. ** E.g., a flag that says "this will be a recurring payment" ** Subscription services, donations.
• It must be possible for the user to revoke previous consent for a recurring payment.
• It must be possible to pre-authorize a payment ** E.g., use cases of hotel reservations and gas payments

Shipping Information

Assumptions

• Purchase cost for physical goods often depends on shipping information.

Requirements

• It must be possible for the merchant to specify which payment methods they accept.
• It must be possible for the user agent to offer a single user experience that includes both selection of payment app and shipping information.
• It must be possible for the user agent to offer a single user experience that includes only the selection of payment app.
• For transactions where a shipping address is required before authorizing payment, it must be possible to satisfy that constraint.
• It must be possible to update the final price based on shipping information. ** Question: Is this mandatory in Europe?
• It must be possible for the user to update the shipping information without requiring the developer to write code that updates the price.
• It must be possible to change the shipping information any number of times as part of a single user experience for a given transaction.
• It must be possible to update the shipping information before displaying price information.
• It is not a requirement that a merchant be able to use the API to capture shipping information outside of a payment. (Consensus 2016-02-23)
• It must be possible to update payment request data asynchronously (e.g., price based on shipping information). (The corollary is the UI should not be blocking.)
• The source of shipping information is out of scope for the API used to make a payment.
• It must be possible for the user to procure shipping information from other services.
• It must be possible to specify split shipping: multiple shipping addresses for transactions that involve shipping multiple items.

Note: Shipping information above is intended to be distinct from billing information.

Questions

• Does sharing shipping information with the merchant to enable calculation of the final price constitute explicit user consent?

Additional Payment Request Information

Requirements

• The API must include a standard field for an email address (for communication with the customer).
• The API must include a standard field for a telephone number associated with shipping.
• The API must include a standard field for a transaction identifier.
• Because only some payment applications require a billing address, that should not be a mandatory feature of the API.

Payment Method Identifiers

Requirements

• Every payment method identifier must be affiliated with a payment method response specification.
• It must be possible for anyone to mint a payment method identifier for any payment instrument.
• It must be possible for the Working Group to mint a payment method identifier for any payment instrument.
• It must be possible for the anyone to mint a payment method identifier for an method under their control.
• It must be possible to use a standard short string (e.g., "visa") to identify a payment method.
• For any short string used to identify a payment method, there must be a URI equivalent.
• It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.
• It is not a requirement that we maintain a registry of standard payment method identifiers outside of the specification.
• It is not a requirement that we define any standard payment method identifiers.

Version information

Assumptions

• We anticipate there will be future versions of the API.

Requirements

• The API design must enable the addition of features in future versions. (Forward-compatibility.)
• It must be possible for merchants to query a browser to determine which features the browser implements.
• The API must therefore specify clearly which features may be queried by merchants.

Questions

• How will we add new features in future version?
• What is the right mechanism for feature detection?

Payment Application Registration

Requirements

• It must be possible to register a payment instrument independent of a specific transaction.
• The API must allow the merchant to determine whether the user has registered an app associated with the origin of the merchant.
• The API must allow the merchant to determine whether the user has registered an app associated with the origin of the merchant, but only with user consent.

Questions

• Do we need to specify anything around storage of payment app info?
• How are payment apps validated at registration (to avoid spoofing, for example)?

Mediator Display

Requirements

• The user agent must present a trustworthy UI.
• It must be possible for the merchant to specify a custom display of payment app information.
• It must be possible for the merchant to provide labels for user information procured via the API.
• It must be possible for the merchant to specify a preferred order when displaying payment apps.
• It must be possible for the user to specify a preferred order when displaying payment apps.
• It must be possible for the merchant to know the displayed order of the accepted payment methods. ** Note: this does not imply the merchant knowing the subset of those methods that the user has registered, but it would still reveal information about the user's preferences.
• The user must be able set a default payment method.
• The user must be able set a default payment method per origin.

Security

• It is not a requirement that payment only be initiated with detectable user presence.

Miscellaneous Notes

• What is a payment app?
• How does the user agent communicate with different types of payment apps? (Web app, mobile native, other operating system native).