Apple Pay is the easy, secure, and private way to pay for physical goods and services within apps on iPhone 6, iPad Air 2, and iPad mini 3. Find out how you can increase conversion rates in your checkout experience by integrating with Apple Pay APIs. And learn more about what's new with Apple Pay within apps in iOS 9.
NICK SHEARER: 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.
Where In-App Purchase is used for in-app content
and functionality, in-app currency, services,
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
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
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 ROTH: Thanks, Nick.
RACHEL ROTH: 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.
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
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
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.
NICK SHEARER: 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
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
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
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.
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
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.
Oh okay, I guess Apple Pay does work on the simulator now.
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
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
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
You want to dismiss it,
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.
You see the transaction identifier here says
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
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
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
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.
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.
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
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
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.
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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.