The mission of the Web Payments Working Group is to make payments easier and more secure on the Web.
|Start date||21 October 2015|
|Charter extension||The charter extension history is documented in "about this charter"|
|End date||31 December 2017|
|Confidentiality||Proceedings are public|
|Initial Chairs||Nick Telford-Reed, Worldpay; Adrian Hope-Bailie, Ripple|
|Initial Team Contacts
(FTE %: 50%)
|Doug Schepers, Ian Jacobs|
|Usual Meeting Schedule||Teleconferences: Weekly
Face-to-face: 2-3 per year
Fragmentation of the payment landscape is limiting the full potential of the Web, including lack of standards in areas such as:
If successful, the Recommendations from this Working Group will increase some areas of interoperability between payer and payee systems, producing benefits such as:
For more background information about this group, please see the Web Payments Working Group Charter FAQ. For more information about Web Payments activities beyond the scope of this charter, see the Web Payments Interest Group description below.
Under this charter, the Working Group defines Recommendations that allow for a payment to be initiated within a Web application.
The Working Group will Recommend:
The Working Group will also Recommend how Web applications and digital payment instruments exchange these messages through a mediating user agent; see the deliverables section for further detail.
This Working Group is chartered to Recommend programming interfaces; not user interfaces.
This Working Group will not define a new digital payment scheme.
The Working Group will specify the following capabilities, in order to support a payment from a payer to a payee, whether a credit push (payer initiated) or a debit pull (payee initiated):
In addition to these capabilities, user agents and digital wallets are expected to fulfill a variety of roles (e.g., displaying a selection of payment instruments and enabling the user to select one) that will not be specified in the deliverables of this Working Group.
The Working Group will consider support for deferred payment execution to enable use cases where the actual execution of a payment requires steps that are out-of-band with respect to the message flows and APIs defined by the Working Group.
The Working Group will also address exceptions that may occur during these steps, including payment authorization failure, lack of available digital payment instruments, and lack of suitable digital payment instruments.
The Working Group may define APIs that will also be used outside of a user agent context, such as between Web services, or from within a native application (where the proxy between the payer's digital payment instruments and the payee's application is not a browser).
If the Working Group specifies interactions with a digital wallet, the Working Group will assure that users are able to use more than one digital wallet. The phrase "the payer's digital wallet" is shorthand for "the payer's digital wallet(s)."
The Working Group may consider the use case where an aggregation service acts as a more sophisticated digital wallet or provides a wider choice of payment solutions to the payer. For example, the aggregator service might combine the functionality of multiple digital wallets, or apply more complex algorithms to discover and collect the set of digital payment instruments available to the payer.
Recommendations for loyalty schemes and coupons, digital receipts, digital credentials, tickets, and location services are out of scope. Future W3C activities may seek to increase interoperability of these or other additional digital wallet capabilities.
Security is obviously critical in payments.
A key 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.
There are other aspects of security (e.g., authentication of payer identity) that the Working Group will leave to individual digital payment schemes. 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.
In addition, W3C might develop additional security-related specifications in other groups that may be adopted in digital payment schemes. This group will follow any such work to help ensure compatibility with the payment flows described in this charter.
Protection of the privacy of all participants in a payment is essential 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 leakage of such data through exploitation of the API.
Digital payment schemes define how various parties meet relevant regulatory obligations. The deliverables of this group should not prevent parties from meeting those obligations.
This Recommendation will define message formats for:
These messages will be exchanged by the APIs described below, but can also be used without them (e.g., for server-to-server communication).
This Recommendation will specify request and response messages for:
It will specify the delivery mechanism for these messages in at least the following scenarios:
The Working Group will fulfill the implementation experience required by the W3C Process as follows:
|Note: The group will document significant changes from this initial schedule on the group home page.|
|Web Payments Messages||March 2016||November 2016||September 2017||November 2017|
|Web Payments APIs||March 2016||November 2016||September 2017||November 2017|
A very large proportion of payments on the Web are conducted using payment cards from one of the global card schemes. The group should attempt to define a specialization of the payment flow specifically for payment cards.
A generic card payment Note could:
The Web Payments Interest Group acts as the overall coordinator at W3C of a vision for Web Payments, by gathering Web Payments Use Cases, engaging in liaisons with other payments standards bodies, and developing a high-level architecture. From time to time, the Interest Group will seek feedback from the Working Group on its evolving vision, and share information about the evolution of the Web payments technology landscape. The Web Payments Interest Group also expects to provide technical input to this and other relevant W3C Working Groups, based on a detailed analysis of the relevant Web Payments Use Cases.
This group will also collaborate with future W3C Working Groups developing authentication protocols.
In addition, for the Card Payments specification, the Working Group will need to collaborate with the administrators of existing global card schemes.
To be successful, the Web Payments Working Group is expected to have 10 active participants for its duration. Effective participation in Web Payments Working Group may consume .1 FTE for each participant; for editors this commitment may be higher.
This group primarily conducts its work on the public mailing list email@example.com (archive). Administrative tasks may be conducted in Member-only communications.
Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Payments Working Group home page.
As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When a Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
Any resolution first taken in a face-to-face meeting or teleconference (i.e., that does not follow a 7 day call for consensus on the mailing list) is to be considered provisional until 5 working days after the publication of the draft resolution. If no objections are raised on the mailing list within that time, the resolution will be considered to have consensus as a resolution of the Working Group.
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
This Working Group will use the W3C Software and Document license for all its deliverables.
This charter for the Web Payments Working Group has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Development of this charter was supported in part by the European Union's 7th Research Framework Programme (FP7/ 2013-2015) under grant agreement nº611327 - HTML5 Apps.
$Date: 2015/10/21 02:20:41 $