Hello.

Hello everybody, thank you for coming this evening. Last session of the day. We're here to talk about what's new in Wallet and Apple Pay. And there are three things that we're going to talk about. We're going to break today's session down to three sections. The first one is going to be a little bit about the Apply Pay experience.

Some of you might be familiar with Apple Pay, but we've also been quite busy this past year, so we're going to run through some of the new things we've been doing. Then we're going to look at iOS 11 and macOS High Sierra and we're going to talk about what's new with Apple Pay. And then, finally, we're going to look at some of the new API inside of Wallet.

Now, there are a few things we're not going to cover in this session. We're not going to cover getting started with the Apply Pay API and how you integrate Apple Pay with your payment processor. We have a lot of great resources for that, you can check out last year's WWDC sessions, "Apply Pay on the Web," and "What's New With Wallet and Apple Pay" 2016 for more information.

So, let's dive right in and let's talk about the Apply Pay experience. Now, hopefully many of you who've used Apple Pay either in a store, or in an app, or on the web, and if you have, you'll know that Apple Pay is easy, secure, and private way to pay.

And when we first launched Apple Pay in iOS 8, we supported payments within applications. Here's a good example. But, since then we've expanded Apple Pay to far more places. We've expanded it to Safari. You can now make payments from Safari on mac and on iOS. We've also expanded it to Siri. You can make payments now from within SiriKit.

Another great extension point we've added Apple Pay to is messages, you can write messages apps that can take advantage of Apple Pay directly from within the message's application. You can buy a movie ticket and send it to a friend without ever having to leave the messages app. And finally, we've added support for watchOS. You can make payments within watchOS on WatchKit. Last year, we also added support, natively on the new Mac Book Pro with Touch Bar. So, now you can make payments directly on your Mac without handing them off to an iOS device.

And hopefully you've also had a chance to see some of the apps that have been built on top of WatchKit. The Apple Store is a great example. You can buy accessories directly from your wrist. You just pick an accessory, pick a card, and you're done. Now, when we first launched Apple Pay it was only available in the United States, but since then we've been extremely busy.

In the past year alone, we've launched in over a dozen new countries. Here are all the countries that we're currently supported in. One country that I'm particularly excited about is Japan. In Japan, you can actually use Apple Pay directly on the Tokyo Transit System with your Suica Card. It works really, really well.

Another thing we launched last year after WWDC was Apple Pay for nonprofits. This is really interesting if you're a nonprofit and you want to take Apple Pay either within your application, or perhaps on your website. Here's an example from OXFAM in the United Kingdom. They're one of the largest nonprofits in the UK and they actually found that using Apple Pay reduced the time that it took to get a donation from 2 minutes to 10 seconds. That's a huge decrease. And as a result, they're seeing much better user experience and performance.

Now, if you're interested in accepting Apple Pay as a nonprofit, it's really easy to do. You can use it inside of your apps and on the web. And to help support you, we've added a new donate with Apple Pay button style. There's a very simple signup process. You can find out more about where this is supported and how to get started at the developer site.

Now, if you're not using Apple Pay, you might be wondering why should I adapt it in my app or on the web. Apple Pay is one of the best ways for users to pay. It has one of the highest customer satisfaction ratings of any wallet. But it's also the best way for merchants to be paid. I want to illustrate that with a little example of a typical product flow.

So, normally in the checkout process, we buy a product. We go to a website, we got to an app, we see the product and we add it to our cart. And then we go to checkout. And the first thing we normally have to do is we have to create an account, or sight in. And if I don't have an account, maybe I've got to like create one and then go to my email to verify it. So, I've left the site already. And then I come back and I've got to add my shipping address.

And then once I add my shipping address, well I shipped it to work, and my credit card uses my home address as my billing. So, now I've got to add my billing address. And I've got to type in my card details. Except, I left my credit card on the other side of the stage, so now I've got to go over there to get the CVV number on the back. And then I've got to review the transaction.

And then finally I can confirm and pay. So, it's not really surprising that if you've done any ecommerce work, conversion rates is one of the biggest things you encounter. Users drop off all the time during purchase. But, with Apple Pay, it's so much simpler. You just tap or click the buy with Apple Pay button, and you're done. All of these steps are coalesced into a single user experience. And this has some really dramatic results for performance.

Over the past three years, we've been asking merchants what they found with Apple Pay. And they've told us that they've seen between 2 and 5 times increased conversion rates with Apple Pay, that they've seen higher purchase frequency. And the checkouts move much, much faster. And a result of all of these, they see improved customer acquisition and satisfaction.

Users are more likely to become your customers, and they're more likely to be happy. I want to give you a few examples. If you are a freelance or a contractor, you might know about Intuit, they have an app and a service that lets you generate invoices. They took advantage of Apple Pay. You can pay your invoice directly. And they found that these invoices were paid 30% faster with Apple Pay.

And half these invoices were paid immediately, the same day they were received. I used to be a freelancer and that was unheard of when I freelanced. Another app that's had a lot of success is Indiegogo. They adopted Apple Pay so you can use it to pledge for items there and they've seen a 250% increase in conversion rate.

There are a few other benefits outside of conversion. Many merchants see a reduction in chargebacks. This is huge. If you deal with these, you'll know they can be very expensive and time consuming to resolve. And perhaps, most importantly with Apple Pay there's no need to handle or store credit card numbers.

This is huge. You don't need to handle you know regular credit card numbers, instead you're handling device-specific tokens. You also get a trusted user experience. Instead of going to five different sites and getting five completely different checkouts, you get a single UI that uses trust. Built directly in Safari or into iOS.

So, hopefully if you haven't adopted Apple Pay I've convinced you to go after this session and immediately start putting it on your site. So, I want to give you a few bits of advice on how you can perfect the Apple Pay experience. When you're thinking about designing for Apple Pay, it's important to think about three basic principles.

How can I make purchasing easier? How can I make purchasing faster? And how can you make purchasing clearer? And when you put these together, you get a great design and a great user experience. And if you've been to our website, you'll see we use three terms to describe how to best perfect these. One of these is something we call upstreaming. Another technique in our interface guide, we call defaulting. And a third technique in our interface guide we call streamlining. So, I want to run through each of these and I want to see how they can help.

Upstreaming is about accelerating single item purchases with Apple Pay directly on product pages. We're accelerating multi-item purchases with express check out. Let me give you an example. I live in San Francisco, so it is obviously very important that I have a constant stock of hoodies to wear. So, here is Lululemon's site, I can buy a hoodie, and you'll see that there is a buy with Apple Pay button directly on the product page. Placing the Apple Pay button on your product pages drastically increases conversions by several orders of magnitude. It allows purchasing immediately. And also, if you allow purchasing without creating accounts, as is done here, you'll get an even better performance.

Now, sometimes, guest check out isn't feasible. But there are some techniques you can use to help mitigate this. Firstly, you can write the account creation seamless with iOS and macOS. One of the ways that you can do this is through shared web credentials. This was introduced a few years ago and there have actually been some great improvements to shared web credentials in iOS 11. So, do check out the Safari sessions to find out more about that.

Another thing you can do that is new in iOS 11 is have native app autofill. iOS 11 will now autofill passwords within applications. And to take advantage of this, all you need to do is hint your UI text fields with the right UI text content type; password, email, etcetera. You can also create an account after payment using data the you gather from Apple Pay. So, the user's email, for example. You can create an account once purchase has happened.

Now, the second technique that I mentioned is defaulting. And this is about making Apple Pay the default payment option where possible. And you can actually take advantage of a new feature we're adding that I'll talk about in just a moment, that we call in-line set up. You'll see how that can make Apple Pay immediate, even if the user doesn't have cards on their iOS device.

The final technique I mentioned was streamlining. This is about making purchasing with Apple Pay quick and simple. It's about collecting the necessary information before checkout begins. If you need a size or a color, make sure you get it before checkout starts. And it's also about preferring customer information from Apple Pay. Don't ask for the user's email address yourself. You'll be able to collect it along with shipping information, billing information, and so on, directly from the Apple Pay sheet.

That brings me to the Apple Pay sheet. You may be familiar with it. This is what it looks like on the Apple Store. And I've got some general advice for when you're thinking about using Apple Pay and how to best take advantage of this sheet. One piece of advice is only to present and request essential information. Don't request information you're not going to use. If you don't need the user's phone number, don't ask for it.

Another thing to bear in mind, is that the screen estate is quite limited. There isn't a lot of space. So, you should keep your line items short and meaningful. It's not intended to be a kind of full receipt. The Apple Pay sheet is intended to be a summary. So, use these line items to explain additional charges, discounts, tax. Let me go back to the Apple store and show you what I mean. Here you'll see I'm buying an iPad and here in the sheet I see a subtotal, shipping, tax, and a total. So, very top level.

Now, sometimes you don't know what you're going to charge. Perhaps you're a ride sharing company and you don't actually charge the user until the ride is over. Or perhaps you want to add an optional gratuity that the user picks at the end of the transaction. You can use pending items to achieve this. It's important to clearly disclose that these pending items are additional costs. Here's an example, we just mark the type as pending, and it will show up on the Apple Pay sheet without an amount.

Now, the total amount has to be nonnegative. It doesn't really make sense to have a payment that's for a negative amount. But it can be pending. So, you can have a total that is not known at the time the time the transaction is taking place. It's very important for the total amount to use the business name that will appear on the card statement.

It's important for two reasons. Firstly, users want to be able to reconcile what appears within the Wallet application and on their bank statement with what they paid. Also, now that we support the new Mac Book Pro with Touch Bar, we actually show the merchant's name on the Touch Bar itself. So, again, it's important to make sure that it matches what the user expects.

Now, one use case that's grown over the last year with Apple Pay is subscriptions. For example, news sites that want to use Apple Pay on the web to take subscriptions. You can do that, but there's some advice I'd like to give you. It's important to clarify the subscription details prior to payment. It's important to include line items that reiterate the billing frequency.

And for variable subscriptions use pending items. Let me give you an example. I have a little side job, a little app I'm working, it sells avocado toast to naïve millennials. Here it is. It's a subscription, of course, because that's what's getting all the funding, so I'm told. And here's my Apple Pay sheet.

And you'll see that I have here, weekly service, so in my line item I'm clearly indicating the length of time that the subscription is for. I'm also noting a discount. You can do that in the sheet. You can note introductory discounts. And then what will be charged at this current time. And then you can use the same information, the same payment data you get from Apple Pay to make subsequent charges.

Now, sometimes there are certain types of subscriptions where the cost varies. Maybe you're a meal ordering service and the number of meals that the user gets varies week by week, month by month. Use pending amounts for variable subscriptions. Another thing to bear in mind is that if your subscription is variable, and the user changes their plan, for example, you only need to show the payment sheet if a change is going to result in additional fees. If the user decreases the cost authorization is necessary.

So, that's the payment sheet. I want to talk now about buttons. Specifically, I want to talk about the Apple Pay buttons. Please, use the built-in Apple Pay buttons. Don't create your own. A couple reasons why you don't want to do that. Firstly, the Apple Pay buttons are localized to any language that the user can choose.

They're also vectors, so they're completely scalable, so you don't need to worry about them not looking right. And they're available in a number of styles. We first introduced the native buttons in iOS 8.3. So, you can target 8.3 and above, which is nearly the entire in store base right now.

And in macOS 10.12.1 and iOS 10.1 we made it a little easier on web. We used simplified CSS styles. Let me give you some examples, some code examples. So, here is the not very exciting code in Swift. PKPaymentButton is a UI button subclass. You just provide a type and a style. We have buttons in black, white, and white with an outline. Let me show you the same button in HTML.

So, this is the new CSS style it was introduced in iOS 10.1. There's a WebKit appearance style Apple Pay button, and a type buy. Now, we have four button styles. Let me show them to you. On the left are the Swift symbols, on the right the CSS names. We have a plain button.

We have a buy with Apple Pay button. We also have a Set up Apple Pay button. We'll see how to use that shortly. And new in iOS 10.2 and macOS 10.12.3, we have a Donate with Apple Pay button if you're a nonprofit. Now, obviously as a nonprofit, you probably want to target all versions of iOS or macOS before that. In that case, you can just fall back to the regular plain button.

So, that's the quick update on Apple Pay over the past year and a review of some of our best practices. And I want to tell you the exciting part of the talk. Which is what's new with Apple Pay. When we thought about what we could do this year with Apple Pay we thought how could we make a best in class conversion even better. And how could we help users resolve common problems that they told us about. And finally, how can we help make getting started with Apple Pay fast and easy, so even more of your potential customers can come with cards already on their device.

So, I think you'll see that the next few slides will show some of the ways we're going to achieve that. The first way is through Set up Apple Pay. Now, starting with this version of iOS, we strongly recommend that you show the Apple Pay button for all devices that are hardware capable with Apple Pay. And you can choose the Set up or Buy button stars that suit your needs. If the API tells you the user doesn't have any cards, you could optionally display Set up. If it makes more sense in your design to stick with Buy, you can do that.

But we've introduced something to really help with that. And the reason for this new advice is because now we support inline set up. Apple Pay Set up is now offered automatically. If you try to present an Apple Pay sheet on previous versions of iOS, if the user didn't have any cards, that would actually be an error. Actually, you wouldn't be able to present the view controller.

Now, you will actually present, or present Apple Pay Set up. And most importantly, users are returned to the purchase as soon as set up completes. Which means that it's actually faster than a manual check out to add and Apple Pay card and complete the purchase. I want to actually show you what that looks like and how quick it is.

So, here is the Apple store, on their website this time, not their app. And we're going to see what happens when we try to tap the Buy button without cards. It's going to go quite quickly. Okay, so we get a little dialogue to add a card. We're going to add a card.

This is a card that I've already used on another phone, so it's already there. I just enter my security code. Now we're going to add the card. Read the terms thoroughly [laughter]. And then we're going to add it to Wallet, activate the card. And boom, we're done. Now what's going to happen? Immediately we're going to go to the Apple Pay sheet so we can continue the payment.

This is great. That actually took less than 30 seconds, which is still much faster than manually typing my card number and all this information on the regular Apple Store checkout. And again, this happens completely automatically. You don't have to make any code changes. There's no new API. All you have to do is present Apple Pay if the user doesn't have cards. So, I recommend you will go and take advantage of that.

Now, if you were at the keynote, or watched it online, one thing that might have got you quite excited was Apple Pay Cash. Apple Pay Cash allows you to send money to fellow users of iMessage. And the money you received is kept inside Apple Pay Cash. Now, Apple Pay Cash can be used in stores, physical stores. But it can also be used within apps and on the web, just like any other card.

In fact, if you can process credit cards, you can process Apple Pay Cash. We will have more information on exactly what you need to do very shortly on our developer site. But rest assured if you take credit cards today, there will be no real work to take Apple Pay Cash. There are a few things you should know about Apple Pay Cash if you're in in-app or website developer. Apple Pay Cash is a stored balance card. You have a balance.

So, let me give you an example. My business model for subscriptions wasn't really working, so I've switched to an on-demand model where we deliver the avocado toast directly to your seats. And so, now I'm just going to one off charge. But I'm trying to make this payment with an Apple Pay Cash card.

Unfortunately, I don't have many friends and they haven't actually sent me any money. So, you'll see this UI is new. It says insufficient balance. The important thing to note here is that we're now using the total amount that you supply to determine whether the payment can happen with Apple Pay Cash. That means that it's important that your total reflects what you intend to charge, Apple Pay Cash is only available when your balance exceeds the total being requested.

Now, if you're not sure of the total, you can use a pending amount. Using a pending amount bypasses this behavior, we will allow the payment to happen regardless, of course bear in mind it may still be like any stored value card, rejected if the user doesn't have a balance.

Let's talk about some new API that we've added briefly. One use case we've been asked a lot about, particularly in Europe is about limiting Apple Pay to specific countries. Sometimes this is required for regulatory compliance. Now you can. You just pass in this new property, supportedCountries, and you just set the countries that you want to limit to. Bear in mind that like some of our other API that exists today, that lets you say limit to credit or debit cards, this isn't available on every single card. So, just bear that in mind. For more information about that, check out last year's session.

Now, I want to talk about the biggest change that we're making to Apple Pay and that's to do with error handling. Sometimes, things can go wrong with Apple Pay, I regret to tell you. And it can be problematic to communicate this to users today. We've had feedback from developers, we've had feedback from users. What are some examples of this? The payment instrument failed to process.

The billing address didn't match what the bank had on the card. The email address was invalid. The postal address had an incorrect zip or postal code. The telephone was missing an area code. And we can divide these up into two categories. We can divide them up into what I call fatal errors and nonfatal errors.

Fatal errors are errors that can't actually be resolved by the user there and then. And you need to handle them outside of Apple Pay. But they're also often not preventable. What's an example of that? The user has exceeded their credit limit. You're not going to be able to solve that within Apple Pay, you're going to need to go to your bank to fix it. But many errors are nonfatal, they can be resolved by the user. And they can be handled within Apple Pay itself. And sometimes they're foreseeable and preventable.

But in previous versions for iOS, it was a little tricky to communicate what exactly was wrong. Whenever a payment is complete in the native API, you would return a PKPaymentAuthorizationStatus Enum. You'd have a similar Enum in the web API. And these have no specificity. You can only say invalid shipping address, invalid billing, invalid contact.

So, the user's not really sure what went wrong. But even if the user could figure out what went wrong, they weren't actually able to edit existing values. So, they'd have to go and pick an entirely new address or type one in. And that's not a great experience. So, we are changing that. And we're changing it in three ways.

Firstly, we're going to introduce some new guidelines to better handle user data. We've also introduced a brand-new UI for users to input and edit data. If you've tried out the iOS Veetle, you might have seen this. And finally, and perhaps most excitingly for you, we've introduced new API to let you communicate precise errors about what went wrong. So, let's go through these one at a time.

Let's talk about handling user data. This is a fun one. Contact information on iOS and macOS can come from many different sources. It can come from iCloud, it can come from contacts manually typed in. But it can also come from LinkedIn, Facebook, VIDO, [inaudible], it can come from anywhere.

And you shouldn't expect this information to conform to your business logic. What do I mean by that? Here is an example of a postal address. It is for the Apple store in Boston, which is a very nice Apple store. You should visit, say hello, tell them I sent you.

Now, the address may look correct to you, and if you wrote this on an envelope and dropped it in the mail, it would get there. But it's actually got a few problems that could trick an unwitting developer up. Some of them don't really seem like big problems. Street is abbreviated. Seems like most systems should be able to handle this.

Some problems are a little more serious. If you paid attention in civics, you may have noticed that Massachusetts is misspelled. It has two T's. I lived there for four years. I still can't spell it right. Now, if you were doing an exact string match on the state, this might cause you a problem.

Another thing that's a little odd is this zip code. It says zip plus 4, which is a regular zip code with 4 additional digits for specificity. If your backend system was only expecting 5 digits, if your like database was only going to accept 5 numbers, you might hit some problems ingesting this.

Country is another example where you might trip up. This is a localized country name. There's actually another field that the user doesn't see called country code. You should use that instead, because country code is always going to be accurate. This is in the language of the user. So, you may well be like, OK I'm going to string match United States, USA, all of its variants.

Well, surprise, your user is French and this field is actually Etats-Unis and you can't now ingest it. So, don't use country, use country code. The phone number also could trip you up. It has some dashes. So, if your system was only set up to accept numeric digits you could have some problems. But it's also got a country code, which could trip you up.

So, be prepared for fuzzy input. Don't force the user to comply with your business logic. There are lots of techniques you can do to validate addresses. For example instead of using the state field directly you can infer it from the zip code. That's an example. There are lots of tools to help you pass phone numbers, both tolls available within iOS and also third party tools.

You might wonder, well why doesn't Apple Pay do this for me? Well, your business logic may actually differ from another merchant's business logic. One merchant may only accept phone numbers with a country code. Another merchant may only accept phone numbers without. And you don't want the user to like have to create two different addresses, two different phone numbers.

So, don't force the user to comply with your business logic. Now, we are going to help you a little bit. There's some new API's within the context framework to support worldwide addresses. The example I gave for you was from the US, but these problems actually happen throughout the world. There are new fields in contact for something that's called supplementary sub-locality. That's very applicable in China.

In Japan, now, within Apple Pay you can request phonetic name in addition to regular name, another very important addition there. But despite all of these, and despite your best intentions, things can still go wrong. The USPS may be able to deliver this to Santa, but I cannot. I know not where he lives.

So, what are somethings that can go wrong? The phone number could just be missing digits entirely. The postal code and address don't match. The email address is misspelled. The address is otherwise unusable. And so, we're going to introduce some new API to help you out with that. And we call it custom errors.

Custom errors let you gracefully handle invalid or incorrect data in Apple Pay. And they also let you display custom error messages. Your own error messages directly in the Apple Pay sheet. You can direct the user to specific fields that need correction. Let's go back to my delightful avocado toast app. The delivery wasn't working, so I've gone back to subscriptions. We're going for our series A funding.

And you'll see here, I've got a shipping address error. Shipping address incorrect. And that's not very clear, but if the user taps in, you'll actually see, now we have a custom error that was provided by the application. Your zip code doesn't match your city. And if you go through even further, we'll actually highlight the individual fields for the user to correct. You'll see an example in Jon's demo, shortly.

Now, one unfortunate side effect of this is that we've had to deprecate a little bit of API. All of our completion handlers in the past in Apple Pay took, as I mentioned this Enum. Well, we didn't really want to have hundreds of different Enums for each type of error. So, instead we're replacing them with an object. In this case, this is the delicate callback when a payment is actually authorized and you return a PKPaymentAuthorizationResult.

So, we have to do little bit of renaming. Now, this result object contains a status and it contains an array of errors. Now, the status is the status that you're used to. The payment was successful or not. If you, for example, have a successful payment, you simply return a result with no errors and a single status set.

But the errors themselves just standard NS errors describing what went wrong. Each error represents an individual problem with a payment. And you can chain errors together. So, you can have more than one. If the user's email is wrong, phone is wrong, shipping is wrong. You can just do it all in one go.

Now, you use NSError codes to indicate the issue and User Info Keys on NSError to provide specific resolution steps and information. Now, creating NSErrors can be a little bit laborious and so we've got some factory helpers to assist you here. Here's an example in Swift. I'm creating a payment shipping address invalid error.

And you'll see that this takes two properties at two parameters. It takes a CN contact key indicating the field that was wrong. So, in this case, the error is the user put a wrong country in and we only deliver to the US. So, I say CN postal address country key. And then the localized description. This is a localized error that you provide that will be displayed in the sheet.

Now, in ES6 and JavaScript, obviously NSError doesn't exist. So, we have a new type called Apple Pay Error. You can check for the existence of this type to determine whether Safari supports this new API. And here you provide the type of error, shipping contact is invalid. The field it relates to, country, and your localized description. And most of our delegate callback have changed. So, here's another example, didSelectShipingContract, and it takes an object, PKPaymentRequest ShippingContactUpdate.

Now, like for like APIs are available in Safari 11. Safari 11, only on iOS 11 and macOS High Sierra. It's not support on Safari 11 running on older versions of the operating system. Now, because JavaScript is a little more forgiving when it comes to API's we haven't had to actually make a deprecation here. The existing completion functions have nearly been overloaded.

So, here is the old API, you'll see we passed in individual items, the total, the line items, the status. And the new API, we simply pass in an object. So, if you're actually writing Apple Pay on web, this is a pretty straightforward change for you. Now, if you are writing Apple Pay in application, I want to show you that it's really not that much work to implement this new API. And to do that, I'm going to ask Jon to come up and he's going to give you a quick demo of how to migrate an Apple Pay App. Jon.

Hi, everyone. I'm Jon and I'm going to show you how easy it is to update and existing Apple Pay project in Swift, to the new API. So, I'm going to be going through four things today. First, I'll take a look at an existing project's code and see its current implementation. And if you've worked with Apple Pay before, most of this stuff will be familiar to you already.

Second, I'll deploy the app to the simulator and interact with the Apple Pay sheet as if I were a customer of your app trying to ship an item to one of my friends. The next thing I'll do is I'll update the code that we have with the new API and show you three different errors that we've introduced this year. And lastly, I'll deploy the app again to the simulator and show you the differences in behaviors from the old Apple Pay sheet and the new Apple Pay sheet. So, let's take a look at what we have.

So, as you can see, our app is pretty simple. It has an image of the item that we want to purchase, as well as a Buy with Apple Pay button. So, let's jump into the code. The first function we have is viewDidLoad and in here, we're creating a PKPayment button, setting the type to buy and the style to black, as well as adding it to the view. And in the add to view function, we're adding various constraints to it as well as setting the target, when I click it to this next function, startPayment. So, let's take a look at that.

So, here the first things we do is create a few PKPayment summary items, as well as a PKShipping method. And then the last thing is create an array of those objects that we'll later pass in to the PKPayment request. So, let's take a look at the payment request. Here, it's pretty simple. After we initialize it, we set the payment summary items to the items that we created before, as well as set various properties, such as a merchant identifier, the capabilities. Etcetera, etcetera.

The last thing, this last line is probably the most important. It's required shipping contact field. And this is a new property in PKPayment request. And here it takes in a set of PK content fields and in this case, the developer is requesting the user provide an email address, as well as a postal address. So, the last thing we do in this function is create a PKPayment authorization controller, with this payment request that we created. Set the delegate to ourselves and present it. So, that's pretty simple.

So, let's take a look at the protocol. The first function we have, it's a didSelectShippingContact function. So, this gets called whenever the Apple Pay sheet first comes up, as well as whenever a user edits one of their addresses, or selects a new address. And you can tell that this is the old API because this completion block takes in a PKPaymentAuthorizationStatus Enum.

Another thing to note is that this contact information is actually redacted, so you don't get information like the email address, the phone number, or the street until the user authorizes the payment. So, let's see what we have here. So, we're doing some basic validation and in this case, we're just checking if the state is valid. And if it's not, we set the status to invalidShippingPostalAddress. Otherwise, we set the payment status to success.

The last thing we do, it's called the completion block, with that paymentStatus, as well as the same shipping methods, and the same payment summary items. Of course, you can update the shipping methods and the summary items if you needed to. But in this case, we're just passing the same ones.

So, the next function we have is the didAuthorizePaymentMethod. And this gets called after the user authorizes the payment, using Touch ID, or with Passcode. And another thing to note is that this PKPayment object contains a property shipping contact, with the full contact information. So, you're given the email address, the phone and the street that you were not given previously. So, we hope that you can validate the full contact information in this method.

And for simplicity sake, all we're doing is checking the email, but you can do more of course. And if the email check fails, we set the payment status to the Enum invalidShippingContact. And if it succeeds, we set the payment status to success. The last thing we do is call the completion block with that status.

So, let's see how this works after we deploy it and interact with the Apple Pay sheet in the simulator. So, the app comes up. We tap the buy with Apple Pay button. And the Apple Pay sheet comes up. So, let's say I want to ship this to my friend Sarah.

After I select shipping, I can select add shipping address and as you can see, this is the new UI to add a shipping address. So, you can either enter it manually or search one of your contacts, or use one of the suggested locations that the Apple Pay sheet provides for you.

In this case, I'm just going to select my friend Sarah. She lives in Hawaii, so it might be a little bit, there might be some problems with the address. Well, let's see. Of course, there's an error. And you can see that the text is red so the user knows that there's something wrong with the address. But it's not really clear where the issue is. As I look at it, the street seems fine.

Hawaii is a valid state. Everything looks fine. And so, if I select that, again, there's not a lot of information on what's wrong with the address. I know my friend, Daniel, likes this item as well. So, he lives in California. So, let's just see if we can ship it to him.

After we got back, it looks like there's no more error. So, there must have been something wrong with Sarah's address, but it wasn't clear to me what was the actual issue. So, let's try to authorize this payment by hitting the Pay with Passcode button. The Apple Pay sheet shows that there's an error with the contact. Again, the text is highlighted red. And if I select that, there's no clear text showing what's wrong with this contact information. It could be the percent sign, it could be just I don't like an iCloud.com email address.

So, let's just select Daniel's real email address to see how that works. After we select that, we hit Pay with Passcode and the payment succeeds. Okay, so that's good. But as a user, it was really difficult to figure out what was wrong with the address that we had previously. So, let's implement the new APIs that we have.

So, the first function that we have is a didSelectShippingContact method. And here it takes in a PKPaymentRequest ShippingContactUpdate object. The first thing we want to do is we have a local variable of the update before and we don't initialize it yet. We'll initialize it afterwards, after we check the errors that we have. The next thing we do is create an array of errors that we'll append to as we validate the address.

So, similar to before, we're checking if the state is valid. And if it's not valid, instead of setting the status to an invalid shipping address, we'll append an error, a new type of error. A paymentShipingAddress UnserviceableError. And in here, all it takes is a localized description. And in this case, we're saying that we're unable to ship to this state.

Let's see, we'll add another check that we didn't do previously, which is check if the zip is valid. And this is another type of error a paymentShippingAddress InvalidError. And this takes in a key, a CNPostalAddress key. And in this case we're taking a CNPostalAddress postal code key, which tells PassKit to show where the error is while the user tries to edit their address.

Again, this takes in localizedDescription, the zip code doesn't match the city. Yeah, so let's continue. And the next thing we do is check if the errors array is empty. If it is, we'll initialize our update object with the paymentSummaryItems, unchanged. Otherwise, we'll initialize the update object with the errors as well as the payment summary items and the shipping methods. So, the last thing we do here is call the completion block, with this new object.

So, let's fix our didAuthorizePayment function. So, this is the old code that we have, so we can comment that out. And the first thing we do, similarly to before, is create an array of errors that we'll append to. In this case, we're checking one thing, which is if the email address is valid or not.

And if it's not, we'll append another type of error, a paymentContactInvalidError. And instead of taking a CNPostalAddress key, this takes in a PKContact field key. And here, we're passing and email address so that it can show in the correct location. Okay, and that takes another localized description that will be presented on the Apple Pay sheet.

Similarly, we're checking if the errors array is empty. If it is, we'll set this status to success. Otherwise, we'll set the status to failure. And the last thing we do is call the completion block with initialize PKPaymentAuthorizationResult, using that same status as well as the errors that we created. So, let's see how this works after we deploy it.

After the app comes up, we'll hit the Buy with Apple Pay button once again. And immediately we're presented with an error. The app doesn't ship to this shipping address. So, this is one of the new errors that we've introduced this year. And there's a shipping unavailable text underneath out contact. After I select that, there's text underneath our contact saying unable to ship to this state.

So, this is pretty clear to the user, saying that the app doesn't support shipping to Hawaii. Let's try to ship this to my friend, John Appleseed whose shipping address is in Cupertino. After I select that, an error shows up saying that the zip code doesn't match the city.

And if I select that address, the zip code is highlighted in red. And because I know that 12345 isn't the proper zip code to Cupertino I can fix that and write 95014, hit done to save it. Go back, and I fixed all the contact information, or the address issues that I've had.

Again, let's try to pay with Passcode and see that we have an error with our contact information. After we click that, we see that there's an invalid character found in the email, which is the percent sign. So, as a user I can edit this email address to remove that percent sign, or I can just select another email address. So, I'll select John Appleseed's email address, at mac.com.

I went back, hit pay with Passcode, the payment should authorize. And that shows you with the new APIs that we introduce in iOS 11, you have the power to give more feedback to the user when dealing with addresses on the Apple Pay sheet. And we hope that this creates a better user experience, when users are using Apple Pay within your apps. Thank you.

Thank you Jon. I hope you all go off and take the time to update your apps. I want to talk briefly about what's new with Wallet. If you've downloaded [inaudible] of iOS 11, you might have noticed one major thing that's new with Wallet, it looks a little different. It's a little brighter.

There's also, if you haven't found it yet, a new mass deletion management interface for your passes. This new color scheme means that it's probably a good time for you to revisit your past designs. Take a look at them, make sure that they look great. If you never updated them to have watch assets or 3x assets, may be a good time.

Well, I also want to give you a quick update about NFC passes. NFC passes are regular passes that let you send customer information over NFC. Starting in iOS 11 we are only going to support a more secure type of NFC pass that we call encrypted NFC passes. If you'd like to know more about NFC passes, you can check out last year's session. You can also go to our developer's site and find out more, and register to take advantage of them.

Now, there's one minor new feature in Wallet this year for passes. And that's sharing. Much requested feature, passes can now be opted out sharing. This is useful for single use items like loyalty cards of tickets. It's really easy to take advantage of. It's just a top level JSON key in your pass JSON. Here it is sharingProhibited.

So, your gift cards, your loyalty cards. You set this to true and the user can't share it via airdrop, iMessage. This is a convenience feature, not a security feature. Obviously, users can still share in other ways. It won't be supported on older versions of iOS. But it's good if you need a good reason to not allow the user to share for pure experience reasons.

That's what's new with Apple Pay and Wallet. We saw some guidelines for building best in brands Apple Pay experiences, new API for handling complex errors, and new ways to share interact passes in NFC. And for more information on any of these things, you can check out our developer site. There's something else you also might want to check out and I suspect a lot of you in the room are extremely excited by.

And that is the Core NFC framework. Now, you can read NFC tags on supported hardware. Now we have a special session for this. It's online only. It's available now. It's just search introducing CoreNFC on the WWDC site, check it out. That's everything from us for this year. I hope you go out now and have a great beer bash and I hope we'll see you next year to talk even more about Apple Pay and Wallet. Thank you very much.