[MUSIC PLAYING]
ZACH KOCH: Hey, everyone.
I like to make
dramatic entrances.
I'm Zach.
I'm a product manager
on the Chrome team,
and I spent most
of my days thinking
about how we can make
payments on the web,
particularly on the
mobile web, easier,
less painful, and
all-around better
experiences for our users.
So I'm really excited by the
Credential Management API.
Especially for someone who talks
to e-commerce people all day
long, and people who sell,
high-engagement and easy
signing is really critical.
And it's really great.
But if you think registration
forms are difficult,
we should talk about
checkout forms.
A lot more form fields,
a lot more questions.
But I think that you're going to
see a consistent theme emerging
through our talks here today,
which is this one of, let
the browser help you.
There are certain
advantages that we
have as a browser,
especially when it
comes to reducing friction and
making life easier for users.
Especially things around
repetitive data sets.
Things that the users can
store inside of the browsers.
What we're trying to do are
expose APIs, and give you
tools to reduce friction
and make things easier
for your users.
We saw that in
Credential Management,
and we'll see a very
similar theme with what
we're doing in payments.
But first, a little user
activity just before we
go off for lunch, which
are some questions.
OK, great.
So first question.
Just curious, how
many people here
actually enjoy the process
of buying something
on the web using
a mobile device?
OK, good.
Some people.
But, by-and-large, no.
And, by the way, we
should come talk.
I'd love to hear what it is that
you like about buying things
on the mobile web, and what
is that you don't as much.
Second question, and I'm going
to be really impressed here.
How many people can
remember all the details
of their credit card?
I'm talking, full
sixteen-digit number.
Really?
CVC and expiration?
I guess more than I
expected, I got to be honest.
OK, we're still like
under 15%, but, OK.
Because I've been doing
payments now for like 18 months,
and I think I have yet to
remember a credit card number.
But that's great.
And then, final
question, how many people
enjoy the process
of handing over all
of their sensitive
credit card information
to a random third-party server.
Aah, I knew it!
I got one.
It's almost like I'm asking
these questions to lead up
to a particular point.
And there is a point.
And the reality is that most
users find payment difficult.
They find it insecure, and
scary, and frightening,
and they find the
process of doing it
on the mobile web
particularly bad.
And so we have this number, we
talked about it at I/O as well,
and it hasn't really changed,
which is that, on average, we
tend to see about 66%
fewer conversions on mobile
than on desktop.
And again, we think there
is an answer to that, which
is all around, again, high
friction, the difficulty,
and issues around
trustworthiness and security.
And so we'll talk about how
we're addressing those today,
and how we're trying to bring
fast, simple, and secure
payments to the web platform.
I'm a PM, but this is little
bit too PM-ey for me, actually.
And so I have a much
better mission for us
inside of the Chrome
team, which is,
we're trying to save the world
from annoying checkout forms.
So I'm trying to save the
world from virtual keyboards,
and having to memorize, and
all of those terrible things.
I actually started this
joke of the better payments
bureau a couple of months ago.
And now it's become,
like, a thing.
But actually, Chrome
has been fighting
the good fight against annoying
checkout forms for many years,
actually.
We started with Autofill
back in the day.
You guys are probably
familiar with Autofill.
This is my one slide on it.
It's not really the topic today.
But consider this my 10-second
plea to say, if nothing else,
leave today and said
auto-complete types
on your checkout forms.
It helps us.
It helps the users.
It helps the browsers.
And it basically ensures
100% accuracy on Autofill.
But I'm not here to
talk about that today.
I'm really here to talk today
about PaymentRequest, which
is this new API that
we're building for the web
to really help solve a
lot of the problems I've
been talking about.
But before I talk about
what PaymentRequest is,
I want to talk about what
PaymentRequest isn't.
And that's because
payments is complicated.
There are a lot of
players in this space.
And I just want to sort
of set out front and help
alleviate any confusion.
So the first thing.
PaymentRequest is not
a new payment method.
We're not trying to create
Chrome pay, or browser pay,
or yet another x pay
button on your website.
That's not,
fundamentally, our goal.
Our goal is to help users pay
the way that they want to pay,
and do it quickly
and efficiently.
Secondly, we are not trying to
become a gateway, or a process,
or some entity that literally
moves money in the ecosystem.
So we're not trying
to step on any toes
here, or enter into
this ecosystem.
We think that the
market has actually done
an incredible job here already.
Players like Stripe, and
Braintree, and others
have done a really stellar job
over the last couple of years,
of taking the incredible
complexity of accepting
online payments, and
making it really simple.
They've removed the
burden of things
like acquiring banks, and
even some levels of PCI,
and they've put it all
into an easy-to-use API.
And so our goal is to
ensure that whatever
we do plays really
nicely with all
these gateways and processors,
but that's not fundamentally
our goal to become one.
The thing about all
these great new services,
though, is that
they've really focused
on developers, which is great.
They've made your lives
easier, and they made it easier
for you to accept payments.
But the user experience has
largely remained the same.
You have to go from the
state where you know nothing
to a user, to everything.
And form fields tend to be
the way that we do this.
So PaymentRequest was
fundamentally built for users.
We think it's pretty
good for developers, too,
and it's pretty easy, and
we'll talk about code samples,
but fundamentally, my
goal-- I think about users,
and how I can help them get
through these burdensome flows
on mobile faster and
more efficiently.
So what exactly
is PaymentRequest?
Well, PaymentRequest,
like I said,
is a new standards-based API.
And standards-based, I
want to emphasize that.
We joined the Web
Payments Working Group
almost a couple years ago, now.
And every major
browser's a vendor.
We have financial institutions
from around the globe,
and we're trying really
hard to build something
that everyone can integrate,
that all forms of payment
integrate with, and
all browsers can do.
So that users on a variety
of devices and ecosystems
can continue to leverage,
and have the benefit of it.
We're just in the
early stages of it,
and we'll talk about where we're
at, but that's fundamentally
our goal.
And so when we started to
think about what design
this API looked like, we had
two high-level goals in mind,
and they sort of reference back
to my original question set.
The first one is,
we wanted to build
a seamless, easy-to-use
checkout experience, on mobile
in particular.
We wanted to make
sure that users
could minimize typing
and minimize friction
as much as possible.
And the second
thing is, we really
want to bring more secure
payments into the web platform.
In many ways, the web is
one of the last places where
it's very commonplace
to exchange over
all of your
sensitive information
to some unknown third party.
And even though
there's an answer
to this from the payments
community with regard
to tokenization, the
web really didn't
have a great answer for that.
Which is why we're really
excited that we brought Android
Pay into the web
platform, and again, we'll
continue to expand that.
But this brings tokenized
forms of payment.
So in the event of data breach
or other problems, you as users
are protected, but it also
reduces the burden for you
as developers and merchants.
And so those are two
high-level goals that we had.
And again, the idea here,
just at the high level,
is that if you think of your
traditional checkout flow,
it looks something like this.
It's anywhere from,
like, two to five pages.
Maybe one for
single-page things.
And you have somewhere
between, like, 10 and 40 form
fields, where you're asking
a variety of questions.
Things like, what's your name?
What's your shipping address?
What's your email?
What's your phone number?
What's your credit card number?
What's your expiration?
And then you have
users who are trying
to do all this on their mobile
device, and at some point
they're like, meh.
They kind of give up, and
maybe they go to desktop later,
or most likely they don't.
And Darren talked a lot about
the growth of mobile, right?
And so we really think we
need to fix this and make
this easier.
And the way this happens
with PaymentRequest,
is you can imagine that
the browser plays this role
and helps facilitate checkout
across the highest friction
point.
So we take that common set
of data, those common things
that you request, and
leverage our strengths
to make it easier for
users to be successful.
So before I show
you a demo, I want
to talk about what types
of data is actually
supported by PaymentRequest.
So the first one is probably
a little bit obvious.
But it's a form of payments.
So at the end of the day, you
need a way to actually request
money from the ecosystem.
So I need some form of payments.
Right now, in Chrome,
we support two.
We support credit
cards and Android Pay.
I put et cetera on here because
the plan is to support more,
but we'll talk about
that a bit more later.
And so you always have to
request a form of payment.
You can't call PaymentRequest
and not want a form of payment.
That would just be weird.
And then it would just be,
Request Arbitrary User Data
API.
So the other big thing that
we allow you to request
is shipping address
and shipping options.
So for physical
good purchases, you
can leverage the
API to say, hey,
give me their shipping address.
And then there's a
dynamic mechanism for you
to take that address,
and then populate
shipping options that have
updated pricing, et cetera.
You can also request
a phone number,
you can request an email
address, of course,
for, like, sending a receipt,
or even prompting signup
afterwards.
And coming soon, actually,
but not quite there,
but in the next couple of
months, is payer name support.
And these are all flexible,
you can request any of these,
or none of these, if you want.
The idea is to support a broad
range of use cases out there.
So if you're like a ride
pickup service, you probably
you probably don't
need everything.
But you definitely need a
location, like an address,
and a name.
Or if you're a physical
good, you may or may not
need their payer name,
because you'll get that
from the shipping address.
So it's flexible, and you can
sort of accommodate experiences
as fits your business.
But the really
important point here
is that all of these data points
can be stored and returned
by the browser.
So users, by and large, trust
Chrome to store this data.
They trust us to store
their names, their emails,
and even their credit card data.
And so the question
is, why put users
through the burden
of a form that they
have to fill out
manually, and you
saw Sabine's slide
about fat-fingering
and the difficulty of
mobile keyboard typing.
And those problems
are multiplied
across all those form fields.
So if you can save them
the burden of doing that,
we think it's worthwhile.
And PaymentRequest requests
is really designed to do that.
But let's go ahead
and see it in action.
So I'll switch over
to a demo here.
See if we can see--
all right, excellent.
I'm going to open
up Chrome on stable,
and I'm going to use the
exact same shop API that-- Oh!
And you see it.
It auto-signed me in.
You have to love when
a good demo goes right.
But otherwise, it's the exact
same website, a Polymer shop
demo, except I'm going to go a
little bit further and actually
just make a purchase.
I hit the shop now button.
You know, I definitely don't
have enough Google hoodies
or sweatshirts, so I'll
just buy yet another one.
So standard shop, you
see that there's, like,
size and quantity.
I won't affect those.
But you see that there's
two buttons at the bottom.
There's a typical
add to cart button,
but there's also
this buy now button.
That buy now button is
based on feature detection.
So we're checking to see
if PaymentRequest exists,
and if it's there,
great, leverage it.
And if not, you would
just see an added card.
I'm going to go ahead and use
the rapid checkout approach.
And so I tap on
the buy now button.
And you see that this
payment sheet slides up
from the bottom.
This is PaymentRequest
in action.
So you're looking at
natively drawn UI.
It's controlled by us.
We go through it.
But it's populated with
data from the merchant.
So you see that my total
amount is there, $22.15.
I default to my form
of payment that I
prefer, which is Android
Pay, if it's available.
Only because it's
faster and more secure.
You see that they're also
requesting my email address
for the purpose of
sending a receipt.
And the only thing
I need to do here
is select a shipping address.
It's very difficult to ship
a sweatshirt to someone
if you don't know where it goes.
So I'll tap on that.
You'll see that the payment
sheet slides up to full screen,
and it has my addresses
automatically populated
for use.
These are our two
Google offices here.
So I'll go ahead
and shift to the one
in San Francisco, where I work.
And you see when I do that,
the shipping options are
automatically populated there.
And so we have a free
shipping in California option,
or an express shipping.
And if I change those, that will
dynamically change the price.
So you can see here that
express shipping changes.
But, of course, why
would I pay more?
I'm going to go back to zero.
That seems to make a whole
lot more sense to me.
And I'm ready to pay.
So I just have the pay
button, and then you'll
see the Android Pay
screen slide directly up.
We're running the test app,
so it says, "unrecognized."
You guys wouldn't have that.
And because I've authenticated
in the last couple of minutes,
I don't even have to do
any extra authentication
on Android Pay.
I'll literally just tap
the continue button.
A response comes back, and
the transaction and order
is successful.
So pay with Android Pay.
No keyboard, no
typing, all I had to do
was tap and select, and
confirm my shipping addresses.
So really great,
really seamless.
We're really excited about it.
[APPLAUSE]
And just to show you
that if you don't
have Android Pay
available, no big deal,
we can always change
our form of payment.
And if I didn't
have Android Pay,
I would just default
back to my credit card.
In this case, the
Visa card that I have.
Once again, I'll select my
shipping address and options.
I hit the pay, and the only
keyboard we can't get rid of
is the CVC input.
Everything else, we have.
So I'm going to do 1, 2, 3.
I used to do a live
credit card on this,
and I discovered that
didn't work well for me.
So I've switched to a demo card.
But either way, the
same concept applies.
We'll talk about what's
happening behind the scenes,
but this is all
client-side, basically.
It's all happening super
fast, and pretty great.
Anyway, we're really
excited about that.
And now, maybe we can
switch back to the slides
and talk more
about what it takes
to make this actually happen.
So how do you leverage
PaymentRequest?
Well, it's pretty simple.
There are three parts to
PaymentRequest, two of which
are required, and one of
which is completely optional.
And so we'll talk
about them in order.
The very first one
are payment methods.
So we need to know, basically,
all the ways that you can get
paid.
This could be a wide variety
of things in the future.
So it could be I accept Visa,
and MasterCard, and AMX,
and Discover, and JCB, UnionPay.
It could be, in the future,
I accept Alipay, or Ideal,
or PayPal, et cetera.
As long as people are
built into the ecosystem.
Like I said, for now,
Chrome, we just launched,
so we're starting with credit
card support and Android Pay.
And so it looks a
little bit like this.
So we basically pass in this
thing called method data.
And method data is
an array of objects,
and those objects each have
an array of supported payment
methods.
So you can see here
that the first thing I
support are credit cards.
I support the standard for Visa,
MasterCard AMX, and Discover.
That's it.
Nothing else to do, it
just says, I accept this.
In the future, coming out
in a couple of months,
we have added support
for granularity,
for things like debit
or credit or prepaid.
But for right now,
essentially, when you say Visa,
we sort of assume you
can accept all Visa,
and don't make a strong
differentiation there.
But the second one is a
little bit more interesting,
and this is Android Pay.
This is an abbreviated
version of this,
but to support
Android Pay, you see
that there's an additional key
inside of that object, which
is the data.
Data is sort of
a generic object,
and it's payment
method specific.
The reality is that different
payment methods out there
have different dependencies.
Different things that
you're going to pass
in when you instantiate
it by default.
So for Android Pay,
for example, you always
have to pass in
your merchant ID,
you have to pass in what
kind of token you would like,
either network or gateway.
We don't have a full example
here, but-- What happens then,
is when a user chooses
to pay with one
of those forms of payment,
we basically bundle it all up
and pass it on to
the payment app.
And then the payment
app uses that data,
plus things like origin
and assertions from Chrome,
to basically verify that the
payment app is the right one,
and so the payment can continue.
So it's pretty simple.
The idea here is that
you throw everything
you can at the browser for
ways that you accept payment.
So if you can accept
100 different ways
of paying around the globe, tell
us 100 different ways to pay.
Because what the
browser does, is
we find that spot in the
middle-- between the set
of ways you can get paid
and a way that a user can
pay you-- and give a user
an optimized experience
about the ones that make
the most sense for them.
So you saw, for
example, in the demo
that Android Pay and a
Visa card were available.
But let's say that we had
removed Visa as an option.
Then Visa just wouldn't
show up, because that
doesn't make any sense.
And so as you go
across the globe,
there are a wide
variety of ways to pay.
But we recommend
giving us all to them,
and then we'll find the best
experience for the user,
to optimize around their
preferences, their defaults,
and what is the
best thing for them.
The second bit of data
is also quite important.
So now that we know
how I can pay you,
we need to know how much
money you want to get paid.
This is what this looks like.
Great.
So the first thing, the
most important thing
that's required, is
this total attribute.
Three parts, basically,
or two parts, really.
The first one's a label.
So we customize this,
so if you tell us total,
we'll display total.
But this could be, like,
authorization, donation,
whatever you want.
And we have to know an amount.
An amount is composed
of a total amount
of money and an
underlying currency code.
So the underlying payment
app that we transfer to knows
what currency to charge in.
We also support display items.
So just like I showed you,
when I tapped on the total,
those line items came down
that basically told you how
the total amount was reached.
We also support this.
It's fully optional.
You can pass in if you
want, or ignore it.
We recommend it.
It's nice to give a
high-level overview
to a user about the things
that inform the total amount.
Things like the subtotal, tax,
shipping costs, et cetera.
Less of a full itemized
receipt, and more
of a high-level overview.
One important point.
PaymentRequest does not do math.
We're not good at
floating-point math.
So if you pass in-- you have
two line items that sum to five,
and your total says four, we're
not going to throw anything.
So you're totally in
control of this thing.
So just keep that in mind.
And there are, by
the way, might be
some use cases where it makes
sense for those not to align.
But by and large, I just
want to point that out.
The other point to note is that
transaction details can also
contain shipping options.
And in this case, if you put
them in there by default,
we support default
shipping options.
We only recommend you
use this if you're
highly confident that your
shipping options will not
change.
As in, they're not dynamic.
So if you support, for example,
worldwide free shipping,
and it never changes
no matter what
the address is, feel free
to default populate this.
But if your shipping is
dependent upon a user address,
then we recommend
waiting until you've
gotten a user address event,
which we can talk about
in a little bit.
And then you can use
that to dynamically query
against whatever service
you use to calculate prices,
and you can repopulate this.
And that's an important point--
that basically, the transaction
details object can be
updated and overwritten
throughout the lifecycle
of PaymentRequest
at certain events and points.
So if a user changes their
shipping option-- you saw how,
in my demo, when I changed
my shipping option,
the price change, and
the list items changed.
That's because when
that event took place,
we repopulated those set
of transaction details.
And so you have that flexibility
and control on those events.
And so that's how we
get that dynamic pricing
model that exists out there.
And so, again, don't do
default shipping options
unless you're highly confident
they are going to change.
And the final piece is
the extra information.
The optional set of options.
And that's the things
I talked about.
User address, shipping support,
name, email, and phone.
All entirely optional,
but definitely useful.
I think there is
this myth out there
that the only drop-off
point in the funnel
is the process of putting
in your credit card.
But really, the entire checkout
funnel is, well, a funnel.
And so wherever your
users experience friction,
and there's a step,
there's a drop-off.
So we highly recommend
taking advantage
of these different pieces.
And so there's a few that
we support, like I said.
And it's as simple as passing
in just a bunch of Booleans,
basically.
Do I want shipping?
Yes.
Do I want email?
Yes.
Et cetera.
And these can be variable.
So you can say, I
don't want shipping,
but I do want a name
and phone number.
Or you can say, I just
want an email address
to send a receipt
to, for example.
It's completely configurable.
And again, the idea
here is to support
a wide variety of use cases.
Something funny that is minor
that we have coming soon--
in the next couple
of months-- is
we're adding support, as well,
for a shipping type value.
It's pretty simple.
But the idea here is that, let's
say you are buying a pizza.
One does not ship
a pizza, right?
That's just weird.
We deliver pizzas.
And so it's a very
minor feature that
allows you to actually
specify shipping, delivery,
or pickup as the address type.
So we still call it
shipping address,
underlining the system.
But this way, in the UI,
a user would see, ah,
I want my pizza delivered
to 345 Spear Street.
I don't want it delivered.
Or if you're a ride sharing
service, for example,
you can say, pickup.
And it's your pickup
address, where
you're currently at or located.
And so that's the value of
that particular little thing.
Again, pretty minor,
but allows us to just
have a better user experience
underlining the whole system.
So now we just put it
together, basically.
And then we get that
whole experience
that we talked about,
or I just showed you.
So the first thing we do is,
we instantiate PaymentRequest,
and we pass in our method
data, things that we support.
We pass in the
transaction details.
Again, how much money,
what currency code,
what line items do we want?
And then our optional options.
So in the case of our
demo that I went through,
that would be request shipping,
true, and request email, true.
But again, that one's
completely optional.
You see here, I've also
added an event listener
to my shipping address change.
And we support two events in the
system, shipping address change
and shipping option change.
This is that dynamic
mechanism that
allows you to
receive the events,
parse out the new details.
So if a user selects a shipping
address, that event fires.
You can actually pull out
that full shipping address.
We don't do just the
zip code, because you
can't get fully accurate
shipping information
with just a zip code.
So you get a full user address,
you can use that at that time
to call event update with.
This basically says, hey
browser, I'm thinking.
I need to calculate this.
You can call your back-end APIs.
And you can update,
resolve a promise
with new transaction details.
So, again, that updated
transaction details
object can now contain your
updated set of shipping
options, including the
empty set of options
and an error which
says, like, sorry,
we don't ship to wherever it is
that you're trying to ship to.
So that's also supported.
And by instantiating
PaymentRequest,
there's no UI that shows.
It's just instantiation.
When you want that actual
payment sheet to slide up
from the bottom,
we call dot show.
Dot show is actually our
signal, and we actually
raise that payment sheet and put
the user through the process.
That returns back a promise,
and when that promise resolves,
you have a payment response.
And that payment response
contains the entire set
of data.
It's just a JSON object that
contains the entire set of data
that you requested.
So for a credit
card, for example,
you would know what the
underlying network was.
So Visa, MasterCard, et cetera.
And then you would see credit
card number, phone number,
full CVC, expiration, et cetera.
Think, like, the
same set of data
that a user would have
typed out into your form,
you're now getting just from
the browser as a JSON response.
You can then use that to send
that response directly off
to your gateway,
your server, or even,
let's say, in the case
of Stripe or APIs,
directly over to the
APIs for tokenization.
It's completely up to you,
because it's all plain text.
These responses, it's important
to note, are method specific.
So if you selected Android
Pay as your form of payment,
then when that
response comes back,
it's going to look like
an Android Pay response.
You're going to be able to
select if there's a key,
and it'll tell you that the
form of payment they chose
was Android Pay.
And then you have to expect
that the Android Pay details
object looks different than
a credit card one, which
may look different than
some other form of payment,
like an Alipay, et cetera.
And that's because different
payment methods have
different requirements,
are different systems,
and call things
different things.
The final step here
is, we just need
you to tell us to close the UI.
Because once you get this
payment response back,
we actually show this
little loading spinner.
And that little
loading spinner is
sort of waiting for you to
come back and let us know
the result of the transaction.
We highly encourage,
but do not require,
that at the time that
payment response comes back,
you try to make the payment.
There are legitimate
use cases where
you can't do this, things
like 3DS flows, et cetera.
But by and large, if you
can submit, we recommend it.
And so you call the complete.
You can call it with
success or failure.
But you can also
call with nothing.
This is basically an
affordance for the browser
to do a special
UI considerations
in the event of success,
like a little animated
checkmark or something.
But it's totally optional.
The important thing is
that when the UI closes,
we'll actually
resolve that promise.
And that promise is your cue
that the UI has been completely
torn down.
So if you have
animations or things
that you're trying to time
with the close of that,
wait for that
promise to resolve,
and then you'll be guaranteed
that any Chrome UI has now
been stripped from the page.
And that's it.
Armed with that, you basically
have the whole experience.
So in just a few lines
of code, you basically
help a user alleviate all
that friction and difficulty
of typing all those
annoying form fields.
Pretty simple.
But also, again, with Android
Pay and other future forms
of tokenized payment,
you're basically
getting easy, great,
tokenized forms of payment
that reduce the burden of
CVC memorization, et cetera.
So, really excited about this.
And this is all possible
because the browser
is sitting as the
middleman there,
proxying data back-and-forth
between native apps
on the device and the
underlying website
and the developer
that's requesting it.
So my last few
minutes here, I want
to talk about just a
few UX considerations
and forward-looking stuff.
So first one is my very bold,
hyperbolic statement to say,
kill the cart.
Which is maybe a bit strong.
But it's sort of
my way of saying,
if a user is coming
to your site,
or if you have a lot of
users who come to your site
on mobile that only
make a single purchase,
why put them through the
burden of opening the page,
adding it to cart,
finding the cart page,
clicking the cart page,
going to the review page,
going to the checkout page,
and then finally starting
the process?
They're on mobile.
We want to optimize
their experiences.
PaymentRequest allows you to do
that quickly and immediately.
So consider adding buy
now buttons directly
to your product pages,
especially on mobile,
when it makes sense.
Again, this movement will
make sense for all businesses,
but I would encourage you to
go back and check the numbers,
and see if like this might
be a powerful tool for you
guys to leverage
to help your users.
Just a few other
things, really quickly,
that I have talked
about and you've
heard mentioned here today, is
think progressive enhancement.
This is a new API,
it won't always
be available, you can't
necessary completely depend
on it, especially
cross browser way yet,
although hopefully
we'll get there.
So think what happens
if it's not available.
You'll still need
fallback flows, et cetera.
The second one, of
course, is we encourage
you to keep the set of
list items high-level.
So don't think of it
like an itemized receipt.
We don't want the user to
see this long scrolling
list in the UI, if possible.
Try to keep it high-level.
Subtotal, tax, things like that.
If it's a single item,
you can put it in there.
But by and large, we encourage
high-level subtotals,
and things like that.
And then, last one,
something to consider
is that if you already
have a user's information
and you already have
a credit card on file,
or some way to pay, don't think
you have to use PaymentRequest.
Give the user the
best experience
they can, and that means go
ahead and just leveraging
what you already have on file.
But if you don't have anything,
and you don't have the credit
card, or the credit card's
expired and you need a new one,
consider PaymentRequest as
a tool to help these users.
We talked about
signup first, right?
But that might not always
make sense for your business.
If you think about
it, maybe your P-zero,
or your most important
thing, is getting a user
through that checkout flow.
Then you can request an email
address from PaymentRequest,
and now all you need from them,
at the end of that funnel,
to optimize the experience
for next time is a password.
And so consider leveraging this.
Again, these are just tools
to help you be successful.
So just a quick status update.
So we are live in
Chrome as of M53.
So we've only been live for
about, say, eight weeks now.
And it's sort of a quiet launch.
We had a great set of
early launch partners
that we worked
very closely with.
And they integrated,
and tested, and gave us
a lot of great feedback.
Again, the API is still early.
Chrome is the first
browser to implement.
And so we're really thankful
to all of these players
for their great feedback.
And from it, we're actually
making a lot of changes,
and improvements,
and enhancements
to the underlining experience.
And so I just want to talk
a little bit about what
you can expect to come soon.
So the first one that we're
working really hard on
is support for
third-party payment apps.
As you go around the world,
there are a lot of ways to pay.
In India, you have Paytm, and
Snapdeal, and all these other
new emerging wallets.
If you go to Holland,
you have Ideal.
If you go into other countries,
whole new forms of payment
that are not just credit
cards and Android Pay.
And we want to be
able support all
of this in a nice open way,
where we can support users
from all over the
globe no matter what.
And so we're really
close to finalizing this,
and we hope to have
support next year.
Secondly, we have a
lot of spec and feature
enhancements coming.
So we have the shipping
address types I talked about.
You'll be able to call this
within an iframe, coming up
soon, as well as a bunch
of other small enhancements
and improvements.
We also have a bunch
of UX improvements.
So we added OCR
scanning just recently,
so you can now just-- if you
don't have a credit card,
you can just scan it
directly into the UI.
So there's things to
make it faster, easier
and fundamentally
better onboarding flows.
And then just quick timelines
here, just so you're aware.
We're targeting M56--
that's our January release--
as our next big major release.
It's going to have all
these enhancements, all
these improvements, and we're
really excited about it.
You'll continue to get
updates along the way.
This is all live
in Chrome Stable.
And we'd love to
continue to work with you
and get your feedback.
Everything I talked
about today is available
online in a lot more detail.
We have integration guides, a
bunch of examples and sample
code-- ooh, the
phone's come up--
and then we also have a "Getting
started with Android Pay."
Android Pay is really
simple with PaymentRequest.
It's less than 10 lines.
We do almost all the
heavy lifting for you.
So just a quick shout-out there.
But I'll be around for
the rest of the day.
I would love to
chat with you, learn
about your challenges,
things that you think
you need from the
browser, ways that we
can help you be successful,
especially in checkout.
So thank you so much.
Talk more.
[APPLAUSE]
[MUSIC PLAYING]
