[DRAFT] Web Payments Working Group Charter

Scope

The Working Group will Recommend:

1. a set of messages that can be used to accomplish a payment,
2. message flows for the initiation and, where scheme-permitting, confirmation or completion of a payment, and
3. an API to allow Web applications to participate in these flows.

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.

Definitions

digital payment scheme

A set of rules for the execution of payment transactions that are followed by adhering entities (payment processors, payers and payees), where transactions take place over 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

An account, token, or other means of fulfilling the payment provider's role in a digital payment scheme.

digital wallet

A logical container for digital payment instruments. A digital wallet affords access to digital 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.

Required Capabilities

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):

Pre-Payment

• Registration of the payer's digital payment instruments.

Negotiation of Terms

• Payment 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, 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 Request), while keeping information local to the payer.
• Payment Response from the digital payment instrument, which may vary according to digital payment scheme. For example, for a credit push instrument, the response may include a notification or proof of execution of the payment. For a debit pull instrument, the response may include the information necessary for the payee to execute the payment.

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.

Digital Wallets

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 and Privacy Considerations

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.

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.