The document provides an overview of the Payment Request API, including details on the UI, code samples, and differences from the Apple Pay for Web API. It discusses how the API aims to streamline the checkout experience for payments on the web by providing a better user experience and security compared to some existing e-commerce solutions. Implementations are in progress across Chrome and Edge browsers.

1. Payment Request API

2. Demo

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

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

6. Click the Buy button…

8. Trusted UI dialog
controlled by browser

9. Note the dialog shows the
origin/domain that
generated the dialog

10. Note also that
browser selects a
default payment method

12. Click the Edit button…

14. Choose among
other available
payment methods

15. Payment instruments shown
are the intersection of:
● those the merchant supports
● those the user has

16. Other options to
display to users…

17. Shipping address

19. Again, the browser chooses a
default shipping address, but
user can select among other
shipping addresses

20. What do you
think of that UI?

21. Criticisms?

22. Code samples

24. Two dictionaries…

25. ● “supportedInstruments”
● “details”

26. Actually…

27. ● PaymentMethodData (includes
supportedMethods field)
● PaymentDetails (includes total,
displayItems, shippingOptions)

28. What do we do with the
PaymentMethodData &
PaymentDetails?…

30. What is that code doing?

31. The code calls new PaymentRequest w/
PaymentMethodData and PaymentDetails
to construct a payment request

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

34. PaymentRequest.show()
triggers the trusted UI
and returns a Promise…

35. “instrumentResponse”

36. Actually the Promise
returned is a…

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

39. PaymentResponse.complete()
returns another Promise…

40. After that Promise returns, your
web-app code can consume
PaymentResponse.methodName &
PaymentResponse.details etc.

41. That’s it.

42. Other options in the API…

43. ● shippingOptions field for
PaymentDetails dictionary
● PaymentOptions 3rd arg
to constructor (includes
(requestShipping field)

45. What about
Apple Pay
for the Web?

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

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

48. “Apple Pay for the Web” is a non-
standard Apple-only proprietary
API…

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

50. ● canMakePayments() and
canMakePaymentsWithActiveCard()
● merchant validation

51. Merchant validation

54. Code for
merchant validation…

56. canMakePayments() and
canMakePaymentsWithActiveCard()

59. Apple Pay
code sample

61. Compare…

64. What do you think of the
Payment Request
API design?

65. Criticisms?

66. Thanks!

67. Michael[tm] Smith
W3C Deputy Director Keio SFC
mike@w3.org @sideshowbarker

68. Q&A

69. Background

70. Spec

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

72. Interface definitions

73. Two objects:
● PaymentRequest
● PaymentResponse

74. PaymentRequest object

76. Three (dictionary) args for the
PaymentRequest constructor…

77. ● PaymentMethodData
● PaymentDetails
● PaymentOptions

81. PaymentResponse object

83. Call flow

84. Somewhat out-of-date
call flow for an earlier
version of the API

86. New proposed call flow

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

89. What problem are
we trying to solve
With this API?

90. For payments on the Web:
● Make a better user experience
● Provide better security

91. Better user experience…

92. Streamline the
checkout experience…

93. Compare to an example
of bad user experience

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

96. That site is just one example
of the kind of user-hostile
horrible UX/UI that we want to
Payment Request to replace

97. Implementations

98. Already implemented in
Chrome for Android (dev)

99. Shipping targeted maybe
for Chrome 53 on Android
(stable) in “late 2016”

100. Will ship in
desktop Chrome in 2017

101. Work in progress on
being implemented
in Microsoft Edge