overview_revision_2018

Status: This is a scratchpad for Adrian, Nick, and Ian to take notes on a revision to the Web Payments Overview specification.

Introduction

Although the Web supports trillions of dollars of e-commerce annually, making purchases on the web, particularly from a mobile device, can be a frustrating experience. Every web site has its own flow, and most require users to manually type in the same addresses, contact information, and payment credentials again and again. This can lead to shopping cart abandonment and lost customer loyalty. Users face other types of friction as well, including very different experiences from site to site, and potentially confusing redirects from e-commerce sites to payment sites. For e-commerce site owners, it can be difficult and time-consuming to create and maintain checkout pages that support a growing number of payment methods.

To address these issues the W3C community is specifying new Web capabilities to streamline checkout and enhance security. These include:

• Enabling e-commerce sites to request stored payment credentials and related information (shipping addresses, billing addresses, and contact information) through an optimized browser-based user experience. This browser-based user experience replaces traditional checkout forms. The new browser experience allows the user to quickly access information (such as shipping addresses) stored by the browser.
• Extending the streamlined payment experience to include third party payment handlers (digital wallets). When the e-commerce site accepts a payment method and the user has a corresponding payment handler, the browser makes it easy to launch and interact with the payment handler to complete a payment. This standard hook makes it easier to bring new (and potentially more secure) payment methods to the Web.
• Increasing payment security by leveraging advances in tokenization and strong authentication.

These capabilities are enabled by a set of specifications that define new browser capabilities. The specifications as well as test suites and developer documentation play a role in ensuring that different browsers exhibit the same (or very similar) behavior.

W3C intends for these new capabilities to support a wide range of the world's payment systems. Working Group participants have focused in particular on card payments and push payments (e.g., European payment systems and regulation).

Impact on the Payments Ecosystem

In the W3C Web payments ecosystem, the browser acts as a mediator between the e-commerce site and the user's payment handlers. This means that the new standards affect in particular:

• Merchants and their payment service providers
• Payment handler (digital wallet) providers
• Browser makers

These standards mostly affect the way that these parties interact (with users) to enable merchants (and their payment service providers) collect data in a more streamlined fashion. These standards do not essentially change how payment processing happens once a merchant has collected data.

Having said that, W3C is engaging with other stakeholders in the ecosystem for security enhancements. These include:

• Strong customer authentication via the Web Authentication API
• Data protection (e.g., via credit card tokenization)

Thus, depending on the payment method, W3C also engages with:

• For debit and credit cards: card networks, token service providers, and issuing banks
• For push payments: bank and organizations that develop open banking APIs

Terminology

To help communicate the vision of the Web Payments Working Group it is useful to define some terms:

• Payer: The party that is making a payment, typically and end user on the Web.
• Payee: The party that is receiving a payment, typically a merchant or e-commerce site.
• Payment Method: A payment method is characterized by the data that the payee provides to the payer and receives from the payer in order to be paid.
• Payment Handler: A payment handler is the software that the user uses to pay. A payment handler may support one or more payment methods. Payment handlers may be implemented using a variety of technologies, including those of native operating systems or Web technologies, or a hybrid. Browsers may also act as payment handlers, storing payer credentials such as card information.
• Open payment method: A payment method for which arbitrary parties may distribute a payment handler. W3C is defining a number of open payment method specifications.
• URL-identified (or Proprietary) payment method: A payment method owned by an entity that controls the payment handler ecosystem for the payment method.
• Payment Method Manifest: Instructions from the owner of a URL-identified payment method that tell a browser which payment handlers are authorized for the payment method.

Flows

W3C's specifications focus on the user experience of making a payment, and the way that payees build checkout experiences on the Web to initiate payment. W3C's specifications do not address all aspects of the payment ecosystem.

Before a Transaction

• For most payment methods, the payer enrolls (sets up an account) with various payment service providers. This includes setting up a card account, online payment service account, bank account, distributed ledger wallet, etc. The payer then provides credentials to payment handlers and registers those payment handlers with user agent(s) that support the API.
• The payee builds a checkout experience using the W3C API instead of a Web form. Note that the payee may delegate part of the checkout experience to its service providers. Indeed, the payee may never see payment response information that is sent directly to its service providers. In the description below, we simplify by referring only to the payee. The APIs do not change how merchants and their payment service providers relate.

During a transaction

• The payer pushes the "buy button" (however it is labeled) on the payee Web site.
• The payee Web site invokes the [https://w3c.github.io/browser-payment-api/ Payment Request API], with information about accepted payment methods (such as the [https://w3c.github.io/payment-method-basic-card/ basic card payment method]) and transaction details (e.g., price, currency, items being purchased).
• The user agent (typically a browser) computes the intersection of payment methods accepted by the payee and those supported by the payer's payment handlers. The [https://w3c.github.io/payment-method-id/ Payment Method Identifiers] specification discusses payment method identifier syntax and matching.
• The user agent displays to the payer (in native browser chrome) the list of payment handlers that can be used for transaction (because they implement the intersection of payment methods). The [https://w3c.github.io/payment-handler/ Payment Handler API] specification defines how Web-based payment handlers participate in this flow.
• The payer selects one to pay.
• The user agent provides transaction details and payment method-specific data from the payee to the payment handler. The user agent then delegates control to the payment handler.
• The payer interacts with the payment handler. Payment handlers will vary greatly in the kinds of user interactions they support, for example, whether and how they support authentication, what services they offer in addition to payments, and the user experience optimizations they provide.
• When payee interaction with the payment handler completes, the payment handler communicates response data back to the user agent, including data specific to the payment method and status information.
• The payment handler is closed and returns control to the user agent.
• The user agent returns the payment handler response to the payee, completing the call to Payment Request API.

This diagram illustrates the transaction flow.

Implementation Status

Payment Request API

As of late 2017, all major browser makers are implementing Payment Request API. As of mid-2018, Payment Request API is supported in the latest versions of Chrome, Edge, Safari, and Samsung Internet Browser. In addition, a number of payment service providers offer Payment Request API to their customers, including Stripe, Braintree, and Shopify.

Below are some screen shots of the Payment Request API user experience in different platforms. The actual user experience may change over time.

Payment Handlers

As of mid-2018:

• Chrome Canary supports Web-based payment handlers through the Payment Handler API. Chrome also supports native Android payment handlers through a proprietary mechanism.
• Mozilla and Samsung have indicated they plan to support Payment Handler API
• Safari supports Apple Pay.
• Edge supports Microsoft Wallet.

Section heading ideas

• Introduction/Problem statement
• How it works
• Stakeholders
• Terminology
• Flows
• Implementation status
• Next steps / active work
• Related work (at W3C or elsewhere)
• Bibliography / Resources