Web Payments WG Charter FAQ

NOTE: This FAQ has been superseded; please see the new Web Payments FAQ.

This FAQ was originally published to supplement the Web Payments Working Group Charter, developed by the Web Payments Interest Group. It is maintained in its original state for historical purposes.

Questions? public-webpayments-comments@w3.org.

What payments challenges are of interest to W3C?

Although eCommerce continues to grow and mobile payments generate much consumer and merchant interest, there are a number of challenges in the Web payments landscape, including:

1. High-profile stories of theft of sensitive user information (e.g., one study indicated a 38% increase in annual fraud costs from 2013 to 2014);
2. Incorporating security at the "data element" level to complement perimeter and point to point;
3. Availability of different authentication methods depending on the required level of security.
4. Usability challenges on mobile devices;
5. Usability challenges raised by different ecommerce experiences across sites;
6. Mobile wallet proliferation but limited user acceptance (trust & confidence?);
7. Merchant interest in loyalty coupons and other commerce tools, as well as smoother integration of payments into buying patterns that include search and social;
8. Lack of tools for Web developers to easily monetize their Web applications;
9. Fragmentation of ecommerce approaches in web pages, in-app, and in-store;

While there are a number of industry standards that help interoperability of existing payment systems, the programming interfaces between the Web stack and underlying payment systems have not generally been standardized, and there are no standard Web APIs to access digital wallets. In addition, there have been improvements in security (e.g., tokenization in card networks), but those benefits have not been integrated into the Web.

These are some of the overall challenges we perceive in the payments landscape. The Web Payments Working Group charter will only address some of these issues. W3C is also planning additional work to address other topics such as security; see the Web Payments Roadmap from the Web Payments Interest Group for more information about W3C payment activities and discussion of capabilities that will be supported in future standards.

What will be the scope of the Payments Working Group?

In many parts of the world today, a Web payment frequently starts on a payment page where the payer manually enters sensitive payment instrument details (as well as shipping address and other information necessary to complete the purchase) and submits a form to the payee. The payment data briefly passes through the Web (from the payer's user agent to the payee's server) on its way to a payment processor. At that point, much of the communication to complete a payment takes place among banks, card networks, and other parties in the payment ecosystem typically outside of the Web.

Various parties have innovated ways to simplify this flow, for example by caching digital payment instrument information in browsers, registering users on eCommerce websites to facilitate re-use of customer data and/or payment credentials, and even developing new payment methods. Unfortunately, these efforts suffer from a lack of standardization in areas such as:

• the high level flow of a Web payment;
• the programming interfaces between the various parties (such as between user agent and Web application);
• the messages exchanged between these parties over the Web.

The result is that users are led through very different flows every time they make a payment on the Web.

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web, by simplifying checkout flow. Standard APIs for messages between user agents, Web applications, digital wallets, and payment processors are expected to increase interoperability between payer and payee systems (for existing and future payment schemes) and encourage greater automation of the steps in a typical payment.

What payment flows will the standards support?

A long description of the image is available.

In this flow we anticipate that the browser will act as a proxy for requests and responses and that a digital wallet service will provide registration and discovery services for payment instruments.

Examples

Payment initiation typically would start like this:

1. Customer (payer) is on eCommerce site (payee) and selects "Pay".
2. Payee Web application sends payment request to browser via browser API.
3. Request contains payment details and lists payee-accepted digital payment schemes.
4. Browser passes request to digital wallet service which performs discovery of digital payment instruments available to make payment and either a) selects the best one OR b) suggests a set to the payer who select their preferred one. (NOTE: The discovery algorithm and wallet behavior is not standardised only the format of the request)

The flow of payment completion depends on the nature of the selected digital payment instrument. Here are some examples:

Credit Push Payment, Payment Processed Automatically

1. A push payment method (e.g., Bitcoin or iDEAL) is selected and the wallet (with user authentication if required - scheme dependent) performs any pre-payment checks the scheme specifies (e.g., funds availability)
2. The payment is processed without further intervention from the payee or payer.
3. The digital wallet, via the browser, returns the payment response to the payee.
4. Payee Web application finds scheme-specific payment proof in response or has out of band mechanism to verify payment and redirects payer to "Thank You" page.

Credit Push Payment, Payment Processing Deferred

1. The payment request includes a signal that the payment requires further payee intervention before it can be completed.
2. A push payment method (e.g., Bitcoin or iDEAL) is selected and the wallet (with user authentication if required - scheme dependent) performs any pre-payment checks the scheme specifies (e.g., funds availability)
3. The digital wallet, via the browser, returns the payment response to the payee (including the scheme-specific payment data). The response indicates that payment has not yet been completed.
4. Payee Web application requires further interactions with payer.
5. Payee (via the Web application) sends a payment completion request to the browser via a browser API requesting the payer to execute the payment.
6. Payer digital wallet receives completion request, executes payment (likely with user mediation of some form, could be various forms of secure authentication) and returns payment completion response to payee Web application.
7. Payee Web application finds scheme-specific payment proof in response or has out of band mechanism to verify payment and redirects payer to "Thank You" page.

Debit Pull Payment

1. A pull payment method (e.g., VISA credit card) is selected and the digital wallet (with user authentication if required - this is scheme dependent) performs any pre-payment checks the scheme specifies (e.g., get one-time-use card token) and packages the data required by the payee to execute the payment in a form defined by the digital payment scheme.
2. The digital wallet, via the browser, returns the payment initiation response to the payee (including the scheme-specific payment data).
3. Payee uses the credentials to execute the payment. Because the payee is now "in control of the flow," the payee can pop-up a 3DS page for the user to perform 3DS if required by their issuer. (This is likely not required if tokenisation is being used.)
4. Payee sends payment completion request to browser via browser API informing the payer that the payment has been executed.
5. Payer digital wallet receives completion request, records the outcome, and returns a completion response.
6. Payee Web application redirects payer to "Thank You" page.

Escrow Payment

1. An escrow based digital payment instrument via mutually accepted escrow service is selected and the digital wallet (with user authentication if required - scheme dependent) performs any pre-payment checks specified by the escrow service's digital payment scheme.
2. The digital wallet, via the browser, returns the payment initiation response to the payee. The payee verifies it and ensures all is in order.
3. Payee sends payment completion request to browser via browser API requesting the payer to execute the payment.
4. Payer digital wallet receives completion request, executes payment into escrow service account (likely with user mediation of some form, could be various forms of secure authentication) and returns payment completion response to payee Web application.
5. Payee Web application finds scheme-specific payment proof in response or has out of band mechanism to verify payment to escrow service and redirects user to "Thank You" page.

Note: In the case of escrow or any scheme that does not require immediate payment the flow would be the same but the seller would not release the goods yet. This flow would serve as a confirmation of terms and establishment of a reference for the transaction. All other interactions would be out of band of this flow and out of scope.

When will the Recommendation be completed?

The group will develop two Recommendations (for vocabularies and APIs) to be W3C Recommendations by November 2017.

These technologies should be in use well before they are finalized as W3C Recommendations; the W3C Process includes implementation experience requirements, so we expect to see early implementations (but not interoperability) toward the end of 2016.

Who will benefit from these standards?

There will be a number of direct and indirect benefits primarily to merchants and their customers, Web developers, and payment services providers. We also expect there to be secondary benefits for banks, mobile network operators, and other parties.

Primary beneficiaries

Customers (Payers)

• Users will have the ability to load a variety of payment instruments into a wallet (or wallets) of their choice;
• This preceding choice ultimately drives competition from vendors and service providers. It also improves the market for digital wallets;
• The payment flow that is being standardized should simplify the user experience around payments on the Web. Many steps are (or can be) automated (under user control) and can take into account user payment preferences.
• Creating user preference based standards can foster enhanced user experience.
• It should become more practical to use payment instruments that are complex to use but have very low (or zero fees) like Bitcoin to make micro-payments for on-demand services.

The standards should make it easier to enable scenarios such as the following:

• When shopping at MyFavoriteStore, the user's preferred payment instrument is selected automatically for any purchase less than a specified amount (or when other conditions apply).

Merchants (Payees)

• Standards for representing information about payment instruments accepted by the payee and available to the user will make it possible for merchants to more easily support large numbers of payment systems without jeopardizing the user's payment experience. (No "NASCAR problem");
• In turn, streamlined payment flow and improved user experience should contribute to reducing cart abandonment rates;
• Merchants can offer more secure payment methods. For example, card payment systems that use EMVco tokenization will be easier to support through standard APIs. More secure payment schemes should have lower processing fees, bringing down the costs for merchants;
• Standard APIs should make it easier to bring new payment systems to the market and automate various aspects of the payment process. This, for example, may lead to a workable micro-payments system as described in the user benefits above. When combined with the possibility of lower fees for merchants, this has the potential to open up entirely new business opportunities not currently viable;
• Possible fraud liability shift when more secure payment methods are used;

Web Developers

Checkout flows are traditionally complex and require many hours of development time to correctly implement. A single payment API will allow developers to:

• More quickly integrate purchase flows into their web applications or sites;
• Avoid building complex forms;
• Add new supported payment schemes to checkout with minimal work and overhead;

In addition:

• Developers will not have to hold on to sensitive customer data or personally identifying information if not absolutely necessary to do so.
• A variety of mechanisms will put applications outside of PCI scope, reducing PCI-related concerns.

Payment Service Providers

Payments service providers (PSPs) will be able to take advantage of these standards both in their capacity as wallet vendors and as payment processors for payees:

• Payment service providers will have standard APIs to support initial data capture.
• PSPs will have fewer hurdles to innovate around new/improved payment schemes and instruments. Schemes that support standard messages will be more easily supported by wallets and by the payment processors (that handle the payments). Standards should reduce the need to establish myriad bilateral agreements that would otherwise be necessary to drive adoption of a new payment scheme;
• Similarly, PSPs can roll out improvements to payment schemes with minimal to no disruption to merchants and users (by pushing upgrades to wallet service providers and payment processors);
• Payment gateways that provide payment processing to merchants can more easily roll out new schemes that will be immediately available to those customers who have payment instruments for that scheme. The same applies for "market-like" services like Etsy, Shopify, eBay, etc;
• Service Providers with sights on multiple jurisdictions (outside their own country) may find it easier to land new business globally;

Secondary Beneficiaries

The benefits listed below will not likely be the direct result of the Recommendations from this Working Group, but reflect longer term benefits supported once payment capabilities become an integral part of the Open Web Platform.

Banks

Historically Banks have not been early adopters of technology, but they are acutely familiar with the need for standards (ISO, ISDA, SWIFT, ACH, etc). However, recent (FinTech) advances have increased the need for banks to participate in the creation of Web payment standards. Open standards can enable banks to leverage their existing role as trusted secure account providers and deliver new payment services to account holders:

• Banks can now offer their customers a wallet (or just a payment scheme) that supports push payments directly from their customer's bank account. iDeal in the Netherlands provides a domestic example of such a standard;
• Banks can now realistically offer a compelling wallet to their customers that is useful across the Web not just in cases where the bank has bilateral agreements. Innovative wallets could even hold non-bank payment instruments;
• Standards reduce the risk/liability vis-a-vis regulators if implementing system protocols that are not proprietary;
• They should enhance the bank's ability to effectively compete with nimble FinTech companies, especially in regions such as Europe with upcoming requirements related to API access to customer accounts;
• It can accelerate the ability for global banks to penetrate new markets and be compliant with local regulators;
• It can accelerate the move to digital payments (away from paper checks, for example) and lower processing costs for banks.

Banks across the world will be ever increasingly required to comply with KYC/AML (and FATCA) rules and regulations related to payments - Web Payments Standards may enhance Banking interest by including this (?what is this?)

Mobile Network Operators

• Mobile Network Operators (MNOs) have an opportunity to compete with the banks and PSPs as both wallet providers and/or providers of a payment scheme that leverages their unique position in the value chain;
• As wallet providers, MNOs have an opportunity to differentiate themselves from the competition in terms of the value added services they can offer their customers, especially for users making Web payments via their mobile devices;

Who drafted the Web Payments Working Group Charter?

The charter was drafted by the Web Payments Interest Group; see the list of participants.

Is W3C standardizing a wallet?

No. W3C is standardizing a set of messages and the flow of these messages required to complete a payment. Digital wallets do play a role in this flow, for registration and discovery of digital payment instruments. In additional, digital wallets may implement other capabilities provided or required by these APIs.

Do these APIs assume the user will have a single digital wallet?

No.

Will the browser be a wallet?

The standards from this Working Group neither require nor preclude the browser fulfilling the roles of a digital wallet.

Will the standards support both debit push and credit pull payment schemes?

Yes. See the example flows above.

Will these APIs require payers to share the list of payment instruments they have with payees?

No.

Is the Working Group specifying user authentication mechanisms?

No. That is currently the purview of digital payment schemes. However, W3C plans to launch other Working Groups in this area.

What is the relation of this work to Secure Electronic Transaction (SET)?

SET also attempted to address some of the issues that the Web Payments Interest Group considers important. However:

• SET was only concerned with securing credit card transactions. This Working Group looks to ease integration of other payment schemes as well.
• SET depended on client certificates issued to card holders by their banks.
• SET was developed prior to common acceptance of ssl (and thus included functionality that is not directly addressed by this Working Group).
• SET rendered customer data opaque to the merchant.

What will the Web Payments Interest Group do now that there is a Working Group?

1. Further work on an architecture for Web Payments ("capabilities");
2. Further work on detailed requirements on messages, security, etc. These requirements will be provided as input to relevant groups;
3. Elaboration of the next set of priorities for standardization on topics such as identity and credentials, security, clearing and settlement, loyalty schemes, and coupons;
4. Coordination role of payments conversations at W3C;
5. Liaison role with other organizations developing payment standards;
6. Proactively seek and attract more Financial Services participation in W3C activities;