WWDC2017 Session 714

Transcript

[ Applause ]
>> Hello.
[ Applause ]
Hello everybody, thank you for
coming this evening.
Last session of the day.
We're here to talk about what's
new in Wallet and Apple Pay.
And there are three things that
we're going to talk about.
We're going to break today's
session down to three sections.
The first one is going to be a
little bit about the Apply Pay
experience.
Some of you might be familiar
with Apple Pay, but we've also
been quite busy this past year,
so we're going to run through
some of the new things we've
been doing.
Then we're going to look at iOS
11 and macOS High Sierra and
we're going to talk about what's
new with Apple Pay.
And then, finally, we're going
to look at some of the new API
inside of Wallet.
Now, there are a few things
we're not going to cover in this
session.
We're not going to cover getting
started with the Apply Pay API
and how you integrate Apple Pay
with your payment processor.
We have a lot of great resources
for that, you can check out last
year's WWDC sessions, "Apply Pay
on the Web," and "What's New
With Wallet and Apple Pay" 2016
for more information.
So, let's dive right in and
let's talk about the Apply Pay
experience.
Now, hopefully many of you
who've used Apple Pay either in
a store, or in an app, or on the
web, and if you have, you'll
know that Apple Pay is easy,
secure, and private way to pay.
And when we first launched Apple
Pay in iOS 8, we supported
payments within applications.
Here's a good example.
But, since then we've expanded
Apple Pay to far more places.
We've expanded it to Safari.
You can now make payments from
Safari on mac and on iOS.
We've also expanded it to Siri.
You can make payments now from
within SiriKit.
Another great extension point
we've added Apple Pay to is
messages, you can write messages
apps that can take advantage of
Apple Pay directly from within
the message's application.
You can buy a movie ticket and
send it to a friend without ever
having to leave the messages
app.
And finally, we've added support
for watchOS.
You can make payments within
watchOS on WatchKit.
Last year, we also added
support, natively on the new Mac
Book Pro with Touch Bar.
So, now you can make payments
directly on your Mac without
handing them off to an iOS
device.
And hopefully you've also had a
chance to see some of the apps
that have been built on top of
WatchKit.
The Apple Store is a great
example.
You can buy accessories directly
from your wrist.
You just pick an accessory, pick
a card, and you're done.
Now, when we first launched
Apple Pay it was only available
in the United States, but since
then we've been extremely busy.
In the past year alone, we've
launched in over a dozen new
countries.
Here are all the countries that
we're currently supported in.
One country that I'm
particularly excited about is
Japan.
In Japan, you can actually use
Apple Pay directly on the Tokyo
Transit System with your Suica
Card.
It works really, really well.
Another thing we launched last
year after WWDC was Apple Pay
for nonprofits.
This is really interesting if
you're a nonprofit and you want
to take Apple Pay either within
your application, or perhaps on
your website.
Here's an example from OXFAM in
the United Kingdom.
They're one of the largest
nonprofits in the UK and they
actually found that using Apple
Pay reduced the time that it
took to get a donation from 2
minutes to 10 seconds.
That's a huge decrease.
And as a result, they're seeing
much better user experience and
performance.
Now, if you're interested in
accepting Apple Pay as a
nonprofit, it's really easy to
do.
You can use it inside of your
apps and on the web.
And to help support you, we've
added a new donate with Apple
Pay button style.
There's a very simple signup
process.
You can find out more about
where this is supported and how
to get started at the developer
site.
Now, if you're not using Apple
Pay, you might be wondering why
should I adapt it in my app or
on the web.
Apple Pay is one of the best
ways for users to pay.
It has one of the highest
customer satisfaction ratings of
any wallet.
But it's also the best way for
merchants to be paid.
I want to illustrate that with a
little example of a typical
product flow.
So, normally in the checkout
process, we buy a product.
We go to a website, we got to an
app, we see the product and we
add it to our cart.
And then we go to checkout.
And the first thing we normally
have to do is we have to create
an account, or sight in.
And if I don't have an account,
maybe I've got to like create
one and then go to my email to
verify it.
So, I've left the site already.
And then I come back and I've
got to add my shipping address.
And then once I add my shipping
address, well I shipped it to
work, and my credit card uses my
home address as my billing.
So, now I've got to add my
billing address.
And I've got to type in my card
details.
Except, I left my credit card on
the other side of the stage, so
now I've got to go over there to
get the CVV number on the back.
And then I've got to review the
transaction.
And then finally I can confirm
and pay.
So, it's not really surprising
that if you've done any
ecommerce work, conversion rates
is one of the biggest things you
encounter.
Users drop off all the time
during purchase.
But, with Apple Pay, it's so
much simpler.
You just tap or click the buy
with Apple Pay button, and
you're done.
All of these steps are coalesced
into a single user experience.
And this has some really
dramatic results for
performance.
Over the past three years, we've
been asking merchants what they
found with Apple Pay.
And they've told us that they've
seen between 2 and 5 times
increased conversion rates with
Apple Pay, that they've seen
higher purchase frequency.
And the checkouts move much,
much faster.
And a result of all of these,
they see improved customer
acquisition and satisfaction.
Users are more likely to become
your customers, and they're more
likely to be happy.
I want to give you a few
examples.
If you are a freelance or a
contractor, you might know about
Intuit, they have an app and a
service that lets you generate
invoices.
They took advantage of Apple
Pay.
You can pay your invoice
directly.
And they found that these
invoices were paid 30% faster
with Apple Pay.
And half these invoices were
paid immediately, the same day
they were received.
I used to be a freelancer and
that was unheard of when I
freelanced.
Another app that's had a lot of
success is Indiegogo.
They adopted Apple Pay so you
can use it to pledge for items
there and they've seen a 250%
increase in conversion rate.
There are a few other benefits
outside of conversion.
Many merchants see a reduction
in chargebacks.
This is huge.
If you deal with these, you'll
know they can be very expensive
and time consuming to resolve.
And perhaps, most importantly
with Apple Pay there's no need
to handle or store credit card
numbers.
This is huge.
You don't need to handle you
know regular credit card
numbers, instead you're handling
device-specific tokens.
You also get a trusted user
experience.
Instead of going to five
different sites and getting five
completely different checkouts,
you get a single UI that uses
trust.
Built directly in Safari or into
iOS.
So, hopefully if you haven't
adopted Apple Pay I've convinced
you to go after this session and
immediately start putting it on
your site.
So, I want to give you a few
bits of advice on how you can
perfect the Apple Pay
experience.
When you're thinking about
designing for Apple Pay, it's
important to think about three
basic principles.
How can I make purchasing
easier?
How can I make purchasing
faster?
And how can you make purchasing
clearer?
And when you put these together,
you get a great design and a
great user experience.
And if you've been to our
website, you'll see we use three
terms to describe how to best
perfect these.
One of these is something we
call upstreaming.
Another technique in our
interface guide, we call
defaulting.
And a third technique in our
interface guide we call
streamlining.
So, I want to run through each
of these and I want to see how
they can help.
Upstreaming is about
accelerating single item
purchases with Apple Pay
directly on product pages.
We're accelerating multi-item
purchases with express check
out.
Let me give you an example.
I live in San Francisco, so it
is obviously very important that
I have a constant stock of
hoodies to wear.
So, here is Lululemon's site, I
can buy a hoodie, and you'll see
that there is a buy with Apple
Pay button directly on the
product page.
Placing the Apple Pay button on
your product pages drastically
increases conversions by several
orders of magnitude.
It allows purchasing
immediately.
And also, if you allow
purchasing without creating
accounts, as is done here,
you'll get an even better
performance.
Now, sometimes, guest check out
isn't feasible.
But there are some techniques
you can use to help mitigate
this.
Firstly, you can write the
account creation seamless with
iOS and macOS.
One of the ways that you can do
this is through shared web
credentials.
This was introduced a few years
ago and there have actually been
some great improvements to
shared web credentials in iOS
11.
So, do check out the Safari
sessions to find out more about
that.
Another thing you can do that is
new in iOS 11 is have native app
autofill.
iOS 11 will now autofill
passwords within applications.
And to take advantage of this,
all you need to do is hint your
UI text fields with the right UI
text content type; password,
email, etcetera.
You can also create an account
after payment using data the you
gather from Apple Pay.
So, the user's email, for
example.
You can create an account once
purchase has happened.
Now, the second technique that I
mentioned is defaulting.
And this is about making Apple
Pay the default payment option
where possible.
And you can actually take
advantage of a new feature we're
adding that I'll talk about in
just a moment, that we call
in-line set up.
You'll see how that can make
Apple Pay immediate, even if the
user doesn't have cards on their
iOS device.
The final technique I mentioned
was streamlining.
This is about making purchasing
with Apple Pay quick and simple.
It's about collecting the
necessary information before
checkout begins.
If you need a size or a color,
make sure you get it before
checkout starts.
And it's also about preferring
customer information from Apple
Pay.
Don't ask for the user's email
address yourself.
You'll be able to collect it
along with shipping information,
billing information, and so on,
directly from the Apple Pay
sheet.
That brings me to the Apple Pay
sheet.
You may be familiar with it.
This is what it looks like on
the Apple Store.
And I've got some general advice
for when you're thinking about
using Apple Pay and how to best
take advantage of this sheet.
One piece of advice is only to
present and request essential
information.
Don't request information you're
not going to use.
If you don't need the user's
phone number, don't ask for it.
Another thing to bear in mind,
is that the screen estate is
quite limited.
There isn't a lot of space.
So, you should keep your line
items short and meaningful.
It's not intended to be a kind
of full receipt.
The Apple Pay sheet is intended
to be a summary.
So, use these line items to
explain additional charges,
discounts, tax.
Let me go back to the Apple
store and show you what I mean.
Here you'll see I'm buying an
iPad and here in the sheet I see
a subtotal, shipping, tax, and a
total.
So, very top level.
Now, sometimes you don't know
what you're going to charge.
Perhaps you're a ride sharing
company and you don't actually
charge the user until the ride
is over.
Or perhaps you want to add an
optional gratuity that the user
picks at the end of the
transaction.
You can use pending items to
achieve this.
It's important to clearly
disclose that these pending
items are additional costs.
Here's an example, we just mark
the type as pending, and it will
show up on the Apple Pay sheet
without an amount.
Now, the total amount has to be
nonnegative.
It doesn't really make sense to
have a payment that's for a
negative amount.
But it can be pending.
So, you can have a total that is
not known at the time the time
the transaction is taking place.
It's very important for the
total amount to use the business
name that will appear on the
card statement.
It's important for two reasons.
Firstly, users want to be able
to reconcile what appears within
the Wallet application and on
their bank statement with what
they paid.
Also, now that we support the
new Mac Book Pro with Touch Bar,
we actually show the merchant's
name on the Touch Bar itself.
So, again, it's important to
make sure that it matches what
the user expects.
Now, one use case that's grown
over the last year with Apple
Pay is subscriptions.
For example, news sites that
want to use Apple Pay on the web
to take subscriptions.
You can do that, but there's
some advice I'd like to give
you.
It's important to clarify the
subscription details prior to
payment.
It's important to include line
items that reiterate the billing
frequency.
And for variable subscriptions
use pending items.
Let me give you an example.
I have a little side job, a
little app I'm working, it sells
avocado toast to naïve
millennials.
Here it is.
It's a subscription, of course,
because that's what's getting
all the funding, so I'm told.
And here's my Apple Pay sheet.
And you'll see that I have here,
weekly service, so in my line
item I'm clearly indicating the
length of time that the
subscription is for.
I'm also noting a discount.
You can do that in the sheet.
You can note introductory
discounts.
And then what will be charged at
this current time.
And then you can use the same
information, the same payment
data you get from Apple Pay to
make subsequent charges.
Now, sometimes there are certain
types of subscriptions where the
cost varies.
Maybe you're a meal ordering
service and the number of meals
that the user gets varies week
by week, month by month.
Use pending amounts for variable
subscriptions.
Another thing to bear in mind is
that if your subscription is
variable, and the user changes
their plan, for example, you
only need to show the payment
sheet if a change is going to
result in additional fees.
If the user decreases the cost
authorization is necessary.
So, that's the payment sheet.
I want to talk now about
buttons.
Specifically, I want to talk
about the Apple Pay buttons.
Please, use the built-in Apple
Pay buttons.
Don't create your own.
A couple reasons why you don't
want to do that.
Firstly, the Apple Pay buttons
are localized to any language
that the user can choose.
They're also vectors, so they're
completely scalable, so you
don't need to worry about them
not looking right.
And they're available in a
number of styles.
We first introduced the native
buttons in iOS 8.3.
So, you can target 8.3 and
above, which is nearly the
entire in store base right now.
And in macOS 10.12.1 and iOS
10.1 we made it a little easier
on web.
We used simplified CSS styles.
Let me give you some examples,
some code examples.
So, here is the not very
exciting code in Swift.
PKPaymentButton is a UI button
subclass.
You just provide a type and a
style.
We have buttons in black, white,
and white with an outline.
Let me show you the same button
in HTML.
So, this is the new CSS style it
was introduced in iOS 10.1.
There's a WebKit appearance
style Apple Pay button, and a
type buy.
Now, we have four button styles.
Let me show them to you.
On the left are the Swift
symbols, on the right the CSS
names.
We have a plain button.
We have a buy with Apple Pay
button.
We also have a Set up Apple Pay
button.
We'll see how to use that
shortly.
And new in iOS 10.2 and macOS
10.12.3, we have a Donate with
Apple Pay button if you're a
nonprofit.
Now, obviously as a nonprofit,
you probably want to target all
versions of iOS or macOS before
that.
In that case, you can just fall
back to the regular plain
button.
So, that's the quick update on
Apple Pay over the past year and
a review of some of our best
practices.
And I want to tell you the
exciting part of the talk.
Which is what's new with Apple
Pay.
When we thought about what we
could do this year with Apple
Pay we thought how could we make
a best in class conversion even
better.
And how could we help users
resolve common problems that
they told us about.
And finally, how can we help
make getting started with Apple
Pay fast and easy, so even more
of your potential customers can
come with cards already on their
device.
So, I think you'll see that the
next few slides will show some
of the ways we're going to
achieve that.
The first way is through Set up
Apple Pay.
Now, starting with this version
of iOS, we strongly recommend
that you show the Apple Pay
button for all devices that are
hardware capable with Apple Pay.
And you can choose the Set up or
Buy button stars that suit your
needs.
If the API tells you the user
doesn't have any cards, you
could optionally display Set up.
If it makes more sense in your
design to stick with Buy, you
can do that.
But we've introduced something
to really help with that.
And the reason for this new
advice is because now we support
inline set up.
Apple Pay Set up is now offered
automatically.
If you try to present an Apple
Pay sheet on previous versions
of iOS, if the user didn't have
any cards, that would actually
be an error.
Actually, you wouldn't be able
to present the view controller.
Now, you will actually present,
or present Apple Pay Set up.
And most importantly, users are
returned to the purchase as soon
as set up completes.
Which means that it's actually
faster than a manual check out
to add and Apple Pay card and
complete the purchase.
I want to actually show you what
that looks like and how quick it
is.
So, here is the Apple store, on
their website this time, not
their app.
And we're going to see what
happens when we try to tap the
Buy button without cards.
It's going to go quite quickly.
Okay, so we get a little
dialogue to add a card.
We're going to add a card.
This is a card that I've already
used on another phone, so it's
already there.
I just enter my security code.
Now we're going to add the card.
Read the terms thoroughly
[laughter].
And then we're going to add it
to Wallet, activate the card.
And boom, we're done.
Now what's going to happen?
Immediately we're going to go to
the Apple Pay sheet so we can
continue the payment.
This is great.
That actually took less than 30
seconds, which is still much
faster than manually typing my
card number and all this
information on the regular Apple
Store checkout.
And again, this happens
completely automatically.
You don't have to make any code
changes.
There's no new API.
All you have to do is present
Apple Pay if the user doesn't
have cards.
So, I recommend you will go and
take advantage of that.
Now, if you were at the keynote,
or watched it online, one thing
that might have got you quite
excited was Apple Pay Cash.
Apple Pay Cash allows you to
send money to fellow users of
iMessage.
And the money you received is
kept inside Apple Pay Cash.
Now, Apple Pay Cash can be used
in stores, physical stores.
But it can also be used within
apps and on the web, just like
any other card.
In fact, if you can process
credit cards, you can process
Apple Pay Cash.
We will have more information on
exactly what you need to do very
shortly on our developer site.
But rest assured if you take
credit cards today, there will
be no real work to take Apple
Pay Cash.
There are a few things you
should know about Apple Pay Cash
if you're in in-app or website
developer.
Apple Pay Cash is a stored
balance card.
You have a balance.
So, let me give you an example.
My business model for
subscriptions wasn't really
working, so I've switched to an
on-demand model where we deliver
the avocado toast directly to
your seats.
And so, now I'm just going to
one off charge.
But I'm trying to make this
payment with an Apple Pay Cash
card.
Unfortunately, I don't have many
friends and they haven't
actually sent me any money.
So, you'll see this UI is new.
It says insufficient balance.
The important thing to note here
is that we're now using the
total amount that you supply to
determine whether the payment
can happen with Apple Pay Cash.
That means that it's important
that your total reflects what
you intend to charge, Apple Pay
Cash is only available when your
balance exceeds the total being
requested.
Now, if you're not sure of the
total, you can use a pending
amount.
Using a pending amount bypasses
this behavior, we will allow the
payment to happen regardless, of
course bear in mind it may still
be like any stored value card,
rejected if the user doesn't
have a balance.
Let's talk about some new API
that we've added briefly.
One use case we've been asked a
lot about, particularly in
Europe is about limiting Apple
Pay to specific countries.
Sometimes this is required for
regulatory compliance.
Now you can.
You just pass in this new
property, supportedCountries,
and you just set the countries
that you want to limit to.
Bear in mind that like some of
our other API that exists today,
that lets you say limit to
credit or debit cards, this
isn't available on every single
card.
So, just bear that in mind.
For more information about that,
check out last year's session.
Now, I want to talk about the
biggest change that we're making
to Apple Pay and that's to do
with error handling.
Sometimes, things can go wrong
with Apple Pay, I regret to tell
you.
And it can be problematic to
communicate this to users today.
We've had feedback from
developers, we've had feedback
from users.
What are some examples of this?
The payment instrument failed to
process.
The billing address didn't match
what the bank had on the card.
The email address was invalid.
The postal address had an
incorrect zip or postal code.
The telephone was missing an
area code.
And we can divide these up into
two categories.
We can divide them up into what
I call fatal errors and nonfatal
errors.
Fatal errors are errors that
can't actually be resolved by
the user there and then.
And you need to handle them
outside of Apple Pay.
But they're also often not
preventable.
What's an example of that?
The user has exceeded their
credit limit.
You're not going to be able to
solve that within Apple Pay,
you're going to need to go to
your bank to fix it.
But many errors are nonfatal,
they can be resolved by the
user.
And they can be handled within
Apple Pay itself.
And sometimes they're
foreseeable and preventable.
But in previous versions for
iOS, it was a little tricky to
communicate what exactly was
wrong.
Whenever a payment is complete
in the native API, you would
return a
PKPaymentAuthorizationStatus
Enum.
You'd have a similar Enum in the
web API.
And these have no specificity.
You can only say invalid
shipping address, invalid
billing, invalid contact.
So, the user's not really sure
what went wrong.
But even if the user could
figure out what went wrong, they
weren't actually able to edit
existing values.
So, they'd have to go and pick
an entirely new address or type
one in.
And that's not a great
experience.
So, we are changing that.
And we're changing it in three
ways.
Firstly, we're going to
introduce some new guidelines to
better handle user data.
We've also introduced a
brand-new UI for users to input
and edit data.
If you've tried out the iOS
Veetle, you might have seen
this.
And finally, and perhaps most
excitingly for you, we've
introduced new API to let you
communicate precise errors about
what went wrong.
So, let's go through these one
at a time.
Let's talk about handling user
data.
This is a fun one.
Contact information on iOS and
macOS can come from many
different sources.
It can come from iCloud, it can
come from contacts manually
typed in.
But it can also come from
LinkedIn, Facebook, VIDO,
[inaudible], it can come from
anywhere.
And you shouldn't expect this
information to conform to your
business logic.
What do I mean by that?
Here is an example of a postal
address.
It is for the Apple store in
Boston, which is a very nice
Apple store.
You should visit, say hello,
tell them I sent you.
Now, the address may look
correct to you, and if you wrote
this on an envelope and dropped
it in the mail, it would get
there.
But it's actually got a few
problems that could trick an
unwitting developer up.
Some of them don't really seem
like big problems.
Street is abbreviated.
Seems like most systems should
be able to handle this.
Some problems are a little more
serious.
If you paid attention in civics,
you may have noticed that
Massachusetts is misspelled.
It has two T's.
I lived there for four years.
I still can't spell it right.
Now, if you were doing an exact
string match on the state, this
might cause you a problem.
Another thing that's a little
odd is this zip code.
It says zip plus 4, which is a
regular zip code with 4
additional digits for
specificity.
If your backend system was only
expecting 5 digits, if your like
database was only going to
accept 5 numbers, you might hit
some problems ingesting this.
Country is another example where
you might trip up.
This is a localized country
name.
There's actually another field
that the user doesn't see called
country code.
You should use that instead,
because country code is always
going to be accurate.
This is in the language of the
user.
So, you may well be like, OK I'm
going to string match United
States, USA, all of its
variants.
Well, surprise, your user is
French and this field is
actually Etats-Unis and you
can't now ingest it.
So, don't use country, use
country code.
The phone number also could trip
you up.
It has some dashes.
So, if your system was only set
up to accept numeric digits you
could have some problems.
But it's also got a country
code, which could trip you up.
So, be prepared for fuzzy input.
Don't force the user to comply
with your business logic.
There are lots of techniques you
can do to validate addresses.
For example instead of using the
state field directly you can
infer it from the zip code.
That's an example.
There are lots of tools to help
you pass phone numbers, both
tolls available within iOS and
also third party tools.
You might wonder, well why
doesn't Apple Pay do this for
me?
Well, your business logic may
actually differ from another
merchant's business logic.
One merchant may only accept
phone numbers with a country
code.
Another merchant may only accept
phone numbers without.
And you don't want the user to
like have to create two
different addresses, two
different phone numbers.
So, don't force the user to
comply with your business logic.
Now, we are going to help you a
little bit.
There's some new API's within
the context framework to support
worldwide addresses.
The example I gave for you was
from the US, but these problems
actually happen throughout the
world.
There are new fields in contact
for something that's called
supplementary sub-locality.
That's very applicable in China.
In Japan, now, within Apple Pay
you can request phonetic name in
addition to regular name,
another very important addition
there.
But despite all of these, and
despite your best intentions,
things can still go wrong.
The USPS may be able to deliver
this to Santa, but I cannot.
I know not where he lives.
So, what are somethings that can
go wrong?
The phone number could just be
missing digits entirely.
The postal code and address
don't match.
The email address is misspelled.
The address is otherwise
unusable.
And so, we're going to introduce
some new API to help you out
with that.
And we call it custom errors.
Custom errors let you gracefully
handle invalid or incorrect data
in Apple Pay.
And they also let you display
custom error messages.
Your own error messages directly
in the Apple Pay sheet.
You can direct the user to
specific fields that need
correction.
Let's go back to my delightful
avocado toast app.
The delivery wasn't working, so
I've gone back to subscriptions.
We're going for our series A
funding.
And you'll see here, I've got a
shipping address error.
Shipping address incorrect.
And that's not very clear, but
if the user taps in, you'll
actually see, now we have a
custom error that was provided
by the application.
Your zip code doesn't match your
city.
And if you go through even
further, we'll actually
highlight the individual fields
for the user to correct.
You'll see an example in Jon's
demo, shortly.
Now, one unfortunate side effect
of this is that we've had to
deprecate a little bit of API.
All of our completion handlers
in the past in Apple Pay took,
as I mentioned this Enum.
Well, we didn't really want to
have hundreds of different Enums
for each type of error.
So, instead we're replacing them
with an object.
In this case, this is the
delicate callback when a payment
is actually authorized and you
return a
PKPaymentAuthorizationResult.
So, we have to do little bit of
renaming.
Now, this result object contains
a status and it contains an
array of errors.
Now, the status is the status
that you're used to.
The payment was successful or
not.
If you, for example, have a
successful payment, you simply
return a result with no errors
and a single status set.
But the errors themselves just
standard NS errors describing
what went wrong.
Each error represents an
individual problem with a
payment.
And you can chain errors
together.
So, you can have more than one.
If the user's email is wrong,
phone is wrong, shipping is
wrong.
You can just do it all in one
go.
Now, you use NSError codes to
indicate the issue and User Info
Keys on NSError to provide
specific resolution steps and
information.
Now, creating NSErrors can be a
little bit laborious and so
we've got some factory helpers
to assist you here.
Here's an example in Swift.
I'm creating a payment shipping
address invalid error.
And you'll see that this takes
two properties at two
parameters.
It takes a CN contact key
indicating the field that was
wrong.
So, in this case, the error is
the user put a wrong country in
and we only deliver to the US.
So, I say CN postal address
country key.
And then the localized
description.
This is a localized error that
you provide that will be
displayed in the sheet.
Now, in ES6 and JavaScript,
obviously NSError doesn't exist.
So, we have a new type called
Apple Pay Error.
You can check for the existence
of this type to determine
whether Safari supports this new
API.
And here you provide the type of
error, shipping contact is
invalid.
The field it relates to,
country, and your localized
description.
And most of our delegate
callback have changed.
So, here's another example,
didSelectShipingContract, and it
takes an object,
PKPaymentRequest
ShippingContactUpdate.
Now, like for like APIs are
available in Safari 11.
Safari 11, only on iOS 11 and
macOS High Sierra.
It's not support on Safari 11
running on older versions of the
operating system.
Now, because JavaScript is a
little more forgiving when it
comes to API's we haven't had to
actually make a deprecation
here.
The existing completion
functions have nearly been
overloaded.
So, here is the old API, you'll
see we passed in individual
items, the total, the line
items, the status.
And the new API, we simply pass
in an object.
So, if you're actually writing
Apple Pay on web, this is a
pretty straightforward change
for you.
Now, if you are writing Apple
Pay in application, I want to
show you that it's really not
that much work to implement this
new API.
And to do that, I'm going to ask
Jon to come up and he's going to
give you a quick demo of how to
migrate an Apple Pay App.
Jon.
[ Applause ]
>> Hi, everyone.
I'm Jon and I'm going to show
you how easy it is to update and
existing Apple Pay project in
Swift, to the new API.
So, I'm going to be going
through four things today.
First, I'll take a look at an
existing project's code and see
its current implementation.
And if you've worked with Apple
Pay before, most of this stuff
will be familiar to you already.
Second, I'll deploy the app to
the simulator and interact with
the Apple Pay sheet as if I were
a customer of your app trying to
ship an item to one of my
friends.
The next thing I'll do is I'll
update the code that we have
with the new API and show you
three different errors that
we've introduced this year.
And lastly, I'll deploy the app
again to the simulator and show
you the differences in behaviors
from the old Apple Pay sheet and
the new Apple Pay sheet.
So, let's take a look at what we
have.
So, as you can see, our app is
pretty simple.
It has an image of the item that
we want to purchase, as well as
a Buy with Apple Pay button.
So, let's jump into the code.
The first function we have is
viewDidLoad and in here, we're
creating a PKPayment button,
setting the type to buy and the
style to black, as well as
adding it to the view.
And in the add to view function,
we're adding various constraints
to it as well as setting the
target, when I click it to this
next function, startPayment.
So, let's take a look at that.
So, here the first things we do
is create a few PKPayment
summary items, as well as a
PKShipping method.
And then the last thing is
create an array of those objects
that we'll later pass in to the
PKPayment request.
So, let's take a look at the
payment request.
Here, it's pretty simple.
After we initialize it, we set
the payment summary items to the
items that we created before, as
well as set various properties,
such as a merchant identifier,
the capabilities.
Etcetera, etcetera.
The last thing, this last line
is probably the most important.
It's required shipping contact
field.
And this is a new property in
PKPayment request.
And here it takes in a set of PK
content fields and in this case,
the developer is requesting the
user provide an email address,
as well as a postal address.
So, the last thing we do in this
function is create a PKPayment
authorization controller, with
this payment request that we
created.
Set the delegate to ourselves
and present it.
So, that's pretty simple.
So, let's take a look at the
protocol.
The first function we have, it's
a didSelectShippingContact
function.
So, this gets called whenever
the Apple Pay sheet first comes
up, as well as whenever a user
edits one of their addresses, or
selects a new address.
And you can tell that this is
the old API because this
completion block takes in a
PKPaymentAuthorizationStatus
Enum.
Another thing to note is that
this contact information is
actually redacted, so you don't
get information like the email
address, the phone number, or
the street until the user
authorizes the payment.
So, let's see what we have here.
So, we're doing some basic
validation and in this case,
we're just checking if the state
is valid.
And if it's not, we set the
status to
invalidShippingPostalAddress.
Otherwise, we set the payment
status to success.
The last thing we do, it's
called the completion block,
with that paymentStatus, as well
as the same shipping methods,
and the same payment summary
items.
Of course, you can update the
shipping methods and the summary
items if you needed to.
But in this case, we're just
passing the same ones.
So, the next function we have is
the didAuthorizePaymentMethod.
And this gets called after the
user authorizes the payment,
using Touch ID, or with
Passcode.
And another thing to note is
that this PKPayment object
contains a property shipping
contact, with the full contact
information.
So, you're given the email
address, the phone and the
street that you were not given
previously.
So, we hope that you can
validate the full contact
information in this method.
And for simplicity sake, all
we're doing is checking the
email, but you can do more of
course.
And if the email check fails, we
set the payment status to the
Enum invalidShippingContact.
And if it succeeds, we set the
payment status to success.
The last thing we do is call the
completion block with that
status.
So, let's see how this works
after we deploy it and interact
with the Apple Pay sheet in the
simulator.
So, the app comes up.
We tap the buy with Apple Pay
button.
And the Apple Pay sheet comes
up.
So, let's say I want to ship
this to my friend Sarah.
After I select shipping, I can
select add shipping address and
as you can see, this is the new
UI to add a shipping address.
So, you can either enter it
manually or search one of your
contacts, or use one of the
suggested locations that the
Apple Pay sheet provides for
you.
In this case, I'm just going to
select my friend Sarah.
She lives in Hawaii, so it might
be a little bit, there might be
some problems with the address.
Well, let's see.
Of course, there's an error.
And you can see that the text is
red so the user knows that
there's something wrong with the
address.
But it's not really clear where
the issue is.
As I look at it, the street
seems fine.
Hawaii is a valid state.
Everything looks fine.
And so, if I select that, again,
there's not a lot of information
on what's wrong with the
address.
I know my friend, Daniel, likes
this item as well.
So, he lives in California.
So, let's just see if we can
ship it to him.
After we got back, it looks like
there's no more error.
So, there must have been
something wrong with Sarah's
address, but it wasn't clear to
me what was the actual issue.
So, let's try to authorize this
payment by hitting the Pay with
Passcode button.
The Apple Pay sheet shows that
there's an error with the
contact.
Again, the text is highlighted
red.
And if I select that, there's no
clear text showing what's wrong
with this contact information.
It could be the percent sign, it
could be just I don't like an
iCloud.com email address.
So, let's just select Daniel's
real email address to see how
that works.
After we select that, we hit Pay
with Passcode and the payment
succeeds.
Okay, so that's good.
But as a user, it was really
difficult to figure out what was
wrong with the address that we
had previously.
So, let's implement the new APIs
that we have.
So, the first function that we
have is a
didSelectShippingContact method.
And here it takes in a
PKPaymentRequest
ShippingContactUpdate object.
The first thing we want to do is
we have a local variable of the
update before and we don't
initialize it yet.
We'll initialize it afterwards,
after we check the errors that
we have.
The next thing we do is create
an array of errors that we'll
append to as we validate the
address.
So, similar to before, we're
checking if the state is valid.
And if it's not valid, instead
of setting the status to an
invalid shipping address, we'll
append an error, a new type of
error.
A paymentShipingAddress
UnserviceableError.
And in here, all it takes is a
localized description.
And in this case, we're saying
that we're unable to ship to
this state.
Let's see, we'll add another
check that we didn't do
previously, which is check if
the zip is valid.
And this is another type of
error a paymentShippingAddress
InvalidError.
And this takes in a key, a
CNPostalAddress key.
And in this case we're taking a
CNPostalAddress postal code key,
which tells PassKit to show
where the error is while the
user tries to edit their
address.
Again, this takes in
localizedDescription, the zip
code doesn't match the city.
Yeah, so let's continue.
And the next thing we do is
check if the errors array is
empty.
If it is, we'll initialize our
update object with the
paymentSummaryItems, unchanged.
Otherwise, we'll initialize the
update object with the errors as
well as the payment summary
items and the shipping methods.
So, the last thing we do here is
call the completion block, with
this new object.
So, let's fix our
didAuthorizePayment function.
So, this is the old code that we
have, so we can comment that
out.
And the first thing we do,
similarly to before, is create
an array of errors that we'll
append to.
In this case, we're checking one
thing, which is if the email
address is valid or not.
And if it's not, we'll append
another type of error, a
paymentContactInvalidError.
And instead of taking a
CNPostalAddress key, this takes
in a PKContact field key.
And here, we're passing and
email address so that it can
show in the correct location.
Okay, and that takes another
localized description that will
be presented on the Apple Pay
sheet.
Similarly, we're checking if the
errors array is empty.
If it is, we'll set this status
to success.
Otherwise, we'll set the status
to failure.
And the last thing we do is call
the completion block with
initialize
PKPaymentAuthorizationResult,
using that same status as well
as the errors that we created.
So, let's see how this works
after we deploy it.
After the app comes up, we'll
hit the Buy with Apple Pay
button once again.
And immediately we're presented
with an error.
The app doesn't ship to this
shipping address.
So, this is one of the new
errors that we've introduced
this year.
And there's a shipping
unavailable text underneath out
contact.
After I select that, there's
text underneath our contact
saying unable to ship to this
state.
So, this is pretty clear to the
user, saying that the app
doesn't support shipping to
Hawaii.
Let's try to ship this to my
friend, John Appleseed whose
shipping address is in
Cupertino.
After I select that, an error
shows up saying that the zip
code doesn't match the city.
And if I select that address,
the zip code is highlighted in
red.
And because I know that 12345
isn't the proper zip code to
Cupertino I can fix that and
write 95014, hit done to save
it.
Go back, and I fixed all the
contact information, or the
address issues that I've had.
Again, let's try to pay with
Passcode and see that we have an
error with our contact
information.
After we click that, we see that
there's an invalid character
found in the email, which is the
percent sign.
So, as a user I can edit this
email address to remove that
percent sign, or I can just
select another email address.
So, I'll select John Appleseed's
email address, at mac.com.
I went back, hit pay with
Passcode, the payment should
authorize.
And that shows you with the new
APIs that we introduce in iOS
11, you have the power to give
more feedback to the user when
dealing with addresses on the
Apple Pay sheet.
And we hope that this creates a
better user experience, when
users are using Apple Pay within
your apps.
Thank you.
[ Applause ]
>> Thank you Jon.
I hope you all go off and take
the time to update your apps.
I want to talk briefly about
what's new with Wallet.
If you've downloaded [inaudible]
of iOS 11, you might have
noticed one major thing that's
new with Wallet, it looks a
little different.
It's a little brighter.
There's also, if you haven't
found it yet, a new mass
deletion management interface
for your passes.
This new color scheme means that
it's probably a good time for
you to revisit your past
designs.
Take a look at them, make sure
that they look great.
If you never updated them to
have watch assets or 3x assets,
may be a good time.
Well, I also want to give you a
quick update about NFC passes.
NFC passes are regular passes
that let you send customer
information over NFC.
Starting in iOS 11 we are only
going to support a more secure
type of NFC pass that we call
encrypted NFC passes.
If you'd like to know more about
NFC passes, you can check out
last year's session.
You can also go to our
developer's site and find out
more, and register to take
advantage of them.
Now, there's one minor new
feature in Wallet this year for
passes.
And that's sharing.
Much requested feature, passes
can now be opted out sharing.
This is useful for single use
items like loyalty cards of
tickets.
It's really easy to take
advantage of.
It's just a top level JSON key
in your pass JSON.
Here it is sharingProhibited.
So, your gift cards, your
loyalty cards.
You set this to true and the
user can't share it via airdrop,
iMessage.
This is a convenience feature,
not a security feature.
Obviously, users can still share
in other ways.
It won't be supported on older
versions of iOS.
But it's good if you need a good
reason to not allow the user to
share for pure experience
reasons.
That's what's new with Apple Pay
and Wallet.
We saw some guidelines for
building best in brands Apple
Pay experiences, new API for
handling complex errors, and new
ways to share interact passes in
NFC.
And for more information on any
of these things, you can check
out our developer site.
There's something else you also
might want to check out and I
suspect a lot of you in the room
are extremely excited by.
And that is the Core NFC
framework.
Now, you can read NFC tags on
supported hardware.
Now we have a special session
for this.
It's online only.
It's available now.
It's just search introducing
CoreNFC on the WWDC site, check
it out.
That's everything from us for
this year.
I hope you go out now and have a
great beer bash and I hope we'll
see you next year to talk even
more about Apple Pay and Wallet.
Thank you very much.
[ Applause ]