Embed Size (px)
Citation preview
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!
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
