This year, Apple Pay is coming to the web with Safari on both macOS and iOS. Now you can experience the convenience and security of Apple Pay in your store, in your app, and on your website. Discover how easy it is to set up Apple Pay on the web, and learn how designing for Apple Pay can increase conversions, user engagement, and customer satisfaction.
[ Music ]
[ Applause And Cheering ]
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,
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
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,
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
that you can use while you are here at the conference.
And Apple Pay within apps enables best-in-class
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.
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.
And it's unclear.
The checkout flow is different
for every single merchant, every single site.
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.
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
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.
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.
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,
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 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.
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.
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.
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
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
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
And to do that, I'd like to ask Anders
from the WebKit Team onto the stage.
I am really excited to be here today
and show you how easy it is
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.
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
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
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
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 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
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,
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.
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
series of validation steps.
And if any of these steps fail, we'll stop
And because of this, creating an Apple Pay session can throw a
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,
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.
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.
And now let's take a look at the source code.
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.
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.
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.
So we have seen how to build our sites to enable Apple Pay.
Let's talk about something that's probably very important
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
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.
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.
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
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.
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.
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
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
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,
When you use Apple Pay within an app, when you upload it
to the App Store you are required
Now when you are designing for the web,
obviously there is no way to do that.
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.
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
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.
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
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.
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 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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.