Improving Payments on the Web

Ian Jacobs, W3C 1 March 2017

Overview• The Web was not designed for payments

• Who is W3C?

• Streamlined checkout (an example)

• How we are streamlining checkout

• Topics for regulators

• More W3C activities

2

The Web Was Not Designed for Payments

3

Source: merchandisingmatters.com

Poor Experience => Abandonment

4

Source: Capital Numbers

Poor Security => Lost Loyalty; Higher Costs

5

Source: Lexis Nexis

Web Scale Improvements Require Standards

● Many standards bodies exist ● ISO, EMV, PCI, X9, IEEE, NIST, …

● Some standardization needs relate to browser behavior or integration into the browser ● Wallet access

● Tokenization ● Biometrics and other strong authentication methods ● Secure hardware

● Interfaces between Web stack, applications, underlying payment systems not generally standardized

6

The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web.

8

● Founded in 1994 by Web inventor Tim Berners-Lee

● ~440 Members; full-time staff ~75

● Community of thousands

● Liaisons to drive interoperability ● ISO TC 68, ISO 20022, IETF, …

● Hundreds of specifications (royalty-free)

Key Facts

9

● The Open Web Platform is a full-fledged programming environment for rich, interactive, cross-platform applications

● HTML5 is the cornerstone

● Most interoperable platform in history

● A billion Web sites

● Millions of developers

● Constant demand for new capabilities

W3C is Building an Open Web Platform

Now is the Time to Improve Payments on the Web

10

“We are long overdue for a payments user interface for the Web.” -- Tim Berners-Lee What if ‘One Click’ Buying Were Internetwide? New York Times, 25 September 2016

Streamlined Checkout: An Example (pay.gov)

11

Selection of payment method

12

Card Payment

13…more data required…

ACH Payment

14

…more data required…

Payment on pay.gov tomorrow

Choose passes

16

Number of passes:

Buy

Total: USD $30

Bighorn Canyon National Recreation AreaPurchase an annual park pass

1 2 3

Choose app and pay

17

Order summary1 Annual Pass for Bighorn Natl Rec Area USD $30

ShippingName, 1600 Pennsylvania Ave, …

Contactme@example.com

Card ***4231

PayPal Pay

Pay with

Make a payment to pay.gov

Browser Interface

Improved User Experience

18

● Reuse of data instead of filling out forms across the Web.

● Especially helpful on mobile.

● Consistent user experience across Web sites, devices, and operating systems.

● Potential for consistent user experience online, in-app, and in-store

● Browser display of matching methods improves chances of completion.

● User can access preferred payment app without scanning the page.

● Browsers distinguish themselves through optimized user experience (e.g., best 1-click options)

Improved Merchant & Gateway Experience

19

● Consistent and simple UX should increase conversions.

● Simpler to build and maintain user-friendly checkout.

● Cross-device interoperability at lower cost (benefit of using the Web).

● Easier adoption of payment method improvements (e.g., to improve security).

● Can support more payment methods without more complex UX and increase chances of matching user’s preferred payment method.

● Enables a branded, harmonized experience across channels through (retailer) payment apps.

How We are Streamlining Checkout

20

Source: surfingaustralia.com

Key Concepts• Merchants declare support for payment methods.

• Payment apps implement payment methods on the user’s behalf.

• The browser computes the intersection of merchant-accepted payment methods and those supported by the user’s payment apps.

• Browser shows matching payment apps; user chooses one to pay.

• When the user has completed interaction with the payment app, the payment app returns response data to the browser, which returns it to the merchant (or their PSP, depending the merchant set-up).

21

Before a Transaction

• Payment apps add support for payment methods.

• Browsers acting as simple payment apps through support for basic card payments.

• Merchants build checkout with API.

• Users install payment apps.

Transaction Flow

23

Payment Methods• The API is designed to be used with a wide array of payment methods.

• Anyone may define a payment method; many will be proprietary.

• W3C is working on three:

• Basic Card Payment

• Tokenized Card Payment

• Basic Credit Transfer Payment

• W3C’s encapsulate similar existing systems (e.g., same five fields everywhere for a basic card payment).

• Payment method data does not directly flow through payment systems; it is converted first (already the case today).

• We are seeking to align our terminology with ISO 20022, SEPA, and other standards.

24

Perspectives on Scope• We are currently addressing a small set of use cases. We look for new

standardization opportunities on an ongoing basis.

• W3C’s Payment APIs (only) address user experience and data exchange.

• The merchant (or gateway) still needs to know how to manage received data (PAN, EMV token, etc.).

• The API does not address payment processing.

• Existing rules (e.g., of schemes) still apply.

• Payment apps are responsible for the relationship between the user and the user’s payment service provider.

• W3C’s Payment APIs are part of a larger suite of Web technologies that improve Web application security, user authentication, privacy protection, etc.

25

Who’s Involved

26

Who’s Involved

Specification Status

27

• Maturing in W3C Process

• Payment Request API

• Payment Method Identifiers

• Basic Card Payment

• Not yet formally part of W3C Process

• Payment App API

• Basic Credit Transfer Payment

• Tokenized Card Payment

Implementation Status

28

• Payment Request API

• Google, Microsoft, Mozilla, Samsung, Facebook, Opera

• Expect early adopter sites in 2017

• Payment Apps

• Experimentation with payment app integration underway, including Alipay, Samsung, Google, Amex, Facebook, Worldpay, Stripe, Klarna, Gemalto, Opera, and others

• Expect some proprietary apps in 2017; Web-based to follow

Topics for Regulators• We are developing some deliverables to:

• Help regulators understand the emerging standards.

• Ensure that the standards align with regulatory expectations.

• Shed light on regulatory topics for developers who use the API to create a checkout page.

• An early draft of a flow analysis is available.

• Themes include:

• Consumer protection (security, privacy).

• Openness (of ecosystem, standards process, relationship to other standards).

29

Related PSD2 Topics

• Open Banking APIs

• Strong Authentication

30

Open Banking APIs

• W3C is not (currently) creating an open banking API.

• Payment app developer can implement open banking APIs.

• The standard should thus make it easier to deploy payment apps that support open banking APIs.

31

Strong Authentication• Strong authentication is the responsibility of the

payment app.

• W3C’s Web Authentication Working Group, with the FIDO Alliance, is creating "Web Authentication: An API for accessing Scoped Credentials"

• Offers a more secure and flexible alternative to password-based authentication

• Strong authentication work is for more than just Web payments.

32

More W3C Activities• E-Commerce: Digital offers, paid content

• Clearing and settlement: Interledger payments

• Security: Strong authentication, crypto, verifiable credentials, etc.

• Device APIs: Web NFC, Web Bluetooth

• Verticals: Auto, digital publishing, internet of things

• Even more W3C Working Groups and Community Groups

33

How to Contribute• Join W3C to drive agenda

• Next meetings: 22-24 March in Chicago

• Participate in Community Groups to incubate ideas

• Review specifications

• Regulator input using flow analysis welcome!

• Help raise awareness

34

Thank you!

• These slides:http://www.w3.org/2017/Talks/ij_ecb_20170301/w3c.pdf

• Web Payments Working Group

• Contact: Ian Jacobs <ij@w3.org>

35