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.

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.
• The user agent can present a trustworthy UI for payment that is not easily spoofable.
• User agents should distinguish themselves on the quality of the user experience.

General design goals

• Create a streamlined user experience to reduce cart abandonment. This includes minimizing the number of steps a user must complete to make a payment, reducing or eliminating data entry, and so on.
• 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 independnet of which payment application the user selects.

General requirements

• The API must not expose user data without user consent.
• The user must always be able to cancel a payment request before it is carried out.

Payment Scenarios

Requirements

• It must be possible to initiate payment without specification of the final amount.
• It must be possible to register a payment instrument independent of a specific transaction.

Shipping Information

Assumptions

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

Requirements

• It must be possible for the user agent to offer a single user experience that includes both capture of payment application information and shipping information.
• It must be possible for the user agent to offer a single user experience that includes only the capture of payment application information.
• 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.
• 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 without updating the price.
• It is not a requirement that a merchant be able to use the API to capture shipping information outside of a payment.
• 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.)

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 Application Identifiers

Requirements

• It must be possible for anyone to mint a payment instrument identifier for any payment instrument.
• It must be possible for the Working Group to mint a payment instrument identifier for any payment instrument.
• It must be possible for the anyone to mint a payment instrument identifier for an instrument under their control.
• It must be possible to use a standard short string (e.g., "visa") to identify a payment instrument.
• 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 application identifiers outside of the specification.

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.

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)?

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).