W3C Presentation -FIDO Alliance -Tokyo Seminar -Smith

Payment Request API

Demo

https://googlechrome.github.io/samples/paymentrequest/

Before looking at details of the API, let’s first look at the UI…

Click the Buy button…

Trusted UI dialog controlled by browser

Note the dialog shows the origin/domain that

generated the dialog

Note also thatbrowser selects a

default payment method

Click the Edit button…

Choose amongother available

payment methods

Payment instruments shownare the intersection of:

● those the merchant supports● those the user has

Other options todisplay to users…

Shipping address

Again, the browser chooses a default shipping address, butuser can select among other

shipping addresses

What do you think of that UI?

Criticisms?

Code samples

Two dictionaries…

● “supportedInstruments”● “details”

Actually…

● PaymentMethodData (includes supportedMethods field)

● PaymentDetails (includes total, displayItems, shippingOptions)

What do we do with the PaymentMethodData &

PaymentDetails?…

What is that code doing?

The code calls new PaymentRequest w/ PaymentMethodData and PaymentDetails

to construct a payment request

…it then calls .show() method of constructed payment request object

PaymentRequest.show() triggers the trusted UI

and returns a Promise…

“instrumentResponse”

Actually the Promise returned is a…

● PaymentResponse which includes a methodName field with the payment method the user chose, along with details

PaymentResponse.complete() returns another Promise…

After that Promise returns, your web-app code can consume

PaymentResponse.methodName & PaymentResponse.details etc.

That’s it.

Other options in the API…

● shippingOptions field for PaymentDetails dictionary

● PaymentOptions 3rd arg to constructor (includes (requestShipping field)

What about Apple Pay

for the Web?

Actually “Apple Pay for the Web” is not “for the Web”…

In fact in reality it’s just“Apple Pay for Safari”

“Apple Pay for the Web” is a non-standard Apple-only proprietary

API…

What are the differences between the Apple Pay for the Web API and the standard Payment Request API?

● canMakePayments() and canMakePaymentsWithActiveCard()

● merchant validation

Merchant validation

Code formerchant validation…

canMakePayments() and canMakePaymentsWithActiveCard()

Apple Paycode sample

Compare…

What do you think of the Payment Request

API design?

Criticisms?

Thanks!

Michael[tm] Smith

W3C Deputy Director Keio SFC

[email protected] @sideshowbarker

Q&A

Background

Spec

https://w3c.github.io/browser-payment-

api

Interface definitions

Two objects:● PaymentRequest● PaymentResponse

PaymentRequest object

Three (dictionary) args for the PaymentRequest constructor…

● PaymentMethodData● PaymentDetails● PaymentOptions

PaymentResponse object

Call flow

Somewhat out-of-datecall flow for an earlier

version of the API

New proposed call flow

In that new call flow, the“Mediator” is the Web Browser (UA)

What problem arewe trying to solve

With this API?

For payments on the Web:

● Make a better user experience● Provide better security

Better user experience…

Streamline thecheckout experience…

Compare to an example of bad user experience

That screen shot is from the ticket-buying website for a major theater chain

That site is just one exampleof the kind of user-hostile

horrible UX/UI that we want toPayment Request to replace

Implementations

Already implemented in Chrome for Android (dev)

Shipping targeted maybefor Chrome 53 on Android

(stable) in “late 2016”

Will ship indesktop Chrome in 2017

Work in progress onbeing implementedin Microsoft Edge