So, hello, everybody! Welcome to WWDC and welcome to learning about Apple Pay within applications. Now my name is Nick and I'm a software engineer on the iOS Apps and Frameworks team. I'm going to be joined here by Rachel and we're going to be talking all about Apple Pay! Now, hopefully you are all pretty familiar with Apple Pay, perhaps you have even tried it out. Maybe you have gone into a store around here and bought something. But you can also use Apple Pay inside of your own applications.

That's what we're going to talk about in today's session. Now it's an extra long bumper hour long session. Set your watches to silent. You won't be standing up. And we're going to run through four main sections today. So first thing we're going to talk about what Apple Pay actually is.

We're going to talk about how you can use it in your app and more importantly, why you'd want to use it in your app. And then we will move on to architecture, how does that Apple Pay actually make a payment from a technical perspective, what's happening there? What's going on? Following on from that, my colleague Rachel is going to come out and talk to you all about design.

How to get your apps ready for Apple Pay and how to make them look and feel really great. And after all that I think we will be ready to dive into Xcode and we'll actually look at how we can in just a few dozen lines really quickly and easily get Apple Pay set up in our own applications. I think we will have a lot of fun. Let's dive right in.

What is Apple Pay? And how are you going to use it inside of your app? So Apple Pay is an easy private and secure way to pay within applications as well as contactlessly, and it allows for one touch payments and you can use it for physical goods and services. So here's an example from Groupon.

Apple Pay has loads of benefits, both for you as developers and for users. So for users, Apple Pay is easy. You don't need to reenter any payment or contact information. You don't need to, like, remember the password I created for that sites months ago. It's all there, ready for me.

And it's also secure. I'm paying using Touch ID. It's really great, and most importantly, it's private. The card number isn't exposed to the merchant. Instead, you are sending a device number along with a unique token that's valid only for that purchase. So it's really secure, and really private.

And all of these things combine together to bring many benefits for you as well as developers. So because you are not getting real card numbers, you don't need to handle them. If you have worked on e-commerce before, I'm sure you know of all the problems you have handling, like, actual card information. And you will also see higher conversion rates and faster checkouts because Apple Pay is so easy to use. It's so easy that you don't even need to onboard your users. They can just open up your app and immediately start purchasing without needing an existing account.

And most importantly, users really love Apple Pay and they love apps that use it. They love taking advantage of it. And you don't really have to take my word for that. We went and spoke to just a few of the hundreds of apps that are already using Apple Pay on the store and they have seen some amazing successes. So first of all, I want to talk about StubHub. They have a great iPhone app. You can buy event tickets directly on the phone. They integrated with Apple Pay and they found that Apple Pay users transact 20% more frequently than regular customers. It's a great result.

Another app that's seen really great things from Apple Pay is OpenTable. You should try to use this app this week. You cannot only book a reservation but you can go into a restaurant and pay for your meal directly on your phone at the table. And when they integrated that product with Apple Pay, they saw transaction growth of 50%.

But it gets even better! We also spoke to Staples, Staples have a really nice app you can buy all of your office supplies directly from your phone and they saw an increase in overall conversion, that's the percentage of users who became paying customers of 109% with Apple Pay! So these are really impressive figures. App developers are loving Apple Pay. We spoke to Joe Einhorn, the CEO of Fancy. He said Apple Pay is not only driving more purchases but activating our biggest spenders.

I can also tell you that iOS users of Fancy out spend all over mobile platforms combined by a factor of two to one. These are customers would really like using Apple Pay to buy things and they want to buy lots of things. So it's great for your apps.

Now, some of you might be thinking, well, Apple already has a mechanism to allow apps to purchase things inside of the app and that's an In-App Purchase. Where does Apple Pay sit with regard to In-App Purchase. There are a few differences and I want to run you through them now.

One of the main differences is where they are actually located in the SDK. So Apple Pay lives inside of the PassKit framework whereas In-App lives inside of StoreKit and they are different code bases and you also use them for different things. So for Apple Pay, you use it for physical goods and services. What do I mean by that, I mean things like gym membership, ride sharing, grocery delivery and buying stuff in a brick and mortar store. Physical things. Where In-App Purchase is used for in-app content and functionality, in-app currency, services, digital subscriptions.

Another really big difference is who is responsible for processing the payments. When you use Apple Pay, you will process the payments yourself through your own payment platform, whereas when you use In-App Purchase, Apple processes the payments on your behalf and sends you the money along with the rest of your app sales on a monthly basis. SO there is a little difference there.

They're also subject to slightly different App Store guidelines. If you are interested in that it's Section 29 for Apple Pay, Section 11 for In-App Purchase. Got a few different guidelines over what you can and can't do. So do check those out Now Apple Pay is available on all of our devices that has a Secure Element chip.

So the Secure Element is this hardware chip that's dedicated to securely storing your card information. And this is available on the iPhone 6, the iPhone 6 Plus, the iPad Air 2 and the iPad mini 3. So all of these devices can support Apple Pay. And until recently Apple Pay was available in the US, as we announced yesterday it's also coming to the UK very soon. But we do have long-term goals for Apple Pay. So if you're a developer not from either of these countries it's still well worth thinking about how Apple Pay might integrate into your own application for the future.

So that was a quick overview of Apple Pay. Hopefully I have managed to convince you that Apple Pay is well worth using in your own app. So now I want to answer a few questions about the architecture of Apple Pay, how payments are actually made from a technical perspective.

So Apple Pay, the very first thing you need to do is create a Merchant Identifier. We require this and it uniquely identifies you as a merchant. Now, you can set your Merchant Identifier up on the developer portal or through the Xcode capabilities window and it's backed by a private key in a certificate. It's very similar to some of the other identifiers we have on iOS, like push token identifiers, or pass identifiers for the Wallet App.

Now we use this certificate to security encrypt the payment information that we generate so it's unique to you as a merchant. Nobody else can decrypt the payment information, it's just another great security benefit of Apple Pay and we recommend that you style it like a standard reverse DNS format, like many of our other identifiers, beginning with merchant. So here is an example we are going to use later in out sample app. This is the very first thing you need to do to use Apple Pay. Once we have a merchant identifier, we're actually ready to get Apple Pay up in our app.

The first thing you do is display what we call the payment sheet which is vendored by us and it summarizes all the charges that your app is going to want to make. The user then Touch IDs to authorize and your app will receive a payment token in response. Now a payment token contains all the information you need to charge the payment. It's encrypted using your Merchant ID certificate. So unique to you, only you as the developer can decrypt it.

And then you can validate this and send it for processing and display a success sheet in your app. Thats a lot of information so let's look in more detail. Little flow here. I have broken down they system into two components iOS and the Secure Element. Remember the Secure Element is the unique hard chip that security stores your card information. So first, your app will display your regular checkout flow and you will ask iOS whether the user has any Apple Pay cards available. Because if the user doesn't have any Apple Pay cards available, or the device doesn't support it, you want them through your traditional checkout flow.

Now assuming they do, you will then want to present the Apple Pay sheet, and you will then check or rather iOS will check whether the Touch ID is valid. Now, assuming it is valid, we will actually pass some information down to the dedicated Secure Element, which is going to securely wrap all of this payment information up, this includes the cryptogram which is an encrypted piece of data required to make the payment.

It's then going to send it to our servers. Now on our servers it just gets rewrapped using your Merchant Identifier. So that's all we're doing. This is because we don't want to ship your certificate in the app, right? So our server reroutes the payment, and encrypts it uniquely to you and it's passed back up through the system where you can then send it for processing. Now, assuming the processing is successful, you can dismiss the payment sheet and display your own confirmation screen.

I think many of you might be wondering, well, that's all very well and good, Nick, but how do I process the payment? How does that actually work? Let's talk about that. Let's talk about how you can get your money. It's probably a subject close to your heart. So there's two way to process Apple payments. The first one, and the one we recommend for most of you, is to use a payment platform.

The payment platform can handle this decryption and the understanding of the cryptogram on your behalf. You, when you sign up, you provide them with your Merchant ID and certificate and they can decrypt it for you and you simply send them a payment token. And some payment platforms actually provide native iOS development kits in Swift or Objective-C. So you can really easily get up and running. It's because of that, we think it's the preferred option for most developers.

And many, many payment platforms support Apple Pay already. Here are just a few. There are many more. We have a list on our website. These are in the US. Chances are maybe you are already using one of these. And a number of UK payment processes are already set up to support Apple Pay. So if you are in the UK, you can go and talk to your payment processor today.

Now, like I said, there's another way, and that's to process the payments yourself. Now, we recommend this if you are experienced working with payments, and you have some existing payment infrastructure, and if you do this, you are going to decrypt the payment token on your own servers and then you are going to send the underlying cryptogram, that the Secure Element generated to your merchant acquirer, your acquiring bank.

If that didn't make any sense to you, again, we only recommend this if you've got existing payment infrastructure and we're not going to cover decrypting the token in today's session. However if you do want to learn more about this we've got some documentation on the website, search for payment token reference and we will also have staff in the labs today and tomorrow who can answer any questions you might have about processing the payments yourself.

Okay. That was a bit of a whistle-stop tour of how to use Apple Pay, how it makes payments. I think we are ready to look at the actual iOS side of things and the very first step is to look at design. It's very important when you use Apple Pay to make sure that your app takes as advantage of what we're providing and designed in the best way possible. And to talk more about that, I would like to ask Rachel up, to run you through how to get the best user experience of Apple Pay. Rachel?

Thanks, Nick. [Applause]

Hi, everybody, I'm a User Experience Evangelist at Apple and I'm here today to hell you how to create the optimal experience, using Apple Pay in your apps. Now, as Nick said, customers love Apple Pay, because it makes shopping easy. And as a merchant, that's great for you, because the easier it is to buy something, the more likely you are to make a sale.

Now a person's desire to buy something can be fleeting. So any obstacle that interferes with that transaction flow could compromise the sale. The great news is that Apple Pay will provide everything you need to complete the transaction, so you can eliminate a lot of the obstacles that people experienced today. There is no need to make people set up an account before they have even bought something. And I don't know anyone who likes looking at lengthy forms and filling them out.

And you don't have to worry about outdated billing or shipping information interfering with someone buying something. I recently moved, and any time I go to make a purchase, if the app isn't using Apple Pay, I have to go through that tedious process of updating all of my billing and shipping information. And if I'm short on time, or just not in the mood to fill out a bunch of forms, well being I will just walk away, rather than completing that transaction. Let me give you an example of how this looks without Apple Pay.

So let's say my dog needs a new collar. My friend told me about this store that makes really cool dog stuff. I downloaded their app, I'm going to check it out. Oh, the first thing I have to do is sign up? Well, my friend promised me the dog stuff is cool, and this picture is really cute of this dog. So I will go ahead and do it. Even though I'm probably going to get some email newsletter I didn't want now.

Ugh! And now the next step is create an account. I haven't bought anything yet and I'm not even sure I'm going to buy something. So this is the point at which I would normally just walk away entirely from this app, but since you are all here, we will go forward. I will fill this all out.

Finally, I find a dog collar, and this is great. My dog is going to look awesome in it. So I'm going to start the transaction process. Okay, first billing information. Lots to type there and I happen to live in an apartment so I have to find that number sign on the keyboard to go with my apartment number.

And I want it to ship to work instead of home and so I have to type in all of this information as well. Okay shipping options. Okay, okay, I'm going to pick one of those. And finally, here is where I have to pull my credit card out of my pocket and type in all of this information. That's six taps and a ton of typing. There's plenty of opportunity in there for me to get distracted, interrupted, frustrated, and walk away.

And if I was looking for this dog collar while I'm on my morning commute, well, I'm not really excited about pulling my credit card out when I'm standing on a crowded train platform. It's just not going to happen. Here's how much faster this can go with Apple Pay. Launch the app. Find a product. No account setup necessary. Tap the Apple Pay button. Put my thumb down for Touch ID, done! Two taps. No typing. That is fast.

So thanks to Apple Pay, you can eliminate a lot of these obstacles. Fewer taps means more sales. So next, let's talk about how to integrate Apple Pay into your transaction flows. And the first thing to think about is giving people a shortcut to buying something. You don't have to put everything into a shopping cart first in order to start that transaction process.

So this is Chairish, I'm looking for something interesting for my home, these glasses look interesting. The Apple Pay button is right there. I don't have to put it in a shopping cart and then go tap on the shopping cart and then say I'm ready to check out. This a way to reduce the number of taps it takes to complete the transaction. Groupon takes a very similar approach.

So I'm going to be in Chicago in a couple of weeks. I'm looking for something fun to do. This looks interesting. So when I tap for more information, that Apple Pay button is right there. It's so easy for me to quickly make a purchase. So think about adding Apple Pay buttons right next to your product details. Give people that shortcut to starting the transaction.

Now, as Nick said, customers love Apple Pay. So if they are on a supported device and they have activated a card you accept, it's highly likely they are going to want to use Apple Pay, so you should default to it. Now Nick will show you how to test for this in a couple minutes.

If they are not on a supported device and they haven't activated a card that you don't accept, there is no need to show any Apple Pay buttons or messaging at all, just complete the transaction as you do today. But if they are, default to Apple Pay as the payment method and then display those buttons prominently.

Now, with iOS 8.3, the Apple Pay buttons are available via API. So you don't have to worry about resizing graphics and embedding them in your app anymore. It's very easy. And when you're thinking about where to put them in your layouts, they should be at least as large as your other payment method buttons. Larger is also fine by us. [Laughter] So here's how Fancy does it. They've got their Apple Pay button right above the Add to Cart button and Shoptiques puts it side by side. These are both great implementations.

Now once your customers tap the Apple Pay button, the next thing they are expecting to see is a payment sheet, so they can quickly put their thumb down and complete the transaction. You don't want to interrupt this with asking any other information. It'll be disruptive and could interrupt them right when you are about to make that sale.

Apple Pay is going to provide you all the core information you need to complete the transaction. The one thing you might need to take in advance is promo codes or other discount codes. So find a place in your app where that could feel at home, where it wouldn't interrupt the payment sheet appearing after someone taps that Apple Pay button. Okay, we talked a lot about the payment sheet so let me give you some tips on customizing it for what you need. So of course, you are going to want the payment method but you will request billing and shipping and contact information if you need it.

As Nick was saying, Apple Pay is incredibly secure. So we're hoping that you don't need the billing information just for verification purposes. But it is available if your system still requires it. And then if you are selling physical products and you need to send them to someone, you'll want a shipping address.

It's very easy for customers to change this right within the payment sheet. They just tap on it, and the payment sheet will display a list of recently used addresses as well as the ability to quickly add one in for contacts. You may have previously collected shipping information for your customers that are already existing but like I was saying earlier, it's highly likely that the Apple Pay information will be current so we recommend that you rely on that.

You can also request a contact email and a phone number, so if you wanted to follow up the transaction with a confirmation email or you will might need a phone number in case of any shipping questions, that's available. And with iOS 9, you can also request just a contact name.

So let's say somebody wanted to order some food and go pick it up at a restaurant. You might just need a contact name so when they get to the counter, you can tell the clerk who the order is for. Now, if you don't need all of that information, don't request it. Respect your customers' privacy and only ask for what you need. Uber only requires email and phone number. So they are not taking a shipping address because they don't need it.

Now, you can also specify shipping method or pickup right within the payment sheet. The Apple Store offers multiple shipping options. So customers can tap on that and see the other choices available to them. There's room to include delivery estimates, so you can help your customers choose the right option for them.

And you also have the ability to list shipping costs, taxes, or even negative value items like discounts after the subtotal. Now, this is not intended to be a line-by-line itemized list of everything someone purchases. It's only things that are added to the subtotal of the merchandise. So here you can see how Keep is listing shipping and tax and handling in addition to the merchandise subtotal.

Now, if you don't have any of those items, you don't even have to list the subtotal, you can just list the total. This keeps the payment sheet nice and short and it's less for your customers to review and means faster transaction times. If you have the additional items you can list them, and if you don't, you can just show the total.

Now, there might be some cases where the total may not yet be known. And in these situations, it's really important that you make estimates clear. Uber is a very popular car service here in the Bay area and the total price isn't calculated until the ride concludes. Now, the way that they handle their language in the payment sheet is very clear.

I can see that the total cost is going to be calculated in the future based on time and distance. So if you are dealing with subscriptions, recurring payments or situations where you have estimates, make sure the language that you are using in the payment sheet is clear, because no one likes surprise charges later.

And then finally, make sure you place your business name next to the total amount at the bottom of the payment sheet. Now this is the name and the total amount that the customers will expect to see on their bank charge. So here I can clearly expect that I will see a charge for $229 to Fancy. Again, no one likes questionable charges and surprise amounts on their bank statements. So you want to be very clear here.

So, that's what goes into customizing the payment sheet. The only other thing that you need to do is confirm the transaction, just like you are already doing today. So once a customer pays with Touch ID, that thumb print button will change to a done status, the sheet will dismiss, and customers will be back in your app, so you can give them that nice reassuring confirmation telling them that the order has been processed and letting them know that they will get more information at their email. So when you are thinking about how to integrate Apple Pay into your apps try to remove all of those obstacles to making a purchase. There's no need to require people to set up an account before they have purchased something.

Display the Apple Pay button's prominently if they are on a supported device with an activated card that you accept. And make sure that you are customizing the payment sheet appropriately. Don't forget to put your business name next to the total at the bottom, and then confirm the transaction just like you do today.

So I hope this sets you all up for creating a great experience with Apple Pay in your apps. I'm going to be in the Apple Pay Lab this afternoon and if you have more questions about UI as it pertains to Apple Pay or want some advice on how to approach it in your apps, I'm happy to take a look, but for now, I going to pass it back to Nick to show you how to put this all together in code. Thanks.

Thanks, Rachel. Okay. I think we are ready to put it all together. I think we are ready to talk about some code. It's very exciting. So we will build out a sample app. It will be based off the app that Rachel showed you, but I've simplified the UI a lot, because we really want to concentrate on the code. It is going to request a payment. It will display the payment sheet and then it's going to handle the authorization. So before we dive into Xcode let's look at the classes that make up Apple Pay.

So the first class I want to talk about is PKPaymentSummaryItem. Again, Apple Pay exists in PassKit so that's where you'll find it. PKPaymentSummaryItem describes an individual item that you would like to charge for on the payment sheet, like, tax, shipping or total and you take all the summary items you would like to use and you pass them into a PKPaymentRequest. Now a PKPaymentRequest is an object that describes both the items you'd like to charge and the information about how you'd like to make the payment, so what card networks you'd like to support and what shipping information you would like to request, that kind of thing.

You take the request and pass it into a PKPaymentAuthorization ViewController which is the payment sheet class. Now it's like any other view controller, you present it using presentViewController. And then when that's done you'll receive a PKPayment object back. A PKPayment object contains both the informations information you need to process the payment, as well as information you might need to display a confirmation sheet or a receipt on the device itself.

So the very first thing we want to do, before we do any of this, is to check whether the device supports Apple Pay. We want to see whether they have payment cards that we can accept. So firstly, I'm creating an array of paymentNetworks that we provide these string constants that you can use for all the networks that Apple Pay supports. So here I'm checking whether the user has any MasterCard or Visa.

You then pass this array into a class method open PKPaymentAuthorization ViewController. It's called canMakePaymentsUsingNetworks. Now, if this returns true, you'll know that the user is set up for Apple Pay and they have cards that match what you are requesting. They can make the payment. If this returns false, you can take the user through your traditional checkout flow.

Now, we have a few other methods you can use as well. We have one to test whether the hardware itself supports Apple Pay. So you don't need to do any messy device checks. You can just call canMakePayments and that will return yes if the device has hardware support for Apple Pay. And new in iOS 9, you can also now check for capabilities of cards, and by capabilities I primarily mean credit or debit. I think that's going to be very useful in the UK and in Europe, where you may want to check or charge only to debit cards.

So let's assume the user has cards they can make a payment with. So let as create a PK payment request. Let's get our payments up and running. So the very first thing we want to do is pass in our merchantIdentifier so that we know how to encrypt your payment correctly. Now, you will have already set this up on the developer portal or the Xcode capabilities window and if you use Xcode, you've also got the entitlement set up on your behalf because all of these APIs are entitled.

Then you pass in a countryCode. This is a standard ISO countryCode and it should be the countryCode that your payment processor is in, the country in which you'll be making the charge. So it's not the country that the user is in or the currency either, because the currency is covered by the currencyCode, that's also in ISO standard code.

You can charge any currency you'd like in Apple Pay. Here I'm just using USD but if you want to charge in Pounds or Euros, you can easily do that. Next you provide some supportedNetworks. supportedNetworks, again, it's an array just like the canMakePayments check of networks that you can accept. So here, I have changed it up a little. I'm saying I can support American Express and Visa.

Now there's another required property on PaymentRequest that may at first look a little cryptic, and that's merchantCapabilities. So it turns out that we have two different ways of generating payment data. One of them is called 3DS and the other is called EMV. Now you don't need to know the intricacies of how these will work.

Most of you will use 3DS, and you should check with your payment processor or your inquiring bank as to the right setting for you. So again, the majority of you will be 3DS but the payment platform or processor can give you the exact advice that you need here. So I'm going to leave this at the standard which is 3DS.

And then finally, the last and probably the most important property of the PaymentRequest, what we actually want to charge. Now, before we look at that, there's a couple of new things in iOS 9. You can use this merchantCapabilities property to only allow certain types of cards to make payments. So it's a bit mask. And if you'd like to limit cards to debit cards, again it's a scenario more common in Europe than it is in the US, you can easily do that.

So a PKPaymentSummaryItem, like I said describes a piece of information that you would like to charge. It has an amount and a label. Now the label is a string, and the amount is this class called NSDecimalNumber. You may have come across NSDecimalNumber before it's a Cocoa class and it precisely represents floating point numbers in base 10, which is very important when you are working in finance and with currency. So it avoids any nasty base 2 floating point errors.

And it's got a few convenience initializers and it has string initializer. It also has a double initializer and you can initialize if from another NSDecimalNumber. So I'm going to use the string. So here I'm creating just one summary item because as Rachel said if I only one want one thing to charge, I should just have a single total. And the label is Apple Inc., because that's what's going to appear on the statement.

And I'm creating an amount from a string for $349.99. I just have a single item in my array which I pass through to my SummaryItems. To reinforce the point, the last item of the summary items array is the total that you want to charge. That's what we're going to authorize and send to you.

So payment request is good. We are ready to present it into our payment authorization view controller. This displays the payment information and it's modally displayed over your app like this. On iPad, it's a form sheet and on the new multitasking on iPad, it will actually cover the entire screen.

We do that so that if you've got two apps side by side they don't try to charge two things at the same time, so it's completely modally displayed. And it's initialized really simply, just with paymentRequest. It also has a delegate which we will come on to. And you present it like any other controller. You will probably want to present it with an animation.

And you will want to present it using an Apple Pay button. Now, from iOS 8.3, we have this great class, PKPaymentButton. It comes prestyled in a variety of colors and very importantly it's completely localized, so we really encourage you to use it. It's just like a UI button, its a UIButton subclass.

Now if you do need to target below 8.3, we also have some imagery available on our developer site that you can use. There'll be a link that at the end of the session. Moment of truth, let's see if we can get this working on a demo. So we will switch over to the demo machine.

Beautiful! Okay. So I have got a really simple app here that I have built and all of this sample code is going to be available on the developer site as well. So lets see what it's like right now, I haven't implemented anything in Apple Pay yet. Let's make the simulator a little smaller. A little shopping app.

And you can see I have got a little description of the price and the buy with Apple Pay button. Okay, nothing is really happening. So let's put that code in. Let's talk about what I have got so far first. You can see here, I have a canMakePaymentsUsingNetworks check. And I have got this supportedNetworks property. So I have actually defined this further up. Let's go take a look at that. There it is. You can see I am supporting all four networks, American Express, Discover, MasterCard, and Visa.

And I'm adding the button if support is available and I have this applePayButtonPressed method. So I'm going to want to add stuff to that. So let's set up our paymentRequest. Well, actually before we set up my paymentRequest we should double check we've got our entitlements set up. So they're all listed here in entitlements. You can see that mine is a little red but don't worry about that. You will see why in a second.

Okay. Let's go back to our code. Let's get this set up, lets create our paymentRequest. So let's run through line by line what is going on here. Scroll this up a bit. Okay, so first of all we are creating the paymentRequest and then we're passing it, our merchantIdentifier which just for convenience sake, I've defined in generic configuration class. I'm then passing the mandatory properties the countryCode and the currencyCode. Now in this case my app is only charging in USD. And I'm also passing in the supportedNetworks.

Now, I talked to my payment processor and they told me that I should use 3DS as my capability. So I've done that. And I also want to create my SummaryItems. I have a convenience method here, I've hidden it. But it's going to create a product. So in this app, all the products come in from appealists. It's a very contrived example. And it will generate a summarized version for me.

We'll take a look at that method in more detail in a bit. Okay so now I'm ready to actually display the view controller. So again, it's initialized with the PaymentRequest and its got a delegate. My delegate method is here and we will take a look at those again in a bit. I can just present it. So let's run it.

So I've just thought of something, I don't know if any of you tried to use Apple Pay on iOS 8. It doesn't actually work on the simulator. So I might have a bit of a problem. Let's see. Oh okay, I guess Apple Pay does work on the simulator now.

[Applause] As of iOS 9 we support Apple Pay. We'll vend you these simulated cards for every card network that you request. So they're hiding here. Let's pay with pass code, cause Touch ID doesn't exist. Oh, okay. I guess I have one more hurdle and that's these pesky delegate methods here. So let's talk about what needs to go in there. Let's talk about how we actually handle authorization once it happens.

So once the users Touch ID, we're going to receive some callbacks in our PaymentAuthorization ViewControllerDelegate. And we can use this delegate to confirm whether we've received the payments and whether we've been able to process them. Now, it has two required delegate methods. The first method is paymentAuthorization ViewController didAuthorizationPayment.

So you will get back a PKPayment object, and you return a completion handler, a block with a status and that status will tell us whether you have been able to process the payment on your own servers, in which case we will display a nice check mark on the sheet, or if something has gone wrong in which case we'll try to tell the user what happened. You then need to dismiss the payment view controller, and that happens in another delegate method. So you shouldn't dismiss the view controller in didAuthorizationPayment. You want to dismiss it, paymentAuthorization ViewControllerDidFinish.

Now PKPayment, the object that you will get back contains another object with PKPayment token, and it's returned after a successful authorization and that's what you will send up to your payment processor or to your own servers and it's got the encrypted payment data, as well as any other metadata that you might have requested. So a shipping address. Okay. Let's add those in. Let's get that into our app.

Okay. So let's do didAuthorizationPayment first. Now, I'm not going to integrate with a payment processor for today. So you'll just have to imagine that this completion, this is where I posted it to my server. There we go. Now, I have also got a segue in this app to send a confirmation sheet. So that's defined -- I have to find it.

Here we are. So I have a really simple segue and it's taking this property on paymentToken called transactionIdentifier. So the PKPayment token, like I said, it contains the information you need to make the payment, it's also got some useful metadata you might want to display in a receipt.

So things like a sanitized version of the card name and also this thing called a transactionIdentifier. Now that's guaranteed unique. You can use it if you'd like. You can use it for receipts. It's unique to every Apple Pay purchase. And last but not least, I probably want to dismiss my view controller. There we go. Now, here I'm sending success, but we do have a few other statuses that you can send if you'd like.

So success and failure, if maybe something went wrong when you tried to authorize it. As we see later, we have some other statuses for invalid billing address and invalid postal address or they haven't supplied enough contact information. Okay. So let's run that. So I'm going to go for the aluminum color because I feel at this WWDC we haven't had enough aluminum.

Okay Pay with Passcode. Okay great. You see the transaction identifier here says Simulated Identifier. That's because I'm on the Simulator it's returning me dummy information. If this was a real device I'd have an actual transaction identifier. I'd also send it off to my own service for processing. I have an app that can accept Apple Pay and make payments.

It didn't seem like I needed that much code, right? I thinks thats only a dozen lines. There is one small problem with my app. I'm buying dog collars but I have no idea where to ship them. So we should probably get that fixed up. We should probably look at how we can actually get contact information.

So you can request contact information from users using a bit mask on the payment request. It's called requiredShippingAddressFields. We have postal address, email and phone and then in iOS 8.3, we introduced name which is name only. So if you are a ride sharing app and you don't want to collect the user's postal name, but you do want their name, so the driver knows what to call them, you can use that.

Now, optionally, you can request billing, the billing address. That's another bit mask with required billing address fields. Now for all of this contact information, we recommend that you don't request it unless you absolutely need it. It's very important. Users love that Apple Pay is so quick and easy to use. So you don't want to get in the way of that, especially for billing address.

It's not required to process Apple Pay and no payment processes should require it. For that reason we recommend you don't request it but, we do understand that some of you might have platforms, fraud systems, existing infrastructure where you need it, so it's there in case you want it, but think about ways you might want to avoid it.

So in conjunction with contact information comes shipping costs. And because the user can update their shipping information inside of the Apple Pay sheet, perhaps you'll want to update the amount they get charged. So you will receive a callback in an optional delegate method. It's paymentAuthorization ViewController didSelectShippingContact. And it returns to you a contact and it has completion handler.

Now, the completion handler has a status. So you can have success or invalid information and it's got two arrays. The last array is an array of PaymentSummaryItems, seems sensible enough, you can update the summary items you'd like to charge, but also there's an array of things called ShippingMethods. So the Apple Pay sheet can also display shipping methods along with costs, and that's a separate array. PKShippingMethod is a subclass of PKPaymentSummaryItem.

So like the of SummaryItem it has a label and it has an amount but it has another string property called detail. And you can use that to say, tell the user how long it will take to be delivered. So here I'm creating a single shipping method, assigning it to my payment request, so that will be displayed in the sheet.

Contact information. So for the users privacy, in this delegate callback, you won't get the full un-redacted contact information because the user has not Touch IDed yet. And we take the user's Touch ID as consent to release that information into your app. So you will receive city, state, and ZIP code or postal code in the UK, or sanitized postal code in the UK, I should say. We think that's enough to estimate shipping costs, for example, out-of-state, international, but then in the final payment, once you get it back in did authorize, you can get the full contact information.

Now, these APIs might look a little unfamiliar to you. That's because they are using the new Contacts framework in iOS 9. So address book has been deprecated in this release. [Applause] Yes, don't applaud me. Applaud the Contacts team. I know I did. They've gone away. We replaced it in Apple Pay as well.

Now, we are going change the APIs a little bit in an upcoming seed. So they won't be exactly the same. If you are watching the video online, check the developer documentation for the latest information informationBut here is a really simple example of extracting a name and an email address. So let's finish our app up. Let's put all of that information into the code. So the first thing I'm going to want to do is actually request the shipping information.

Then I'm going to just want postal address. That's what I will ask for. Then we will need to put in our delegate method. So let's find the right one. There we are. didSelectShippingContact and let's put our code in. So what I will do in this app, I will have a very contrived example. I going to run you through it line by line.

I'm going to charge a surcharge. If a user selects a shipping address that's not in the United States, so an international surcharge. Now this paymentAuthorization ViewController didSelectShippingContact method is always called if the user has an address in the sheet. So if the users had a default address, perhaps from the me card, you will get a call back as soon as the sheet is presented. I'm setting up a shipping method, I'm only going to have one, standard shipping.

And then I will check the address. So here I'm getting the address out using the new contact APIs. There's another session on the contact APIs. So don't worry too much about this. There's a chance to find out about them later. Then I'm checking in a contrived example whether the country is the United States.

Now the reason I say this is contrived is the address information on iOS can come from many different sources. It can come from the user inputting it into the Contacts app, but it can also be synced from from Facebook, or one of the many other social networks that integrate with iOS. So it's important that you validate addresses correctly and don't assume that they will always have the exact information you are after. So, again for demo purposes, I'm just simplifying things a little.

So earlier, we saw I had this helper function called makeSummaryItems. So what this actually does and you can check the sample code out is adds an additional surcharge into my payment items, if it's international. So that's why there's this Boolean property here called requiresInternationalSurcharge. Then I return my completion handler, which is of Success.

It's got an array of shipping methods, just one. And my summaryItems array. Now, again, you can also return a failure state here. Perhaps the user put a city or state or country that you don't deliver to in which case you could return one of the invalid postal address states. All right. Let's try this out.

So I have got some addresses already in my Apple Pay sheet. So here I have got an address in Canada. It's not in Canada. I just put it together. You can see it has international handling here, but if I change it to a US address, you will see that the international handling has gone away as has the subtitle. It's a single title. It's really easy in the Apple Pay sheet to update all of your shipping costs which are again listed in a separate screen. So here I have just got one. There's only one to choose from.

It's a really great way to get your shipping information directly into the sheet and get another step of the purchase flow out of the way. So all of that sample code is going to be available on the developer site. There are a few other things I would like to talk about.

We have got some new API in iOS 9. One of them is something called PKPaymentMethod. So this lets you find out more about the payment instrument and by instrument, I mean the card that the user selected. And it lets you do things like -- like apply debit or credit surcharges or discounts.

So again, not too common in the US, but something that can happen elsewhere in the world. And you'll receive a delegate callback whenever the user changes their payment method. So here I'm inspecting for a confirmation screen whether these are paid with debit or not. It's a really nice API that you can use. It might be useful for you.

Now there is a caveat, a minority of older cards added to Apple Pay, we don't know the type of card they are. So you will receive PKPaymentMethodTypeUnknown. Now, because this API is primarily targeted at Europe and the UK we are launching next month, this won't be a problem there, but if you're in the US and you want to use this API, do just bear that in mind. You will need to code around this.

We have also got a new property on PKPaymentSummaryItem. Something that people, developers have really requested and that's the ability to change the type of the summary item. We have two types. One is called final, self-explanatory, and one is called pending. And you can use that to indicate that your charge isn't final.

So if you're a ride sharing app and you don't know how much it's going to cost the user. You can select the type to pending. Now additional documentation for this will be coming in a future seed and we might make a couple of changes so again, if you are watching online, check the developer documentation for the latest information.

I already talked about Simulator support. It's really important that even though we have added support for the Simulator, you still ten your apps on real hardware. I think this is a great feature if you have developers in another country and you are in the UK now and you want to get up and running before we launch.

It's very important that before you go in the store you test your apps on real hardware and make sure that payments can be processed successfully. I also want to talk about Apple Watch. So when I showed you the hardware slides, you are thinking the Apple Watch has a Secure Element.

The Apple Watch does not support Apple Pay inside of WatchKit apps. However it is possible to trigger payments directly from the apple watch using Handoff. You can handoff directly to your app on the phone and display an Apple Pay sheet as soon as the user launches the app from the lock screen.

I have some sample code that shows you how to do that. In the app I just demoed I have a WatchKit extension and WatchKit app that triggers a payment on the phone. If you are interested in that take a look. We have also actually opened up the PassKit APIs for the watch as well. If you would like to know more than that, the session that just happened, Wallet, the home for Apple Pay, that's available online and you can take a look there. So in summary, Apple Pay, it's really easy to use. It's private and it's secure.

And I really encourage you to go give it a go. Go download and app from the store. We have a great featured section on the store that has loads of amazing app that use Apple Pay. Try it out tonight and think about how you can integrate it in your own apps think about not just how you can improve the user experience but how you can actually see your apps really shine and improve your own results with Apple Pay. Delight your users with it. I know they will appreciate it.

So we have more information for you. We've got some documentation. We have an Apple Pay for developers microsite. If you are interested about the Secure Element and the hardware, which is kind of interesting, we have more information about that in the iOS Security White Paper. It goes into a lot of detail about how we actually generate these payments, and the process of getting these cards onto the device.

It's quite an interesting read. You might want to check it out. We also have technical support available through DTS and the developer forums and if you have any questions, you can talk to our Evangelist Paul or talk to Rachel, who you saw up on stage earlier, our User Experience Evangelists any design questions for Apple Pay.

There's the related sessions, the Wallet session, I already mentioned. You can grab that online. If you are interested about the new Contacts framework, I strongly recommend go check out their session, it's on Thursday at 3:30. Learn all about what we have done to make Contacts easy to use.

And lastly, but not least, we have labs. There are labs today and tomorrow for Apple Pay in the afternoon, please come to them. We will have people from the server teams to answer questions about cryptography, and we'll have people from the client the iOS side, we'll have some business team there if you have any questions about how to accept Apple Pay and payment processes.

And Rachel is going to be at today's lab, which is a great time to get design feedback. So it's well worth attending, we'll be real happy to see you. That's it for me and Rachel. Thank you so much. I hope you enjoy the rest of the conference. Have a great lunch. Goodbye. [Applause]