[Draft] Web Payments Working Group Charter

Scope

Continued Work

The Working Group will continue to advance these existing specifications to Recommendation:

• Payment Request API, which standardizes an API to allow merchants (i.e., Web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user, mediating the user experience and providing consistency between different merchants and providers.
• Payment Method Identifiers, which defines the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
• Payment Handler API, which defines capabilities that enable Web applications to handle payment requests. The specification defines how Web-based payment handlers register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged. Note: Based on experience with the Payment Handler API, the Working Group is discussing creation of a new UI component where payments, authentication, and other activities can occur. This functionality would generalize some of the current payment-specific functionality of Payment Handler API.
• Payment Method Manifest, which allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment handlers may be used to fulfill the payment method. The scope of this work extends to all types of payment handlers, including native mobile apps and Web apps.

The Working Group will continue to develop the following payment method specification, intended to become a Working Group Note:

• Basic Card Payment, which specifies request and response data for making simple card payments with Payment Request API.

Formal Adoption of Work Under Consideration

The Working Group has discussed, but not yet taken up formally, payment method specifications on the following topics:

• EMV® Secure Remote Commerce (SRC)
• The relationship of Payment Request API, Payment Handler API, Web Authentication, and the security model of the Web to the EMV® 3-D Secure - Protocol and Core Functions and EMV® Payment Tokenisation specifications.
• Credit transfers
• Direct debits

New Topics

Working Group participants have expressed interest in a number of enhancements to Payment Request 1.0. These include:

• Integration of user payment instruments previously stored by the merchant (e.g., "cards on file") into the display of options enabled through Payment Request API.
• Multi-tender payments
• Discount codes
• Trailing transaction (such as tips or post-checkout hotel expenses)
• Facilities for improved error reporting to the user
• Facilities to enable merchants to test Payment Request API in their environments

The Working Group has discussed the following payment methods but has not developed any draft specifications:

• Web Monetization

The Working Group will determine which specification type best suits each topic, for example through modifications to Payment Request API, through a payment method specification, or some other specification.

Curation of Working Group Resources

The Working Group will continue to curate the following resources it has published:

• Test suites for the above specifications. Note: To promote interoperability, all changes made to specifications should have tests.
• Registry of standardized payment methods
• Card Network Identifiers Approved for use as filters with Payment Request API

The Working Group may publish informational resources (e.g., FAQs or best practices documentation) to support the deployment of its other deliverables.

Out of Scope

The following topics are out of scope for this Working Group.

• It is in scope for the Working Group to discuss user experience, for example as part of understanding user journeys during a checkout experience. However, this Working Group is chartered to Recommend programming interfaces, not user interface specifics.
• The Working Group will not define authentication mechanisms (e.g., hardware-based solutions in securing transactions, or authenticating users via biometry or other mechanisms) but should be aware of industry developments to help ensure compatibility with the flows defined by this group. The Web Payments Working Group anticipates leveraging the deliverables of W3C's Web Authentication Working Group.
• A digital payment scheme is a set of rules for the execution of payment transactions that are followed by adhering entities (payment service providers, processors, issuers, acquirers, payers and payees), where transactions take place over networks (such as the Web). A digital payment instrument is an account, token, or other means of fulfilling the payment provider's role in a digital payment scheme. Some digital payment schemes make use internally of payment instruments from other payment schemes. How they register and communicate with internal payment instruments is beyond the scope of this charter.

Security and Privacy Considerations

A key security consideration is the ability to prove message integrity and authentication of all message originators. The Working Group will work with the organizations listed in the liaisons section of the charter to help ensure API security.

Protection of the privacy of all participants in a payment is important to maintaining the trust that payment systems are dependent upon to function. A payment process defined by this group should not disclose private details of the participants' identity or other sensitive information unless required for operational purposes, by legal or jurisdictional rules, or when deliberately consented to (e.g. as part of a loyalty program) by the owner of the information. The design of any API should guard against the unwanted or inadvertent leakage of such data through exploitation of the API.

Relation to Regulatory Requirements

The deliverables of this group should enable parties involved in a payment transaction to meet any and all regulatory obligations.