WWDC2016 Session 703

Transcript

[ Music ]
[ Applause And Cheering ]
>> Hello everybody.
Welcome back, if you came to
last year's Apple Pay session.
My name is Nick.
I'm here today with
my colleague Anders.
And we are going to talk
about a brand-new feature,
Apple Pay on the web.
But first, I want to
ask you a question.
How many of you, and put your
hands up, or yell at your screen
if you are watching
downstairs or online,
how many of you have tried to
buy something online but given
up because the checkout
was just too confusing?
I'm seeing a lot of hands.
That's true isn't it?
It's a big problem.
Here's a site I went
to yesterday,
completely legitimate.
Ignore the name, Honest
Bob; he's a great guy.
But his checkout was
a little confusing.
And so I typed in my name, which
in this example has been changed
to protect the innocent,
to Johnny Appleseed.
And I typed in my
account number.
And I got this confusing error.
It said the card number needed
to be a series of numbers.
So I thought, "Well,
I guess it didn't
like the fact I had some spaces
there even though that's how it
was written on my card.
So I changed it.
And then I got this other error.
So apparently the
month's not entered,
which wasn't even the month
I'd chosen; didn't exist.
This is very confusing.
Now hopefully the checkouts
you've seen aren't quite
as bad as this.
But Internet checkouts,
they are pretty poor.
And we think we can solve that.
We think we can solve
it with Apple Pay.
And we are going to talk today
about how we can solve
the problem of checkouts
about how we can solve
the problem of checkouts
on the web using
the great interface
and the great benefits
of Apple Pay.
We have got a lot to
cover, so we are going
to start off with
an introduction.
We are going to run through some
of the things about Apple Pay,
if you are not familiar with
it, and what it can do for you.
Then we are going to talk
about the actual API,
the new API that we've added
into Safari, the JavaScript API.
And then we'll move on
to payment processing,
how you can actually get paid.
And finally we'll look at
designing for Apple Pay,
how to make your sites
really shine and really work
and have a great
Apple Pay experience.
So let's get started.
What is Apple Pay?
Hopefully most of you are
familiar with Apple Pay.
It's an easy, secure,
and private way to pay.
And you can pay both
in-store and you can pay
within iOS applications.
Maybe you've tried that.
If you haven't, give it a go.
There are some great apps
like Lyft or Uber or DoorDash
There are some great apps
like Lyft or Uber or DoorDash
that you can use while you
are here at the conference.
And Apple Pay within apps
enables best-in-class
eCommerce experiences.
They are apps that really shine.
And thousands of applications
have adopted Apple Pay today
across the world, in China,
in the UK, in America.
And these apps are
seeing great results.
They are seeing higher
conversion rates.
Users who pay with Apple
Pay are more likely
to convert to paying customers.
And they are also seeing
increased engagement.
These users aren't
just buying things;
they are spending more
time in these applications.
And finally, users are happier.
Apple Pay has one of the highest
customer satisfaction rates
of any payment method ever.
It's so easy to use,
and users love it.
And that's great
in applications.
But I think there is
something missing.
But I think there is
something missing.
A large amount of
eCommerce happens outside
of the app ecosystem.
Apps are great.
I love apps.
But many of us still pay
for things through the web.
Most payment on the
web is pretty slow.
It's laborious.
And it's unclear.
The checkout flow is different
for every single
merchant, every single site.
It's different.
And so we are going
to solve that today.
And we are going to solve
it by bringing Apple Pay
to more places and
to more people.
And we call that
Apple Pay Everywhere,
because there's three main
places we are bringing it to.
One of them is WatchKit.
You may have seen this
in the keynote yesterday;
and Kevin talked about how
we are bringing Apple Pay
to WatchKit apps.
And we are also bringing it to
all of the great new extensions
that you saw: SiriKit,
maps, and message apps.
But perhaps the biggest
place we are bringing it to,
and the reason you are here
today, is the web and Safari.
and the reason you are here
today, is the web and Safari.
We are going to talk about
WatchKit and extensions
in the session right after this.
So if you like the sound of
my voice, don't go anywhere.
But for now let's focus
on Safari, and let's focus
on Apple Pay on the web.
I have already talked to you
about how eCommerce
today is pretty bad.
Large amounts of retail
happen on the web.
But these checkouts are
lengthy, they are complicated,
and they are hard to use.
And that's doubly
true on mobile.
The screens are smaller, but
the checkouts are still just
as complicated.
Users also want the same
experience that they get
from apps, the same ease of use,
the same security,
the same privacy.
How many of you have
had to get a new card
because you got an
e-mail telling you
that some site you shopped at
three years ago was hacked?
I know I have.
And so Apple Pay solves that.
And Apple Pay on
the web is available
on any Apple Pay device today.
That's iPhone and iPad.
And it's available on Safari
and on SafariViewController.
It's the same Apple Pay
experience but on the web,
the exact UI, the
exact experience.
If you are familiar
with Apple Pay in app,
you'll be right at home.
But there is something
missing there,
and that's on the desktop.
Now in some countries
like China,
mobile eCommerce is the
majority of eCommerce.
But here in the U.S., the
majority of people still pay
for things on their desktop.
You have probably bought
your WWDC ticket on your Mac.
And we think Apple Pay should
be available wherever you are.
And so we are also bringing
Apple Pay to Mac OS Sierra.
Now you can pay directly
from your Mac,
but with the same security
you get from Apple Pay
on your iPhone and
on your Apple Watch.
You can simply tap through
continuity to authorize.
You can simply tap through
continuity to authorize.
It's really easy to use, and
it's really straightforward.
It's available on any
Handoff-enabled Mac
that can run Mac OS Sierra.
So that's pretty much every Mac
sold for the past four years.
It's fully supported in Safari.
And you authorize the
payment on your iPhone
or on your Apple Watch.
Now because Apple Pay
on Mac OS is so quick,
you might have missed the
demo that we gave yesterday.
So I am going to
give you another one.
Don't worry.
It's very quick.
Let me switch over here.
So I have got, on
the left, a website,
and on the right
I've got an iPhone.
Now Craig booked a few
tickets for an off-site to see
"Finding Dory" on Thursday.
I am going to crash
it, actually Friday.
I am going to crash that.
We are going to join him.
I am going to take 10 of my
engineers, my colleagues, over.
Yeah, we'll go say hi to Craig.
OK. I clicked the buy
with Apple Pay button,
OK. I clicked the buy
with Apple Pay button,
and that's what happened
instantly.
Let's do that again.
I'm going to cancel it.
And you'll see when I
cancel, it cancels this
from the phone as well.
So I' m going to tap
buy with Apple Pay.
It's immediate.
It came up straightaway.
And then I just Touch
ID on the phone.
And we're done.
We paid in seconds.
It was instant between
these two devices.
And I get a notification telling
me about the payment I've made.
That's how easy and quick
Apple Pay is to use on Mac OS.
It's blindingly fast.
So hopefully I have sold you
on how great Apple Pay is.
Let's talk a bit about
actually integrating it.
Now before we dive into the
web API, I just want to run
over a few basics of Apple Pay
because perhaps you
haven't integrated it
into your application.
Perhaps you are solely
a web developer.
So Apple Pay provides you
with a unique payment token.
So Apple Pay provides you
with a unique payment token.
And you send this token to your
payment processor, like Stripe
or Braintree, or
Chase Paymentech.
Now this token is unique
to that transaction.
It can only be used one time,
and for the amount
that you asked for.
But when you use Apple Pay
in an app or on a website,
it's also unique to
you, the merchant.
It's encrypted.
So even if the token
was compromised somehow,
if the connection the user is
on was an unsecured
WiFi connection,
the token is still
completely safe
because it's encrypted
using a merchant certificate
and a merchant identifier.
Now the merchant identifier
and certificate identify
you as a merchant.
They look like this, like
standard reverse DNS strings.
If you are an iOS developer,
you'll be familiar
with that format.
And they're generated
at our developer portal.
And because they
are unique to you,
and because only you can
decrypt these tokens,
only you can read your
customer's Apple Pay tokens.
Now let's see how
that flow works
in an actual application today.
So in an iOS app, Apple
Pay starts with the Buy
with Apple Pay button.
Now when the Buy with Apple
Pay button is pressed,
iOS authorizes the payment.
It displays the Apple Pay sheet.
And the user Touch IDs
or uses their passcode.
And so payment data is generated
from the secure elements chip
on the phone; that's the
unique Apple Pay chip
that securely holds
your card data.
Now what happens next
when you're paying
in an app is this data is sent
to our servers, where it goes
through a process
that we call Rewrap.
And that's when it's reencrypted
to you as a merchant.
This happens behind the scenes.
And so when your
app gets a callback,
it just receives
this reencrypted,
rewrapped payment data
that you can then forward
to your merchant or your
payment processor's server
and then just dismiss the sheet
once that charge has been made.
Now the flow is very
similar on the web.
There's a couple of differences
around how we actually validate
merchants, because in iOS
when you have an app, it's
an app on the App Store.
It's a signed binary.
Before we go into
that, let me just run
through a few requirements
for Apple Pay.
Apple Pay on the
web is available
to any website that
wants to use it.
But you have to have an
Apple developer account,
and your site has to
be served over HTTPS.
Finally, your site has to comply
with the Apple Pay guidelines.
Now these are very
straightforward guidelines.
Most payment processors have
similar ones about the types
of goods you can
and cannot sell.
Now some eCommerce platforms
will actually support Apple Pay
on your behalf.
We'll talk about the exact
eCommerce platforms we are
partnering with in the next
section on payment processing.
partnering with in the next
section on payment processing.
But if you are partnered with
those eCommerce platforms,
you won't actually need to
have a developer account;
it can be taken care of for you.
So assuming your site
is compliant with all
of these requirements, the
first step to using Apple Pay is
to register your site.
Registering your
site is really easy.
You just create a merchant
identifier and certificate
at the developer portal.
And then you register
your domain and link it
to this merchant identifier.
This is the fully qualified
domain so for example,
store.apple.com, that you want
the actual payment to happen on.
Now when you register
your domain,
we'll go off and validate it.
And you'll also obtain
a certificate back,
a TLS certificate that we issue.
And we call this the
Session certificate.
So I just want to recap.
We have got three
pieces of information
from registering for Apple Pay.
We have got our merchant
identifier
and our merchant certificate.
They identify us as a merchant.
And then we have the Apple
Pay Session certificate,
which identifies our domain.
And when you register
on the portal,
it's very easy, very
straightforward.
It should be enabled right now.
It looks something like this.
And just add a domain.
We validate it by checking
the presence of a file
that we ask you to
place on that domain.
And you're done.
So let's look at how
this fits into our flow.
Let's look at the Apple
Pay on the web flow.
Now just like Apple Pay within
an app, the process starts
when you press or tap the
Buy with Apple Pay button.
Now there's a key
difference on the web.
You create the payment
request; that's the object
that tells us what
you want to charge.
And then something
extra happens.
This is a piece of validation.
You create a merchant session.
And this is requested from
your web server to Apple.
It's returned back to
you, and you forward it
on with your payment request.
That's the only difference.
That's the only difference
in the flow between Apple Pay
within an app and
Apple Pay on the web --
this merchant validation piece.
Let's focus a little more
on this merchant validation.
Let's talk about why we do it.
So I mentioned just a moment ago
that the web is a
little different to apps.
In an iOS app, security of
various features like Apple Pay
or Location is protected
with signed entitlements.
If you are not familiar
with those, these are pieces
of information that
are digitally signed
into your binary
in the App Store.
And this protects both
users and developers and,
in the case of Apple
Pay, merchants.
Now obviously on the web
we don't have an app store,
and we don't have
the entitlements.
So instead we have this
merchant validation process.
It protects both your users, and
it protects you as merchants.
If your site is compromised, for
example, you have an easy way
If your site is compromised, for
example, you have an easy way
to stop Apple Pay
from being used there.
Merchant validation
is really simple
and really straightforward.
It's not that tricky.
You take an Apple
Pay server URL,
and this URL is provided
from Safari.
You send this URL
to your web server,
which then requests
the merchant session.
Now to request the merchant
session you simply provide the
TLS certificate that we
generated for that domain.
It's a challenge response.
And if that certificate
looks good, if it's valid,
if it matches the domain
that you are requesting
a payment from,
we'll return a session.
Now this session is opaque.
You don't need to worry
about the contents of it.
It's basically a unique
token that's linked
with a single Apple Pay request.
And it's used to ensure that
your site is still secure.
You have to request this
for every Apple Pay payment,
but it's a very lightweight
call,
it doesn't take very
much to request it.
And you request it
from your web server.
You don't request
it from the client.
I have got some tips for
this merchant validation.
The first one is to always
obtain the session request URL
from the client, because
it may vary depending
on the country the user is in.
Apple Pay has many
servers worldwide,
and we'll use the one
that's closest to the user
in the region they
are currently in.
Now for some of you,
you made need to know
up front the IP addresses
because you'll need to go
through your firewalls
on your web servers.
And we'll provide a list
on developmentalapple.com
so you can do that.
You should also only request a
session where the user interacts
with the Apple Pay button.
Don't request it on every
page load; there is no need.
You only need to request it
when the user taps the button.
We actually display the
Apple Pay sheet while you are
requesting the session.
So from a user's perspective
it's instantaneous.
They tap or click
the Apple Pay button.
They'll see the sheet, and we'll
just hold it in a loading state
until this validation
is complete.
You'll see how that works in
the next section when we talk
about the JavaScript API.
Finally, don't generate a
merchant session client-side.
That's because you have to
have this session certificate;
this certificate is
linked to your domain.
You don't want to embed that on
your web pages on your client.
It's very important
that you keep it secret.
And so you perform the
validation on your web server.
OK, let's recap.
We have got ourself set up.
We made sure that
our site complied
with Apple's requirements.
And we created our
virtual identifier
and our merchant certificate,
and we linked it
to our domain name.
And then we learned
how to validate --
how to validate our site
for every Apple Pay payment.
So that covers this
portion of the flow.
What about this portion?
I said it was the same
as Apple Pay within app.
But it's obviously
not the same API
because sadly we can't
call Swift from the web.
And so we are going to talk now
about the new JavaScript API
that's supporting this feature.
And to do that, I'd
like to ask Anders
from the WebKit Team
onto the stage.
Anders.
[ Applause ]
>> Thanks Nick.
I am really excited
to be here today
and show you how easy it is
to use the Apple
Pay JavaScript API.
As Nick mentioned, the Apple
Pay JavaScript API is available
in iOS 10 in Safari,
as well as apps
that use SafariViewController.
And now, with Mac OS Sierra, you
can use Apple Pay on your Mac,
in Safari, using your
Apple Watch or iPhone
to do the actual authorization.
It's a relatively simple API.
It's got a single entry
point called ApplePaySession.
It's got a single entry
point called ApplePaySession.
And it's influenced
by the PassKit API
for doing Apple Pay with an app.
So if you are familiar
with that API,
you'll notice a lot
of similarities.
Now before we dive
in, I have to tell you
about this friend of mine.
She owns a store that sells
high-end designer clothes
for dogs.
And a couple of months
ago, she launched a website
where you can buy these clothes.
You can order them
online and pay for them
and have them shipped
to your door.
But unfortunately business
has been a little rough.
She's getting a lot of traffic
to the website, but not a lot
of actual orders go through.
So let's take a look
at the website and see
if we can figure out why.
So this is our website.
And let's say I want to
buy this lovely scarf here.
Well first I have to
add it to my cart.
Then I have to check out.
Then I'm at the Checkout page,
and I have to enter
my shipping address.
And then I have to go
and get my credit card
and enter the credit card
number and billing address.
And then I can place my order,
and my scarf will be on its way.
So let's see how we can
use the Apple Pay API
to make this process
simpler and more streamlined.
For example, what if we could
take this Add To Cart button
and supplement it with
an Apple Pay button
so that you can place orders
right on the main product page?
Now we only want to display
this button if we know
that the user can actually
make payments with Apple Pay.
So in order to do that,
we can use the function
ApplePaySession.canMakePayments.
This is a pretty
simple function to use.
This is how it would
look like in code.
Note here that I am
checking for the existence
of the window.ApplePaySession
object before I try to use it.
So I am not checking
for a specific version
of WebKit or Safari.
I am just checking for the
existence of the object.
And if it exists, I call it --
it returns a boolean and
I check the return value.
If it returns true, I call this
function showApplePayButtons.
And that will show the button.
It's important to note, though,
that this function only tells
you whether Apple Pay is
supported by the device.
So if you are on an
iPhone or an iPad,
it'll tell you whether
it has a secure element.
And if you are on a Mac,
it'll tell you whether there
is an iPhone or Apple Watch
that can authorize the payment.
It does not tell you whether
the user has a card added.
So in order to check for that,
we can use the function
ApplePaySession.canMakePayments
WithActiveCard.
You pass this function,
your merchant identifier.
And it actually goes out to the
Apple Pay servers and validates
that the merchant
identifier is correct
and that it's properly
associated with the domain
where you are making
the call from.
Because of this,
it is asynchronous
and returns a JavaScript
promise.
Now if you don't know what
a JavaScript promise is,
you can just think of
it as a more robust way
of doing callback-based
programming.
There are also some
restrictions as to
when you can use this function.
You can use it if
you want to default
to Apple Pay during your
checkout flow or if you want
to Apple Pay during your
checkout flow or if you want
to add an Apple Pay button
to your product page.
Now in our case we want
to add an Apple Pay button
to our main product page,
so we can use this function.
Otherwise we would have used
ApplePaySession.canMakePayments.
But here is how we
use the function.
Again, I am checking
for the existence
of the Apple Pay session object.
Then I call canMakePayments
WithActiveCard.
I tap in my merchant identifier.
And then I use this
promise.then function so that
when the promise is resolved,
in this case it's resolved
to a boolean that's
true or false,
the function I specified
inside will be called.
And if canMakePayments is true,
I call showApplePayButton.
So now we've got our
nice-looking buttons
for every single
product on the page.
And the next step is to
present the payment sheet
when the user clicks
on the button.
So in order to do that,
we'll create a new
ApplePaySession
we'll create a new
ApplePaySession
JavaScript object.
The ApplePaySession constructor
takes two parameters.
One is an API version number.
This is something
that we've added
so that we can extend
the ApplePaySession API
in a backwards-compatible way
without breaking
existing clients.
The current API version number
is 1 so just always has 1.
The second parameter you pass
in is the payment request.
If you are familiar
with the PassKit API,
this is the JavaScript
equivalent
of a PKPaymentRequest.
So it then takes all the
necessary information needed
to display the sheet, things
like currency and country
where the payment will be
processed, the total amount,
and optional list of line items,
as well as shipping information
that might be required.
And then when you get back your
new ApplePaySession object,
you simply call Begin and
that'll present the sheet.
you simply call Begin and
that'll present the sheet.
This is what it looks
like in JavaScript code.
So first we declare our
paymentRequest object.
We specify the currencyCode
and countryCode.
And here I specified
the total amount
and the supported
card networks as well
as the merchant capabilities.
And lastly, I specified that
I need the full postal address
for shipping purposes.
And then I simply create
my new ApplePaySession.
I pass in the merchant
number, which is 1,
and the payment request.
And I call sessions up again
on the returned object.
Now with any payment API,
it's really important
that we get all the
details right.
And because of this, before we
present the sheet we perform a
And because of this, before we
present the sheet we perform a
series of validation steps.
And if any of these
steps fail, we'll stop
and just throw a
JavaScript exception.
And because of this, creating
an Apple Pay session can throw a
JavaScript exception.
For example, if you call
in from an insecure page,
a page that it's not served
over HTTPS using the best
practice encryption protocols.
In fact, every single Apple
Pay session API will throw an
exception if you try to call
it from an insecure web page.
Creating an Apple Pay session
can also throw an exception
if you pass in an
invalid payment request.
For example, if you
didn't specify the list
of supported networks, or
if you have a total amount
that is negative, for example,
or if you spell the
property wrong
so that it's something
we don't recognize,
that will throw an exception.
In addition, calling Begin can
throw an exception if you call
in -- try to call
it in from outside
of an onclick handler,
for example.
We do not allow displaying
the sheet unless the user has
explicitly asked for it
to be presented using
a click or a tap.
Or if there is already a sheet
up, and we try to call Begin,
we'll throw a JavaScript
exception
because we only allow showing
a single sheet at a time.
And if you get one
of these errors,
you can use the Web
Inspector's Error Console
to get a more detailed look
at what could be wrong.
But if everything is good and
all the steps are correct,
we'll display the sheet.
But notice that you can't
actually confirm the payment
yet; we have this
loading spinner going.
yet; we have this
loading spinner going.
And that's because we haven't
yet handled the merchant
validation
that Nick mentioned earlier.
So shortly after the
sheet is presented,
we will send a validateherchant
DOM event
to the ApplePaySession object.
This DOM event has a
validationURL property,
and this is the URL that
you pass to your server
and have it load to create
the merchant session.
And then when you get back
your merchantsession object
from your server, you simply
call completeMerchantValidation,
pass in the session,
and you're good to go.
Here is what a validatemerchant
event handler looks like.
So here I call this
performvalidation function
that I have written.
It returns a promise,
and the promise resolves
to the merchant session.
So when the promise is resolved,
I simply call
completemerchantvalidation,
I pass in the merchant session,
And that's how you do
merchant validation.
So now, when merchant
validation is done,
the user can authorize
the payment
on their phone or
their Apple Watch.
And when the payment
is authorized,
we'll send a paymentauthorized
DOM event
to the Apple Pay session.
This DOM event contains
a payment property
that has all the necessary
information about the payment.
So it's got things like
the full shipping address,
information about the
payment network that was used
to make the payment; and it's
got the encrypted payment token
itself that you send to
your payment processor.
And when you have sent that and
the payment has been processed,
and you get back a reply,
you call completePayment
and that will dismiss
the sheet, like this.
So here we have a
paymentauthorized event handler.
I call sendPaymentToken.
I pass in the token.
And this returns a promise
that resolves through boolean
that is either true
or false based
on whether the payment was
processed successfully or not.
So if it's true, I set my status
to ApplePaySession.STATUS
SUCCESS.
If it's false, for example, if
the payment didn't go through,
I set my status to
ApplePaySession.STATUS FAILURE.
Then I call completePayment.
I pass in the status, which
will dismiss the sheet.
And then I call this
showConfirmation function,
which will show a nice little
order confirmation pop-up.
And when you call
completePayment and pass
in Success, you get
this nice check mark
and the sheet will be dismissed.
OK. So now let's take a
look at a demo and see how
to do all of these things.
Here we go.
So first of all,
this is the website.
So first of all,
this is the website.
And now let's take a
look at the source code.
But before we start adding
JavaScript, I'd like to point
out a couple of things.
Here I have added
these touch icons.
These are used in the Safari
Favorites view, for example;
but they are also used in the
Apple Pay authorization sheet,
which we will see later.
And here I have listed
all the products,
and I have actually gone ahead
and added the Apple Pay buttons.
I am just keeping them
invisible with CSS.
So let's take a look at that.
Here is my CSS, and
this is the declaration
for the Apple Pay button.
So I set this visibility
to hidden here.
And for the actual image itself,
I am using this
WebKit-named-image feature
so we can grab the Apple Pay
logo directly from the system
so you don't have to
host it on your website.
OK. So the first thing we want
to do now is add the code
that'll display the buttons
if Apple Pay is enabled.
So I have already started
writing some code here.
I have created an EventListener
for the DOMContentLoaded event.
This event is dispatched
when the main document
is finished loading
but before any remaining images
from other resources
have been loaded.
So it's a good place to do that.
So let me add the
code to do that.
Again, I am checking
for the existence
of the ApplePaySession object.
Then I call
canMakePaymentsWithActiveCard.
And inside my promise function,
I check the return value,
and if it's true I call
showApplePayButton.
So I -- let me save
and go back here.
And we load.
And now we got our
Apple Pay buttons.
So the next step is
to show the sheets
when a user clicks on a button.
So I have written this
applePayButtonClicked function
that is invoked whenever
the user clicks on a button.
So here is where we want to add
our code to present the sheet.
So again I have declared my
paymentRequest object here.
I have hard-coded the amounts
here and, since this is a demo,
but in real life we would
get this from somewhere else.
And I then create my new
ApplePaySession object,
and I call Begin.
So let me save and reload
and present the sheet.
OK. So it looks like
the sheet did not show.
So let me open the Error console
and try to figure out why.
OK, so it says that
"supportednetwork" is not
a valid property name.
And it looks like I
misspelled "supported" here.
So let me just go back
and fix that and reload.
And now we have the sheet.
But I can still not
confirm the payment
because I haven't handled
the merchant validation.
So let's go ahead and do that.
So I want to add my
validateMerchant event handler.
And I'll do it here after
we have created the session
but before we call Begin.
And again I call
performValidation.
And when the promise that this
function returns is resolved,
I call
completeMerchantValidation.
I pass in my merchant session.
And then I should be able
to confirm the payment.
And the last thing we need
to do now is add our
payment authorization code.
And this will send the
payment token to the server
and confirm the payment.
And if we are successful,
I set my status to SUCCESS;
otherwise I set it to FAILURE.
And then I call completePayment
and showConfirmation.
So now I want to
bring up QuickTime
so we can actually see what this
looks like on the phone as well.
So let me reload, and I hit Pay.
And now I can confirm.
And as you can see, I get
this little site icon.
That's because I added
those link icon attributes.
And now I can pay
and we're done.
And the scarf is on its way.
[ Applause ]
So that's how easy it is to
add Apple Pay to a website.
And I think that
with these changes,
Canine Clothing sales are really
going to be through the woof.
Back to you, Nick.
[ Applause ]
>> You know all this -- I
think whoever on WebKit came
up with all those dog
puns should be thrown
in the doghouse.
Aw, come on.
Throw me a bone.
I'm wasted in software
engineering.
I'm wasted in software
engineering.
All right.
So we have seen how to build
our sites to enable Apple Pay.
Let's talk about something
that's probably very important
to you.
That's how you'll
actually get paid,
how to get some money
from Apple Pay.
So Anders covered these steps up
to receiving the payment data.
What happens next?
Well you have two options,
really, with the payment token.
The first option is to decrypt
the payment token yourself
on your own servers.
That's a good option if you
are already using Apple Pay
or you have a very large
eCommerce back end.
You're familiar with the
cryptography involved.
It is documented, though,
on our developer site.
But another option
that's a little easier is
to just pass this
encrypted payment data
to your payment provider, and
they can decrypt it for you
on your behalf if you
provide them with the keys.
This is a really easy option,
and many payment
processors today offer SDKs
to do this in-app.
We are highly confident
that these payment processors
will be offering similar
JavaScript-based SDKs;
these integrate directly
into your websites.
In fact, in the U.S. and Europe
over 40 payment processors
support Apple Pay today --
too many for me to
put on a site.
But there's a full list
on developer.apple.com.
And as I said, many of these
providers offer SDKs today
for in-app; and they'll
be offering SDKs
for the web as well.
I also want to highlight
some new payment processors.
As you may know, Apple
Pay launched in China.
And of course this feature
works in China as well
as in the U.S. and Europe.
And we have four payment
processors in China
that support Apple Pay.
They are China UMS, LianLianPay,
PayEase, and YeePay.
So if you are looking to
distribute an app or a site
in Asia, you have got great
support there as well.
Now one thing I mentioned at the
start is eCommerce platforms.
Many sites don't build
their own eCommerce systems.
They use the platforms provided
by an eCommerce provider.
And we are partnering
with multiple eCommerce
platforms today.
We are partnering with
three major platforms.
They are Demandware,
IBM, and Shopify.
And if you are using any
of these three platforms,
you will be able to use
Apple Pay, and in many cases,
you will be able to use
Apple Pay without even having
to have a developer account.
These platforms can
make that easy for you.
They can handle all
of this process
with their deep Apple
Pay integration.
Now you are probably
pretty desperate
to go off and try this.
I hope you are.
I want to talk a
bit about testing.
So testing your sites:
We are introducing a
new testing environment
for Apple Pay called
the Apple Pay Sandbox.
It's a new way to test.
And initially Apple Pay for
the web will be available
within this sandbox.
Now if you'd like
more information,
we don't quite have enough
time in this session.
But you can check the
session right after this one;
we are going to be
talking about the Sandbox.
Or if you go to our site
at developer.apple.com,
we have some information
about how
to use the Apple Pay Sandbox.
But for the initial seeds,
that's how you'll be able
to test Apple Pay on the web.
Then we'll roll it out into
our production environments
as we near the release of
iOS 10 and Mac OS Sierra.
Now also, when testing
and developing your sites,
please give us some feedback,
[inaudible] some bugs.
We really want to hear about
all the issues you are having
and all the great
things you're seeing.
If you just have compliments,
I'd love to receive
those as well.
OK. Let's talk about the final
piece: Designing for Apple Pay.
How to build a compelling
experience for your websites.
How to build a compelling
experience for your websites.
And a lot of these tips are
applicable to apps as well.
At the start of this
session I talked
about how Apple Pay has three
main principles: They're easy,
secure, and private way to pay.
And your designs
should reflect that.
They shouldn't make
it complicated.
They shouldn't make it
hard to use Apple Pay.
There are three main
phases of Apple Pay as well.
There's pre-payment,
that's before you have seen the
Apple Pay sheet, the experience
of using Apple Pay before
the sheet has come onscreen.
There's payment itself,
actually taking payment
when the sheet's
looking towards the user.
You can customize that.
How should you customize it?
We'll find out.
There's also post-payments.
That's the experience after
the sheet has been dismissed.
So let's run through
these three phases
and discuss how your
designs can work
and discuss how your
designs can work
with Apple Pay for each phase.
Prepayment starts with
the Apple Pay button.
And the Apple Pay button is
available both in Cocoa Touch,
and, as I've just shown you,
we have some artwork in WebKit
that you can use as well.
It's available in a
variety of styles.
Here are a couple of them.
And Anders showed you the CSS,
but just to reiterate we have
a WebKit-image-named property
that you can use.
You can get an Apple
Pay logo, so you can use
that for your buttons
on the web.
There are some do's and
there are some don'ts
when you are using
the Apple Pay button.
Do use the built-in assets.
Sometimes, you never know,
we might change the logo.
You want to make sure
you're up to date.
Also, place wherever a user
might want to purchase.
Don't hide it away.
Don't make it difficult
for the user to pay
with what is a very
easy payment method.
There is also some don'ts.
Don't modify the button, or
don't change its behavior.
Don't modify the button, or
don't change its behavior.
It's very important
that if a user taps
on an Apple Pay button,
they see an Apple Pay sheet.
We want that expectation
to be there.
And also don't suppress
the button.
As part of the Apple Pay
guidelines, you are not able
to suppress the button.
It needs to be at the same level
as your other payment methods.
Let's talk about where
you can place the button.
Now Anders' demo showed you how
to place the Apple Pay button
early on in your purchase flow.
And placing it on product pages
can increase user engagement.
We've seen some great data from
apps that have adopted Apple Pay
to show they've seen
drastic conversion increases
when they place the Apple Pay
button on their product page.
Now obviously you
can also place it
in regular checkout
and in carts.
Let's look at a few examples.
We gave the Apple Pay API to
some websites, and we asked them
to come up with some designs
and some experiences
that use Apple Pay.
Here's one from StubHub.
Now StubHub has decided to a Buy
with Apple Pay button during
their checkout process.
You select the number
of tickets you want,
and then you just
buy with Apple Pay.
You can also bring
that a step earlier.
You can do what I call
an express checkout.
This is from Warby Parker.
This is after you have
selected a product.
You see we have two options.
We can add the product to our
cart and continue shopping,
or you can just buy it there
and then with Apple Pay.
Finally, you can place
the Apple Pay button
on your actual product pages.
Here's an example
from Lululemon.
The Apple Pay button right
there on the product page.
Let me show you that
on iPad as well.
Here you can see there's
still an Add to Bag.
So if I want to create my
cart as normal, I can do that.
Or I can just buy
it there and then.
Now one thing that
really enhances buying
on the product pages is
enabling a guest checkout.
Required registration is a
major source of user friction.
Required registration is a
major source of user friction.
I don't know about you, but I've
definitely not purchased things
because the site I didn't
really know wanted me
to create an account up front.
And so Apple Pay can help
reduce these abandoned purchases
by making guest checkout
flows really ease to use.
Also, you can optionally
leverage the information you
collect in the Apple Pay sheet
to create accounts
post-purchase.
I'll show you an example of that
in the post-payment section.
Let's move on now to actual
payment, the Apple Pay sheet.
Now the Apple Pay sheet
offers a flexible payment flow
for merchants.
It's highly customizable,
but it also offers a
consistent experience for users.
You can decide what
fields you want to show,
but the user always
knows what to expect.
Here is an example of
an Apple Pay sheet.
I am using the Mac OS sheet.
But the same fields
are available on iOS
But the same fields
are available on iOS
if you're making a web payment
in Safari, on iPhone, or iPad.
The first field is where
you select your card.
It's also optionally where you
can input your billing address,
although billing
addresses aren't required
to process an Apple Pay payment.
The next field is shipping.
This is where you request
information from your users.
You can request billing,
shipping,
and contact information
if you need it;
and you can also specify
shipping methods or pickup.
You can change the terminology.
If you don't like it saying --
to say "shipping," you can
say "delivery" or "pickup."
It's good if you're
a ridesharing app
or maybe a takeaway service.
Now you can list
shipping costs as well.
You can list them
in summary items,
which we'll talk
about in a second.
But when you're collecting
this information,
make sure you have a
clear privacy policy.
When you use Apple Pay within
an app, when you upload it
to the App Store
you are required
to the App Store
you are required
to provide a link
to a privacy policy.
Now when you are
designing for the web,
obviously there is
no way to do that.
So instead we just ask that you
place a privacy policy somewhere
on your site that clearly
describes what you are intending
to do with this information.
Now you can also
enable shipping methods
that lets you select
things like delivery.
And just like the shipping
address, it's customizable.
Users can pick from
a list of methods.
Now these methods can
be updated in response
to address changes perhaps
if you already offer express
shipping in New York City,
you can easily reflect that.
Methods could also be free if
you want to offer free shipping.
And just like shipping
addresses,
the naming can be
customized to suit your needs.
Now although you
request address, e-mail,
and phone number in
the same property,
they are separate
fields on the sheet.
So this field here,
the contact field,
is where you enter
the information other
than postal address.
Now we support collecting
phone number.
Now we support collecting
phone number.
We support collecting
e-mail address.
And if you are not
requesting a shipping address,
we also allow you to
request the user's name.
That's useful if maybe you
are a ridesharing app or site
and you want to have
the name of the user
but you don't need
their shipping address.
Now is the most important field,
it's the summary items field.
This highlights the amount
that is being paid to the user,
sorry, that the user
is paying you.
And you can use this
summary of items sheet
to display a concise indication
of what's being charged.
Things like subtotals,
shipping, or discounts.
Now it's not a line-by-line
itemized list.
It's not intended to
be a bill of sale.
So you should keep it concise.
Also, be upfront and clear
about what you're charging.
Make sure that the total amount
reflects what the user is
actually going to be
charged on their card.
That being said,
there are some cases
where you don't necessarily know
the amount you want to charge.
Sometimes you don't
know the final cost.
Maybe it's a hotel
reservation that's open-ended,
or car hire, or a taxi service.
And you can use the
pending item type
on our summary item
to indicate this.
Now again, just make
estimates clear.
Why do I keep saying
"Make estimates clear"?
Well as you may have seen
in the demos, after you pay
with Apple Pay normally you'll
actually see a notification
from your bank with the
amount that's charged.
So you want to make sure
that the amount that's
on the sheet matches this,
at least as best you can
in the case where you
don't necessarily know the
final amount.
Summary items also support
free and discounted items.
Items can be marked as free.
And summary items can also be
negative except for the total.
The total amount needs
to be a positive number.
But anything before that,
if you want to indicate a
discount that's totally fine.
Now there's one other
field on the Mac OS sheet,
and that's the field that tells
you which device to confirm on.
and that's the field that tells
you which device to confirm on.
Which brings me to
a point others raise
around the site icon.
So this is a sheet on iPhone
when you are paying on your Mac.
You can't customize
anything on here.
We inform you of the card,
but you can't change it;
you need to do that on a Mac.
By the way, if you
change any options
on the Mac the price here
will automatically update.
So if you change shipping
methods to something
that costs more, we'll
sync that straight over.
But this site icon is
downloaded from your site.
You can specify it
in a number of ways.
It uses the existing Apple Touch
icon, and you need to provide it
for Apple Pay at 180
and 120-pixel sizes.
The easiest way to specify this
is to just use a link attribute.
But you can also specify at
the root node of your domain.
Whatever works best for you.
I'd also like to briefly
touch upon something else.
That's semantic markup.
So many of you may already
be using semantic markup
on your pages to indicate
the types of products
that are available for
search engine indexing.
We actually index the
product type ourselves
in Spotlight on iOS.
You can also indicate that
your site takes Apple Pay using
appropriate semantic markup.
We think this will benefit,
for example, search engines,
people who want to know where
Apple Pay is being used,
if you'd like to
consider doing that.
OK, let's move on
to the last phase
of payment, the confirmation.
Now in your confirmation
you want
to reflect the appropriate
status in the Apple Pay sheet.
So for example, don't
display a success page
if you returned a failure.
That would be silly.
You can also leverage
information collected
by Apple Pay to offer
account creation.
I mentioned this earlier.
I want to show you an example
of that from Lululemon.
Here's an example.
After you have made
an Apple Pay payment,
you get a confirmation page
and you actually get a create
an account field that's
and you actually get a create
an account field that's
pre-populated with
the e-mail address
that came from Apple Pay.
So I can create an
account on my own terms.
I can enter into a
relationship if I want to,
and it's easy to do so.
OK. We covered quite
a bit today.
What did we cover?
We covered Apply Pay merchant
validation on the web.
We learned about the differences
between ActiveWeb for Apple Pay.
We also covered the Apple
Pay session JavaScript API
with Anders.
And we also talked
about taking advantage
of Apple Pay in our designs.
Now we have a lot of information
about Apple Pay on the web.
You can check out our developer
page and our microsite here.
We've also got the
related sessions.
Firstly, don't go anywhere.
Stay right here.
Don't you even leave.
I am going to be right back here
at 3 o'clock talking about news
with Wallet & Apple Pay.
We're going to talk
about the Sandbox.
We're going to talk
about WatchKit.
We're going to talk
about extensions.
And we're going to talk about
some of the new things in Wallet
And we're going to talk about
some of the new things in Wallet
and Apple Pay for
banks and retailers.
There's also a session
for web people:
Optimizing Web Content
in Your App.
That is Friday at 4:00.
That's everything from us.
Thank you so much for coming.
I can't wait to see all the
sites you're going to build
with Apple Pay on the web.
Thank you, and have
a great WWDC.
[ Applause ]