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 payment apps register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged.
• 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 apps may be used to fulfill the payment method. The scope of this work extends to all types of payment apps, 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.

The Working Group will also look at enabling re-use of the Payment Request API data model in out-of-browser payments. One approach may be to define the model in a binding- and encoding-neutral way. For early work on this topic, see HTTP Messages 1.0.

Formal Adoption of Work Under Consideration

The Working Group has discussed, but not yet taken up formally, the payment method specifications on the following topics. The Working Group will decide whether these should be published on the Recommendation Track or as Working Group Notes:

• Network tokens
• Credit transfers
• Direct debits
• Interledger payments (in cooperation with the Interledger Payments Community Group)
• Distributed ledger payments
• Leveraging existing encryption mechanisms to secure payment data, in consultation with with relevant security groups in W3C and the IETF.

The Working Group will account for exception handling in the design of payment method specifications. These include, but are not limited to, authorization failures and network failures.

New Topics

The Working Group has had significant discussion about the following topics and anticipates discussion will continue:

• 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 Specification.

Working Group participants have expressed interest in the following topics new to this charter:

• Multi-tender payments
• Discount codes
• Trailing transaction (such as tips or post-checkout hotel expenses)
• Access to and validation of billing address
• Enhancements to the event model so that payment methods involving merchant validation can do so within the Payment Request API flow.
• Facilities for improved error reporting to the user
• Facilities to enable merchants to test Payment Request API in their environments
• Payment app security and filtering

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
• Developer Portal to help with adoption.

The Working Group may publish similar resources deemed important for the successful deployment of its other deliverables.

Discontinued Deliverables

The Working Group plans to discontinue work on the following specification:

• Web Payments HTTP API 1.0

Out of Scope

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

• This Working Group is chartered to Recommend programming interfaces, not user interfaces.
• 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.