W3C

[DRAFT] Web Payments Working Group Charter

Note: This draft has been superseded by the October 2015 draft charter .

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web, through incremental improvements to Web.

Start date TBD
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

@@Join the Web infrastructure that support and facilitate payments. Payments Working Group.

Goals

Fragmentation of the payment landscape is limiting the full potential of the Web, including lack of standards in areas such as:

The standards If successful, the Recommendations from this Working Group will reduce increase some areas of fragmentation, 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.

@@Join the Web Payments Working Group. End date 31 December 2017 Confidentiality Proceedings are public Initial Chairs Nick Telford-Reed, Worldpay, Co-Chairs TBD Initial Team Contacts (FTE %: 50%) Doug Schepers, Ian Jacobs Usual Meeting Schedule Teleconferences: Weekly Face-to-face: 2-3 per year Goals

Under this charter, the Working Group defines standards Recommendations that ease integration of the payments ecosystem into the Web allow for a payment to be initiated within a Web application.

Scope

The Working Group will standardize Recommend:

  1. a set of messages and that can be used to accomplish a payment,
  2. message flow flows for the initiation, confirmation, and initiation and, where scheme-permitting, confirmation or completion of a payment. Deliverables from this group will increase interoperability between payer and payee systems (for existing and future digital payment schemes ), payment, and encourage greater automation of the steps
  3. an API to allow Web applications to participate in a typical payment. By addressing message format and flow, the group leaves open the standardization of the delivery mechanism for these messages as this will vary depending on the use case and technology stack. To support use cases where messages are proxied between payer and payee using different technologies, the group will standardize delivery mechanisms for common scenarios. This flows.

The Working Group will include JavaScript APIs for the use cases where the messages are proxied between payer and payee via a also Recommend how Web browser applications and additional APIs where the digital payment instruments exchange these messages are exchanged directly over through a mediating user agent; see the Web between two online entities. deliverables section for further detail.

This group Working Group is chartered to standardize Recommend programming interfaces; not user interfaces.

This group Working Group will not define a new digital payment scheme .

Definitions

digital payment scheme
A payment scheme is a set of rules and technical standards for the execution of payment transactions that are followed by adhering entities (payment processors, payers and payees). A digital payment scheme is one payees), where transactions take place over digital networks (such as the Web). 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.
digital payment instrument
A payment instrument is an An account, token token, or other means of conducting a transaction according to a payment scheme. A digital fulfilling the payment instrument is one that is associated with provider's role in a digital payment scheme.
digital wallet
A wallet is a logical container for digital payment instruments that instruments. A digital wallet affords access to them. A digital wallet holds payment instruments, providing registration and discovery of digital payment instruments. In this charter, a digital wallet is an entity that provides these functions by fulfilling the specified APIs for registration and discovery. The entity fulfilling the APIs may be a user agent, or a user agent may ultimately locate payment instruments via other more specialized digital wallets.
Payment Flow

Required Capabilities

The scope of work supports Working Group will specify the following elements of a basic purchase triggered by payment initiation through a Web application. These standards define a high-level message flow for capabilities, in order to support a payment from a payer to payee either in the form of a payee, whether a credit push (payer initiated) or a debit pull (payee initiated) payment, and can be used to facilitate a payment from any digital payment scheme . They involve: initiated):

Pre-Payment
Negotiation of Terms
  • Payment Initiation Request , by the payee to the payer providing the terms of the payment including elements such as the accepted digital payment schemes , price, currency, recurrence, transaction type (purchase, refund, etc.), type, timeout and requests for any additional data that is required from the payee.
Negotiation of Payment Instruments
  • Discovery , by the payer, of their available digital payment instruments that can be used to make the payment. This is done by matching those registered by the payer with those supported by the payee (as defined in the Payment Initiation Request), while keeping information local to the payer.
  • Selection of a Payment Response from the digital payment instrument by instrument, which may vary according to digital payment scheme. For example, for a credit push instrument, the payer, confirmation response may include a notification or proof of the terms, and sending execution of any requested data back to the payee payment. For a debit pull instrument, the response may include the information necessary for validation. the payee to execute the payment.
Payment Processing

In addition to these capabilities, user agents and Completion Execution of the payment by either payer or payee. Delivery digital wallets are expected to fulfill a variety of roles (e.g., displaying a Payment Completion generated by selection of payment instruments and enabling the entity user to select one) that executed will not be specified in the payment. This may contain a Proof deliverables of Payment if supported by this Working Group.

The Working Group will consider support for deferred payment execution to enable use cases where the actual execution of a payment scheme. requires steps that are out-of-band with respect to this API.

The group Working Group will also address exceptions that may occur during these steps, including payment authorization failure, lack of available digital wallet service, payment instruments , and lack of suitable registered digital payment instruments .

Relation to Digital Wallets

This The Working Group intends to create a standard programming interface from the Web to a payer's digital wallet so that someone with a conforming digital wallet can seamlessly make payments with a conforming application running in a conforming user agent. Because the "digital wallet" concept means different things to different audiences this charter includes the above definition to clarify the intent of this group. This group is not developing standards for loyalty schemes and coupons, digital receipts, digital credentials, tickets, and location services. Future W3C activities may seek to increase interoperability of these or other additional digital wallet capabilities. The 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 browser is not the proxy between the payer's digital wallet payment instruments and payee application). the payee's application is not a browser).

On Multiple Digital Wallets

In If the design of these standards, Working Group specifies interactions with a digital wallet, the Working Group will not assume assure that each user has only users are able to use more than one digital wallet. In this charter, the The phrase "the payer's digital wallet" is shorthand for "the payer's digital wallet(s)" as the payer may have multiple digital wallets. wallet(s)."

The Working Group may consider the use case where an aggregation service acts as a more sophisticated digital wallet service or provides a wider choice of payment solutions to the payer. For example, the aggregator service might combine the functionality of multiple digital wallet services, 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 and Privacy Considerations

Security is obviously critical in payments.

For the APIs defined by this group, a A key consideration is the ability to prove message integrity and authentication of all message originators. This group 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 this group the Working Group will leave to the individual digital payment schemes . This group The Working Group will not define authentication standards 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 is developing might develop additional security-related specifications in other groups that may be adopted in digital payment schemes . This group will follow that any such work to help ensure compatibility with the payment flow standards 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 participants' identity or other sensitive information as part of the payment process unless required for operational purposes, by operational, 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 public facing API should guard against the unwanted leakage of such data through exploitation of the API.

Relation to Regulatory Requirements

Digital payment schemes define how various parties meet relevant regulatory obligations. The deliverables of this group should not prevent parties from meeting those obligations.

Deliverables

Web Payments APIs Messages Recommendation

Web Payments APIs This Recommendation will seek to increase interoperability for the following: define message formats for:

It These messages will include standard be exchanged by the APIs described below, but can also be used without them (e.g., for server-to-server communication).

Web Payments APIs Recommendation

This Recommendation will specify request and response messages for:

It will specify the delivery mechanism for these messages in at least the following scenarios:

Process and Planning

Preference for Community Developed Specifications

The Working Group will actively seek to base its deliverables on specifications that have been socialized in W3C Community Groups or contributed as W3C Member Submissions .

Interoperability Success Criteria

The Working Group will fulfill the implementation experience required by the W3C Process as follows:

Milestones

Note: The group will document significant changes from this initial schedule on the group home page.
Specification FPWD CR PR Rec
Web Payments Messages March 2016 November 2016 September 2017 November 2017
Web Payments APIs March 2016 November 2016 September 2017 November 2017

Optional Deliverables

Card Payments Recommendation Working Group Note

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 standardized specialization of the payment flow specifically for payment cards.

A generic card payment Recommendation Note could:

Instrument Discovery Good Practices

This charter does not include a deliverable for a standard mechanism to discover —via the payer's digital wallet— available digital payment instruments . However, the Working Group may document good practices and recommend algorithms for the discovery of payer digital payment instruments.

Test Suites The Web Payments Working Group anticipates developing test suites for Recommendation-track specifications it develops.

Dependencies and Liaisons

Web Payments Interest Group

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. The group intends to explore more eCommerce scenarios than are represented in the current Working Group charter, such as digital receipts; loyalty programs and coupons; peer-to-peer payments; and harmonization of user experience in-browser, in-app, and in-store. 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 Interest Group may also propose new Working Groups to cover topics such as identity, credentials and commerce (including invoicing, receipts, loyalty programs, coupons, discounts, and offers). 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 . Cases.

Other W3C Groups

Internationalization Core Working Group
Internationalization and localization review.
Privacy Interest Group
For privacy reviews.
Protocols and Formats Working Group (and successor)
To help ensure the protocols provide support for accessibility to people with disabilities.
Web Application Security
For security reviews. If the Working Group perceives the need for IETF review, W3C will arrange discussion through its IETF liaison.
Web Applications Working Group (and successor)
For review of JavaScript APIs.
Web Payments Community Group
Research and incubation of ideas for consideration by this group.
Web Security Interest Group
For security reviews.

This group will also collaborate with future W3C Working Groups developing authentication protocols.

Groups Outside W3C

ASC (Accredited Standards Committee) X9
Coordination with X9 will help achieve broad interoperability of payment systems (e.g., through alignment between Web protocols and ISO 12812).
EMVCo
EMVCo administers all the original specifications known as EMV, including specifications about card tokenization.
GSMA GSMA is an industry association of mobile network operators with near global coverage. IETF Consultations with the IETF Crypto Forum Research Group (CFRG) on cryptography, as well as the "IETF Security Area Advisory Group . ISO TC 68
Coordination with ISO TC 68 will help achieve broad interoperability of payment systems (e.g., through alignment between Web protocols and ISO 20022).

In addition, for the Card Payments specification, the Working Group will need to collaborate with the administrators of existing global card schemes.

Participation

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.

Communication

This group primarily conducts its work on the public mailing list public-payments-wg@w3.org (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.

Decision Policy

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.

Patent Policy

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 .

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter for the Web Payments Working Group has been created according to section 6.2 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 is was supported in part by the European Union's 7th Research Framework Programme (FP7/ 2013-2015) under grant agreement nº611327 - HTML5 Apps Apps.


Participants of the Web Payments Interest Group
See the the Editor's Draft of the charter .

$Date: 2015/10/08 18:01:18 18:00:50 $