[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 apps 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 apps handlers may be used to fulfill the payment method. The scope of this work extends to all types of payment apps, 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.

deleted text: <p> 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 <a href= "https://www.w3.org/TR/webpayments-http-messages/"> HTTP Messages 1.0 </a>. </p>

Formal Adoption of Work Under Consideration

The Working Group has discussed, but not yet taken up formally, deleted text: 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: topics:

• Network tokens </li> <li> Credit transfers </li> <li> Direct debits </li> <li> Interledger payments (in cooperation with the <a href= "https://www.w3.org/community/interledger/"> Interledger Payments Community Group </a> ) </li> <li> Distributed ledger payments </li> <li> Leveraging existing encryption mechanisms to secure payment data, in consultation with with relevant security groups in W3C and the IETF. EMV® Secure Remote Commerce (SRC)
deleted text: </ul> <p> 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. </p> <h3 id="new-topics"> New Topics </h3> <p> The Working Group has had significant discussion about the following topics and anticipates discussion will continue: </p> <ul>
• 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. and EMV® Payment Tokenisation specifications.
• Credit transfers
• Direct debits

New Topics

Working Group participants have expressed interest in the following topics new a number of enhancements to this charter: 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)
• deleted text: Access to and validation of billing address </li> <li> Enhancements to the event model so that payment methods involving merchant validation can do so within the Payment Request API flow. </li> <li> 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:

• Payment app security and filtering 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
deleted text: <li> <a href="https://github.com/w3c/payment-request-info"> Developer Portal </a> to help with adoption. </li>

The Working Group may publish similar informational resources deemed important for (e.g., FAQs or best practices documentation) to support the deleted text: successful deployment of its other deliverables.

deleted text: <h3 id="discontinued"> Discontinued Deliverables </h3> <p> The Working Group plans to discontinue work on the following specification: </p> <ul> <li> <a href="https://www.w3.org/TR/webpayments-http-api/"> Web Payments HTTP API 1.0 </a> </li> </ul>

Out of Scope

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

• This 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 interfaces. 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.