WWDC2015 Session 702

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> 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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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?
>> RACHEL ROTH: Thanks, Nick.
[Applause]
>> 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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Applause ]
>> 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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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]