Apple Pay on the Web 

[ 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 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 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.

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.

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.

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, 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.

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.

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 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.

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 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 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.

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 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.

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.

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.

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.

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 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 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 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 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.

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.

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.

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 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 ]