Hello everybody. Hello again if you just came from the previous session, thanks for staying. And hello if you're new. Hello to everyone downstairs, and hello to everyone watching online. My name is Nick, I'm joined today by my colleague, Leo, and we're going to talk about what's new with Wallet and Apple Pay.

First of all, we're going to have an update for Wallet. We're going to talk about passes. We're going to talk about some new features for banks and for retailers. And then we're going to talk about WatchKit, now you can use Apple Pay not just to pay in-store on Apple Watch, but also inside WatchKit Apps.

We'll also talk about something I'm really excited about and that's the new extensions on iOS, Siri, maps, and messages. All of these new extension points that can be enabled with Apple Pay. And finally we'll talk about something exciting and new, I think you're all going to love, testing Apple Pay and the new Sandbox environment. Let's get started.

What's new with PassKit. So, hopefully you'll be aware that Wallet isn't just Apple Pay, it's passes as well. And there's no better time to start using passes because more users are engaging with Wallet than ever, due to Apple Pay. More people are opening the Wallet App, more people are using it. Now, we don't have time today to run through the pass ecosystem, but we do have some resources for you.

I'll tell you a little bit about them just to remind you, don't worry, not too much. Passes enable you to get gift cards, boarding passes, rewards cards, event tickets, membership cards, and more directly into the user's iPhone or Apple Watch. And you can distribute these passes in many ways, through an app, through email, SMS or iMessage, web link or QR code. And these passes can be updated remotely. And these updates show up on a user's lock screen.

Things like date changes, for an airline ticket, or relevancy. Your passes can be relevant, if you're near the store, they'll show up on the lock screen. We have a session that talks a little bit about some of these passes and provides you some more resources. It's the home for Apple Pay and more, it was last year's session. And there's plenty of great resources at developer.apple.com.

Let me talk now about a few new changes. Some things we've changed over the past year that maybe you didn't notice. One of them was app placement. We've actually changed the pass design a little bit, this happened in iOS 9.3. Apps are now placed on the front of passes and these app icons can deep link directly into your applications. So these are great for things like gift card top-up, if you're a gift card pass and you want and easy way for the user to quickly top it off, or an airline, you want to go to the app for more information about the flight.

And it's very easy to add this, you just need to add the pass to your pass, the apps ID, it's Adam ID from iTunes, and also its URL scheme to deep link in if you want to do that. Last year we also introduced a new type of pass, the value-added services pass. So passes can now transmit information securely over NFC.

Things like loyalty card information, if you're in the US you might have used the Walgreens Pass, which lets you transmit over NFC. And support for value-added passes has grown over the past year for many points of sale systems. Verifone, Ingenico and many other manufacturers of payment terminals now support this protocol.

There's some things you may not know about value-added service passes, they also support what we call a one tap experience. It looks a little like this. It's where you actually place the phone on the payment terminal and you'll transmit both your payment information and your loyalty information in a single tap.

So it's deeply integrated into the purchase process. This also works with Apple Watch as well. Now these value-added service passes can also be distributed over NFC, and you can even sign up for loyalty programs from these NFC distributed passes directly from Wallet, to be shared and personalized. You can actually sign up for a loyalty program right there.

Now, there are a few caveats to the value-added service passes. One of them you might be aware is that passes need to be signed using a different certificate. Regular passes are signed with a certificate you create at the developer portal, but value-added service passes need to be signed with an NFC signing certificate.

Now, you need to request these certificates. You can contact us to find out more. I'm actually going to have a link at the end of this presentation. So you can go and request more information about using value-added service passes. And we're also going to have some engineers in the labs. We got a lab right after this session, so if you have any questions please come down, we'd love to talk to you.

Let's talk about a few other new features in PassKit. Now these are specific to card issuers, but I think they're pretty interesting, even if you're not a card issuer, you might be interested to know about them. We offer some unique features for card issuers who use Apple Pay.

We also now support store credit and debit cards. Here's a Kohl's card. So if you have a store card you can add them. So these aren't just for banks, they're for retailers as well. One really great feature is app provisioning. Now, we added this last year and a couple of apps have already adopted it, Discover is one of them. This lets you set up cards in Apple Pay directly from your own app. You never need to leave you app, to open Wallet, to open preferences. And it's available to any existing Apple Pay issuer.

Now the API is documented on developers.apple.com. But you can also contact us for more information. We actually have an email address, which I'll show at the end, and we're going to have people in the labs to help. We also have this great new button style, which you can use both for adding cards, but also for adding regular passes. So if you're just a pass developer, you can use the new PKPaymentButton style I'm showing you here. I'll have some codes to show you how to do that in a minute.

Now something that's new in iOS 10 is specifically for card issuers and retailers who might have partnerships, either co-branded cards, or they've got a partnership with a bank, we now let you enable a new in-store experience. You can present your cards directly from your apps. A really good use case of this, you can redeem a coupon from your app and immediately present a payment method.

So maybe your app is enabled with iBeacons, it's got a great in-store experience. So you go into the store, you redeem a coupon in the app, you just press a button and you can immediately pay with Apple Pay. The card could be right there in your app. It's a really easy API to use. It's just on the Pass Library.

And you can use the new PKPaymentButton style for some consistent branding. And this is the style .inStore. We have another style I just showed you to add it to different class actually, it's an Add to Pass Button, but take a look at the documentation for more information. Another feature that's pretty interesting is associating your applications with your cards.

Again, this is great if you're a retailer and you have a co-branded card or you have a partnership with an issuing bank, you can associate your app with your store or program cards, which means it can default, if the user wants to do that. Here's the screen you'll get for a VAS pass, but it's the same for payment passes. You can default your card when paying over NFC, or new in iOS 10 you can also default when paying with an application. And also a website if you're taking advantage of the new Apple Pay on the web stuff.

Now the great thing about most of this is that no API required. It's actually built into the card itself. All you need to do is get your app, and its Adam ID and URL scheme into the pass when it's added to device. Now to do that you can talk to your issuing bank, or if you're an issuing bank, you can come talk to us using the contact information at the end of the session, or come and see us in the labs. So that's some of the new stuff in PassKit. I want to talk now about Apple Pay and what's new in Apple Pay. And I also want to tell you how Apple Pay has been doing.

So Apple Pay is an easy, secure and private way to pay both in-store and within applications. And it's got amazing customer satisfaction. It has one of the highest customer satisfaction rates of any payment method. And Apple Pay is usable today within applications. You can pay using Apple Pay directly from apps. And thousands of apps have already adopted worldwide in the US, in China, an example here.

We've recently announced we're launching in France, also Australia. We've got many countries that support Apple Pay. And millions of users are enjoying using Apple Pay. And we've seen incredible growth of Apple Pay, both in-store and within applications. And developers such as yourselves have seen some great results too. Here's two apps that I want to talk about. One of them is Chairish.

Now the Chairish app, they found that when they used Apple Pay their conversion rate tripled from other payment methods. That's a huge increase. I can't think of another payment method that has such great results. And StubHub in their iOS application found that Apple Pay was driving twice as many new users than any other payment method. So this isn't just for your existing customers, Apple Pay can bring you new customers as well. Apple Pay apps are often highlighted on the app store in their own sections. We often run promotions of Apple Pay apps.

We've also seen some great results in some of the new countries we've launched in. One country I want to briefly talk about is China. We've seen some great applications in China. I was so lucky to go to Beijing a few months ago and taught some developers using Apple Pay and they've seen some great results too.

Apple Pay in China offers full support for China UnionPay credit and debit cards. And the Apple Pay API is accepted by CUP, that's China Union Pay, PayEase, Lianlian Pay, YeePay, and UMS. These are major Chinese payment processes. We also have documentation both interface guidelines and our Getting Started Guide are available in Chinese, they're also now available in French as well, now that we're launching in France.

You can check out our developer site for links to those. Now I want to talk about some new API and if you're developing for Apple Pay already, you're probably really going to love this. One of the problems with Apple Pay has been the need to set your networks upfront. You need to tell us the networks you want to use in your payment request. So that's hard coded into your application.

And adding new networks is difficult. You either have to perform SDK availability checks to tell if the constants are available, or you have to try to hack something together, it's not ideal. And for those of you who have Apple Pay apps maybe you remember when we launched Discover on Apple Pay, last year, unless you went and updated your app, you probably weren't able to accept them even if your payment processor could. So we're introducing something new in iOS 10 to help with that, it's dynamic networks and proxies.

Firstly, we're adding a new class method onto PKPaymentRequest. It's going to tell you all of the networks that are available on that device. There's PKPaymentRequest available networks. We're also going to enable something else. You're going to be able to set payment process as supported networks. And these proxy down to other networks.

So for example, if my payment processes supports Visa, MasterCard, AmEx and it's enabled here, I just put them in as the supported network and I'll get all of the networks automatically. And perhaps most importantly, I'll get new networks as they're added to Apple Pay without needing to do anything. So you can check our developer site for information about payment processes that are going to participate in this. It's a really cool feature, it's going to save a lot of pain I think for writing Apple Pay applications.

One other thing we've changed, I just want to touch on, Swift 3, maybe you've already seen some of the big changes in Swift 3. We have improved our API for Swift users. We've actually completely rewritten our sample code, talk about that later. One change that's coming, didn't make seed one, but it will be in seed two. PassKit now uses stringly typed enumerations. If you're not sure what those are, they're a very cool way in Swift to take string constants and turn them into enums, which is going to make developing for Apple Pay a lot easier. Now let's talk about Apple Pay in general.

This year we've got three big new places where we're adding support for Apple Pay. We're adding support to WatchKit for WatchKit apps. And we're adding support to new extension points on iOS. And finally we're adding support to Safari, both on MacOS Sierra and on iOS 10. Now we just talked about Safari in the previous session. It's online right now. You can check it out.

Let's focus today, right now WatchKit and extensions. I'm going to start off with WatchKit. And to talk more about WatchKit and to show you how easy it is to integrate Apple Pay on to Apple Watch, I'd like to ask Leo from the WatchKit team to come up. Leo.

Thanks, Nick. Hello everyone. My name is Leo and I'm a software engineer on the Apple Watch team. I'm really excited to tell you about what we are doing with Apple Pay on the watch this year. We're adding support for making payments within WatchKit apps. We think this is going to enable a whole new category of apps on the watch. And the great news for you developers, if you have implemented Apple Pay on your iOS app, the same code with work on watchOS, with very minimal changes. So let's take a look at what we're going to be covering.

First we're going to do a quick recap on how payments work on the platform. I'm going to show you how to create a payment request and how to present a payment sheet. And then we're going to do a quick demo. So you get an idea of how easy it is to get started with Apple Pay on the Watch. Finally, we're going to talk about some of the design considerations that you should keep in mind when designing specifically for the watch. This is the Apply Pay experience that your users are familiar with in iOS. Now let's bring up the watch.

The first thing you notice is that the UI is very simple. We only display the total amount and the merchant name at the top. And users can simply double press the side button to pay at any time. If they want to make any changes, or review their information, they can scroll down. And they can have access to their different payment cards, as well as shipping, billing and contact information. And they can see a detail of what they are paying for.

When they're ready to pay, they simply double click the side button and it's done. It is that simple. Now let's take a look at how payments work from a developer's point of view. We follow the same flow that we have on iOS right now. First you create a payment request and you pass that in to a payment authorization controller. This is the object that drives the payment sheet on our platform.

As the user interact with the UI, we're going to call your delegate, for example in the payment method, or the shipping address. And you may use this opportunity to perform some validations. For example, you may not ship certain products to some countries. Or you may want to update the shipping cost and the total amount on the UI. When the user confirms the payment, we talk to the secure element in our Apple servers and we issue a payment token that you can use to process the payment.

Now refer everyone to the code, a quick note, there is some setup that you need to do to enable Apple Pay on your apps. First, you want to go to the Developer Portal and register a merchant identifier and a certificate. You may have done this already for your iOS app. And then you want to enable Apple Pay for your WatchKit extension separately. And there are step by step instructions on our website on how to do this.

Now let's take a look at the code. This is how you create a payment request. We use the same PKPaymentRequest object that we have on iOS. You create one of this and you set it up with a country and currency code, your merchant identifier, and the payment network sync capabilities that you support.

And then you specify a list of summary items that describe what the user is paying for. Always remember that the last item on the list represents a total amount. And we recommend that you use your merchant name as the label, since we display that at the top of the payment sheet.

When you want to present a payment sheet, you create a PKPayment AuthorizationController and you pass in the request that we just created. Then you designate yourself or some other object as a delegate, and you simply code present. Now, since you're presenting the payment sheet, you're also responsible for dismissing it. So make sure to do that when we go to payment authorization controller DidFinish in your delegate.

So PKPayment AuthorizationController. This is a new controller class provided in the PassKit.framework. It is responsible for controlling the payment authorization flow. And it has the same API semantics as of PKPaymentAuthorization ViewController. But since it's not view controller based, it allows for presentation of the payment sheet from your WatchKit extension.

It is supported across watchOS and iOS, so you can share your user code across different apps and across different platforms. Now, let's put all of this together and see a quick demo. So I have been working on this app for a coffee shop, so that users can order and pay for their drinks right on their watch and have it ready when they get to the shop. Let's take a look at my interface so far.

Great. So we have a product view almost done, now we just need to add a way for users to pay for this. I'm going to go to the Option Library in the bottom right corner and search for a payment button. We provide you with this object that you can use when you want to present the payment sheet. We just need to drag and drop this into our view.

And now let's add some code. I'm going to bring up the assistant editor so I can have the code and the UI side by side. I'm going to control drag from my button to my interface. And create a new action that I'm going to name Buy. Now let's just focus on the code.

First of all, since we're going to be using the PassKit framework, let's make sure we import that. And now we're going to implement the buy method and it's going to be pretty similar to what we saw on the slides before. First, we're going to create a payment request.

In this case we're setting it up for the US, we're going to be charging this in US dollars. We specify the merchant identifier that we registered is available portal, and the payment networks sync capabilities list that we support. And finally a list of summary items, in this case we're just using the total for the coffee.

Now, if you want to present the payment sheet, we create a PK Payment Authorization Controller. We pass in the request, we set our self as a delegate, and we call present. Now for seed one we ask you that you keep around Payment Controller while the payment sheet is visible. Let's define the state that we're using here. And then since we're implementing the delegate protocol let's conform to that. And we only have to implement two of the required methods for this to work.

The first one, PaymentAuthorizationController, these authorize payment. It's going to be called when the user confirms the payment. And we provide you with all the information that you need to send to your payment processor and to confirm calling the completion handler with a status. The second one, as I mentioned earlier, PaymentAuthorizationController DidFinish. It's another opportunity for you to dismiss the payment sheet and perhaps present an order status at the end. This is all we have to do. So let's try bill and run this.

Okay, there's our app. I'm just going to click the Buy with Apple Pay Button, and there we have the payment sheet. It's very simple, we have different payment cards that we can try. And if you went to simulator, user action of double clicking the side button, there's a new option on the simulator menu, under Hardware, and it's called Authorize Apple Pay. We just click on this and it's done. Our payment is confirmed and the coffee should be ready pretty soon. So that's our demo.

As you can see it's very simple to implement Apple Pay. It only took us just a few minutes and less than 50 lines of code. Now, before we finish this section, I want to talk about design. How do we make something easy for users of Apple Watch? Perhaps the most important thing here is to consider what kind of experience you want to bring to the watch. Users are not going to spend more than just a few seconds interacting with your app. So try to offer them something they want, and direct them quickly to the payment sheet. Remember that the interactions are short and screens are small.

Next, don't request information that you don't need. This could be, for example, a contact email address. While we offer users the same options that they have available for billing and shipping on the iPhone, there's no way to enter a new one right on the watch, so keep that in mind.

And then as we said in the demo, use the Payment Button that we provide. If it's available on the WatchKit framework, it is supported on Interface Builder, so it is super easy to add. And please follow the guidelines that we have on our website. This is probably more detail how the Payment Button should be used in the context of your app.

So to summarize, if you have an iOS hub that implements Apple Pay most of the same code will work. You just need to make sure to implement PKPayment AuthorizationController and use the present and dismiss methods that it provides. When you're designing apps for the Watch, remember that the interactions are short, and the screens are small. And use the Payment Button that we provide following our guidelines.

If you haven't done so already, I highly recommend you checking out last year's session on Apple Pay We Announce, which goes into a lot more detail on how to create this kind of experiences, and how to customize the payment sheet in different ways. I'm really excited to see what you'll create with Apply Pay on the Watch. And now I'm going to turn it back to Nick who's going to tell you more about extensions. Thank you very much.

Thank you Leo. Okay. Extensions. In previous releases, Apple Pay hasn't really played that well with extensions. It's been difficult to support in extensions, probably because we've always needed a view controller to present from, and not all extensions are UI based. Frankly, there also weren't that many interesting places to use it. There weren't that many extension points on iOS 9 and iOS 8 that really lend themselves to Apple Pay. But that's changing in iOS 10. We've got some new opportunities.

The new extensions, in iOS 10 work really well with Apple Pay and they have built-in support for Apple Pay. And we've solved the problem of not being able to display in a non-UI context. The PKPayment AuthorizationController API that Leo showed you on watchOS, is also available on iOS. You can actually use it anywhere in an app, or an extension.

I want to show you some extensions that use Apple Pay. We gave the extension's API the iMessage app API to Fandango and they use it to purchase movie tickets. There's some other things you can use it for. You can use it to split items and purchases, send gifts to friends, organize outings. So here you can see, Fandango you picked a movie, suggest with your friends, bought the tickets, we never leave messages, we're still in messages. And you're done. It's really easy.

I want to show you another use of Apple Pay. It's Apple Pay in Siri and Maps in the Intents framework. So there's a new ride sharing extension point that works both in Siri and in Maps. And you can use Apple Pay within that extension point, it's actually built in. So you can pay directly from the extension.

I'll show you a short video of that. The sample code that we've developed this year, actually has a ride sharing intent. So here we're asking Siri to book a ride using our sample app. Siri asks us if we want to get a ride, we say yes. The Apple Pay sheet's immediately displayed.

I can touch ID, and then I can be on my way. It's that easy. I never have to leave Siri, I stayed right there, never have to go to another app, never have to put any payment information in. This is great if the user never has a relationship with your app, if they've never used your app before, they can still pay for things. They don't need to have an account. And so requesting and presenting payment in these extension points is identical to WatchKit.

There's no difference. You can use this new PKPayment AuthorizationController in both your UI and your non UI extensions. And I actually recommend that you share your payment code. You can have a centralized payment class, and you could share that between Watch, iOS app, and iOS extension. That's actually what we've done with our sample code.

So we've rewritten the Emporium sample app we released last year, it's been rewritten in Swift 3. It's been simplified. So it's a lot easier to understand. And it shows a shared Apple Pay model, where the actual payment logic is the same, regardless of the platform that you're on.

So, download that and try it out. Of course, you might have a little problem trying it out, and that brings me on to testing Apple Pay. I saved the best until last for you. Testing Apple Pay today if you've developed an Apple Pay app, you'll notice it's a little tricky. You can test on the simulator. And we've actually got some great new support in the simulator. You saw the new authorized Apple Pay Button on the simulator for Watch, we're also bringing that to iPhone in seed two.

And you can test your iOS, your WatchKit, even Apple Pay on the web, you can test on the simulator in Safari. Now the simulator returns dummy payment data. Its payment data is completely fake. It's not real and it's not useable for anything. So it's really useful for UI development and quick testing. But it's not particularly useful for end-to-end testing.

It's not real card data, and the simulator is just not representative of device behavior. You know we always tell you, please don't use the simulator of your sole way of developing, you have to test on hardware. But with Apple Pay that's not always feasible. Apple Pay is available in many countries, but not all countries. Maybe your developers work abroad, or you don't have a card that's eligible.

Okay, we're going to solve that today. We're going to introduce the Apple Pay Sandbox environment. The Sandbox is a brand new testing environment for Apple Pay and it lets you provision test cards directly onto real devices and the data that it returns is real payment data using these test cards.

So it's just like paying for something with a real credit or debit card in Apple Pay. It's really easy to use and it's really easy to set up. And you can integrate it into your QA environments, where previously perhaps you couldn't due to restrictions on production financial data.

Getting set up with the Sandbox is really straightforward. All you need to do is create a testing iCloud account at iTunes Connect. Now you can already do this for various other features, so this already exists today. You then just log into that account on your device. If you're not in a region that supports Apple Pay you can change your region to, say the US, or to Canada. And then you just use the test cards that are published at developer.apple.com. We have a list of test numbers that you can input. There will be provisions to Apple Wallet just like regular cards.

There's no developer setting or switch. Environment's a switch automatically, where you sign in and out of iCloud. Now you should still validate your apps with production cards before you launch. You still should do an end-to-end transaction. I think this is going to be a really great environment, a really great feature to help you test.

And actually if you're using Apple Pay on the web, which we talked about in previous session, initially you're only able to test it in the Sandbox, because we're not going to roll out production support until later, nearer the time we actually GM iOS 10. So the Apple Pay Sandbox today supports three networks, it supports American Express, MasterCard and Visa. And more networks will be coming on board overtime. We're also hoping that the Sandbox can be integrated in various payment processes.

So you can do that, it's available today if you're on iOS 10. So let's have a quick look at some of the stuff we talked about today. We talked about some new Wallet and Apple Pay API and features. Some of the new things that we've introduced over the past year and in iOS 10 that help host developers, card issuers and retailers. And we talked about Apple Pay and WatchKit.

I think Apple Pay WatchKit is really great. I can't wait to hail a ride directly from my Apple Watch without ever needing to pull out my phone. We also talked about Apple Pay in extensions. I think there's so much opportunity here to enable really compelling experiences, where users can pay for things without having to go into an app, straight from Siri, straight from maps, straight from messages.

And then we talked about testing in the Sandbox and the simulator. There's one thing we didn't talk about that's very big this year, that's Apple Pay on the Web. So, you can use Apple Pay as well as in apps, as well as in extensions, as well as in WebKit, you can now use it on mobile websites and you can use it on the desktop, on MacOS Sierra.

You can authorize payment in Safari using your Apple Pay device, both iPhone and Apple Watch. Now, we talked about this in the previous session. So if you're interested you can go to the website, check it out now. And if you want more information about anything we talked about today you can check our sessions microsite.

Now I did promise some contact information, and some other things. I promised you bank and co-brand private label inquiries. If you're interested in taking advantage of in-app provisioning or any of the features I talked about for co-brands and card issuers, you can email us here. And if you're interested in value-added service passes, you can visit our website, the links up here, developer.apple.com/ contact/passkit. And you can put in a request to use the value-added service signing certificates.

We have some related sessions, like I said, we just covered Apple Pay on the web. There's also a WatchKit session tomorrow, upstairs in Presidio, Designing Great Apple Watch Experiences. I think you should definitely go to that if you're interested in WatchKit. See how you can really enable WatchKit apps especially with the new changes on watchOS3.

So thank you so much for coming. Thank you for making Apple Pay great with your own applications. And I can't wait to see some of the amazing things you're going to build. And hopefully I'll see you back here next year to talk about even more cool things in Apple Pay. Have a great WWDC.