馃攳
Implementing the Web Payments API - Progressive Web App Training - YouTube
Channel: Google Chrome Developers
[0]
once you master autofill how would you
[2]
like to make payments even easier hi I'm
[8]
Sara Clark and I'm ready to show you how
[10]
to use the payment tools built into iOS
[12]
and Android from your web app the
[15]
payment request API is a w3c standard to
[18]
eliminate payment forms for users and
[20]
standardized payment collections for
[21]
sites it allows us to request payment
[24]
and shipping information with a single
[26]
API call this knows how to run Apple pay
[29]
on iOS Safari and Google pay on Android
[32]
it's not limited to those to any payment
[35]
provider can write a plug-in
[36]
it's not even restricted to one browser
[39]
it's probably in the browser you're
[41]
using right now the browser simply acts
[44]
as an intermediary collecting the
[46]
information we need in a consistent way
[48]
then returns a JSON object with the
[50]
results that we can use to collect the
[52]
payment if you have used a pay with
[54]
Apple pay or pay with Google pay button
[57]
in the browser you already know what the
[59]
experience will be like
[61]
developers previously used custom
[63]
libraries to implement this such as the
[65]
Apple pay API or the Google Wallet API
[68]
and if you want to do that too
[70]
great but if you want to work with
[72]
whatever payment system the user has
[74]
payment request is your friend let's
[76]
take a quick look at the code flow and
[78]
user experience we want to buy this
[80]
jacket what happens when we tap buy now
[83]
this is an ordinary button with an
[85]
ordinary event handler first the site
[89]
creates a payment request object and
[90]
populates it with some details it
[93]
typically has the price a list of items
[95]
being purchased and the available forms
[97]
of payment this is all invisible to the
[100]
user
[100]
we need to trigger the payment user
[102]
interface you get the UI by calling
[105]
payment request dot show this displays a
[108]
native UI over the browser and returns a
[110]
promise the next few steps are all
[113]
happening inside this promise the first
[115]
screen is a summary of the information
[117]
supplied by the app tapping on an item
[119]
opens it the EPI stores addresses and
[122]
payment options securely in this example
[125]
Larry can select his shipping address
[127]
with one tap edit the address or add
[130]
another need to change the shipping
[131]
option no problem
[133]
it's just
[133]
kappa way note that changing this option
[136]
may change the total price the payment
[139]
request api can handle this with a
[141]
little help from your app notice the
[143]
multiple payment options the api also
[145]
handles country specific payment methods
[147]
and finally the user taps on pay at this
[152]
point the browser runs the selected
[153]
payment service this might be an app on
[156]
your device or going across the network
[158]
to a payment provider the completed
[161]
payment returns a special token that you
[163]
can send to your server the server has
[165]
ways of verifying this token is this
[168]
safe the api is more secure than form
[171]
based payments the new payment
[173]
instruments are based on modern
[175]
cryptography you don't need to enter
[177]
payment data that can be logged or
[178]
observed at the point of entry so to
[181]
review payment requests eliminates
[184]
manual and tedious entry by storing the
[186]
user's information securely in the
[187]
browser it works across browsers across
[190]
OS platforms and can work with any
[193]
payment service that wants to write just
[194]
a little code now that you've seen how
[197]
payment request works for the user let
[199]
me show you how to code it remember that
[201]
the payment UI contains multiple
[203]
sections we need to populate these
[205]
sections before making the request the
[207]
request needs at least three data
[209]
structures the payment options the order
[212]
details and shipping options so we'll
[215]
create those then generate a payment
[217]
request we will call show and get back a
[219]
promise that resolves when it's time to
[221]
contact the payment processor finally
[224]
notice that we may want to or three
[226]
event handlers these are called while
[228]
the UI is visible and can trigger
[230]
updates when the user changes addresses
[232]
or shipping options let's walk through
[234]
the steps in the UI and the
[236]
corresponding code first the user taps
[238]
by now so we want to set up a payment
[240]
request remember that we need some data
[242]
structures before we can create the
[244]
request the payment methods lists all
[247]
the payment services that your site
[248]
understands it's an array of payment
[251]
method objects and each method may have
[253]
its own specific properties here we're
[255]
listing the basic credit card method and
[257]
Google pay note that I'm leaving out the
[260]
details of the Google pay object as it's
[262]
pretty involved we want the user to know
[264]
what they're buying this includes the
[266]
core details of the transaction
[267]
how much money what currency and what
[269]
list items you want displayed keep the
[273]
line items fairly high level it isn't
[275]
meant to be used as an itemized receipt
[277]
if you want more than one shipping
[279]
option you can define this structure
[281]
notice it's a property on the
[283]
transaction details if you have multiple
[286]
options include a selected bit the
[289]
browser will highlight the selected
[290]
option and fire an event when it changes
[292]
now you can define what information you
[294]
want from the API by default payment
[297]
requests will only return the payment
[299]
info if the user is logged in you may
[302]
have the rest of their information if
[303]
you need more these options let you
[306]
collect what you need take the data
[308]
structures you've just created and pass
[310]
them to the payment request constructor
[312]
this should happen in response to a
[313]
button tap or other user initiated
[315]
action now so far the screen hasn't
[318]
changed
[318]
we need to trigger the UI take the
[321]
payment request and call the show method
[323]
this returns a promise and opens the
[325]
user interface notice there's a big
[328]
block of code after this we still have a
[330]
couple of steps until we're done the UI
[333]
shows the details of the purchase and
[334]
collects payment information when the
[337]
user approves the promise resolves with
[339]
a payment response object the payment
[341]
response object contains everything
[343]
needed to submit a payment for credit
[345]
card payments the response is
[347]
standardized for non credit card
[349]
payments such as Google pay the response
[352]
will be documented by the provider next
[354]
you should check that the payment is
[355]
valid send the information to your
[357]
payment processor for processing the UI
[360]
will show a spinner while the request
[362]
takes place okay so how do we remove the
[365]
payment UI after we click payment even
[369]
if it fails call payment response not
[371]
complete you can include a message to
[373]
the user this tells the browser that the
[376]
payment is complete and allows the app
[377]
to notify the user of the result now
[380]
there's one loose end to tie up what
[383]
happens if the user changes their
[384]
shipping address or options this may
[387]
change a total cost and in some cases
[389]
may change a shipping options payment
[391]
requests can omit shipping address
[393]
change shipping option change and
[395]
payment method change events you should
[398]
have event listeners for these and
[400]
update
[401]
details accordingly remember we're
[403]
making the update in the middle of a
[404]
promise just as we do installing the
[406]
Service Worker so we use a similar bit
[408]
of code we get the event and call update
[412]
with on it this takes a promise that
[414]
resolves to a new transaction details
[416]
record it's not all that different from
[419]
calling cache at all from the service
[421]
workers install event that also returns
[423]
its result via the event the get new
[426]
info method is something that you would
[427]
write it takes some data from the
[429]
request and builds a new transaction
[431]
details object here's a reminder of what
[433]
goes in the transaction details your
[435]
code probably needs to copy from the old
[437]
object to a new one we resolve the
[440]
promise with the new details
[441]
update with then updates the payment
[444]
request and the screen and that's it
[446]
you now have a seamless easy to use
[448]
checkout experience now that was a bit
[451]
of a long example but most of it is
[453]
boilerplate check out the payment
[455]
request samples at Google Chrome github
[457]
io remember the process for easier
[461]
payments starts with autofill if you
[463]
want more payment request is there to
[465]
help you can also check out specific
[468]
libraries for Apple pay Google pay
[470]
Samsung pay and others they put up a pay
[474]
with button on the screen they usually
[477]
fall back to the payment request
[478]
interface but they may be an easier
[481]
option for your users the only way to
[483]
know is to try them for yourself thanks
[486]
for hanging in there through web
[487]
payments this is one of the most complex
[489]
parts of building a PWA yet it's really
[492]
satisfying and could be great for
[493]
business take care and I'll see you
[496]
again soon
[496]
[Music]
Most Recent Videos:
You can go back to the homepage right here: Homepage