What's New with Wallet and Apple Pay

Get the latest news and updates from the Wallet and Apple Pay teams. Learn how to integrate Apple Pay into more places than ever before including watchOS, iOS Messages and Intents extensions. Learn about new tools to make testing and developing your Apple Pay-enabled apps even easier. We'll also cover new features in Wallet for retailers, banks, and card issuers.

WWDC 2017

WWDC 2016

Hello again if you just came
from the previous session, thanks for staying.
And hello if you're new.

Hello to everyone downstairs,
and hello to everyone watching online.
My name is Nick, I'm joined today by my colleague, Leo,
and we're going to talk about what's new
with Wallet and Apple Pay.
First of all, we're going to have an update for Wallet.

We're going to talk about passes.
We're going to talk about some new features
for banks and for retailers.

And then we're going to talk about WatchKit,
now you can use Apple Pay not just to pay in-store
on Apple Watch, but also inside WatchKit Apps.

We'll also talk about something I'm really excited about
and that's the new extensions on iOS, Siri, maps, and messages.
All of these new extension points
that can be enabled with Apple Pay.
And finally we'll talk about something exciting and new,
I think you're all going to love, testing Apple Pay
and the new Sandbox environment.
Let's get started.
What's new with PassKit.

So, hopefully you'll be aware
that Wallet isn't just Apple Pay, it's passes as well.
And there's no better time to start using passes
because more users are engaging with Wallet
than ever, due to Apple Pay.
More people are opening the Wallet App,
more people are using it.
Now, we don't have time today to run through the pass ecosystem,
but we do have some resources for you.

I'll tell you a little bit about them just to remind you,
don't worry, not too much.
Passes enable you to get gift cards, boarding passes,
rewards cards, event tickets, membership cards,
and more directly into the user's iPhone or Apple Watch.
And you can distribute these passes in many ways,
through an app, through email,
SMS or iMessage, web link or QR code.
And these passes can be updated remotely.

And these updates show up on a user's lock screen.
Things like date changes, for an airline ticket, or relevancy.
Your passes can be relevant, if you're near the store,
they'll show up on the lock screen.
We have a session that talks a little bit about some
of these passes and provides you some more resources.

It's the home for Apple Pay and more,
it was last year's session.
And there's plenty of great resources
at developer.apple.com.
Let me talk now about a few new changes.
Some things we've changed over the past year
that maybe you didn't notice.
One of them was app placement.
We've actually changed the pass design a little bit,
this happened in iOS 9.3.
Apps are now placed on the front of passes
and these app icons can deep link directly
into your applications.
So these are great for things like gift card top-up,
if you're a gift card pass and you want and easy way
for the user to quickly top it off, or an airline,
you want to go to the app
for more information about the flight.

And it's very easy to add this, you just need to add the pass
to your pass, the apps ID, it's Adam ID from iTunes,
and also its URL scheme to deep link in if you want to do that.

Last year we also introduced a new type of pass,
the value-added services pass.
So passes can now transmit information securely over NFC.

Things like loyalty card information,
if you're in the US you might have used the Walgreens Pass,
which lets you transmit over NFC.

And support for value-added passes has grown
over the past year for many points of sale systems.
Verifone, Ingenico and many other manufacturers
of payment terminals now support this protocol.
There's some things you may not know
about value-added service passes,
they also support what we call a one tap experience.
It looks a little like this.
It's where you actually place the phone
on the payment terminal
and you'll transmit both your payment information
and your loyalty information in a single tap.

So it's deeply integrated into the purchase process.
This also works with Apple Watch as well.
Now these value-added service passes can also be distributed
over NFC, and you can even sign up for loyalty programs
from these NFC distributed passes directly from Wallet,
to be shared and personalized.

You can actually sign up for a loyalty program right there.
Now, there are a few caveats to the value-added service passes.
One of them you might be aware is that passes need
to be signed using a different certificate.
Regular passes are signed with a certificate you create
at the developer portal, but value-added service passes need
to be signed with an NFC signing certificate.
Now, you need to request these certificates.
You can contact us to find out more.

I'm actually going to have a link
at the end of this presentation.
So you can go and request more information
about using value-added service passes.
And we're also going to have some engineers in the labs.
We got a lab right after this session,
so if you have any questions please come down,
we'd love to talk to you.
Let's talk about a few other new features in PassKit.

Now these are specific to card issuers,
but I think they're pretty interesting,
even if you're not a card issuer,
you might be interested to know about them.
We offer some unique features
for card issuers who use Apple Pay.

We also now support store credit and debit cards.
Here's a Kohl's card.
So if you have a store card you can add them.

So these aren't just for banks, they're for retailers as well.
One really great feature is app provisioning.
Now, we added this last year and a couple
of apps have already adopted it, Discover is one of them.
This lets you set up cards
in Apple Pay directly from your own app.

You never need to leave you app,
to open Wallet, to open preferences.
And it's available to any existing Apple Pay issuer.

Now the API is documented on developers.apple.com.
But you can also contact us for more information.
We actually have an email address, which I'll show
at the end, and we're going to have people in the labs to help.
We also have this great new button style,
which you can use both for adding cards,
but also for adding regular passes.
So if you're just a pass developer,
you can use the new PKPaymentButton style I'm
showing you here.
I'll have some codes to show you how to do that in a minute.
Now something that's new in iOS 10 is specifically
for card issuers and retailers who might have partnerships,
either co-branded cards, or they've got a partnership
with a bank, we now let you enable a new
in-store experience.
You can present your cards directly from your apps.
A really good use case of this, you can redeem a coupon
from your app and immediately present a payment method.
So maybe your app is enabled with iBeacons,
it's got a great in-store experience.

So you go into the store, you redeem a coupon in the app,
you just press a button and you can immediately pay
with Apple Pay.

The card could be right there in your app.
It's a really easy API to use.
It's just on the Pass Library.

And you can use the new PKPaymentButton style
for some consistent branding.
And this is the style .inStore.

We have another style I just showed you to add it
to different class actually, it's an Add to Pass Button,
but take a look
at the documentation for more information.
Another feature that's pretty interesting is associating your
applications with your cards.

Again, this is great if you're a retailer
and you have a co-branded card or you have a partnership
with an issuing bank, you can associate your app
with your store or program cards,
which means it can default, if the user wants to do that.
Here's the screen you'll get for a VAS pass,
but it's the same for payment passes.
You can default your card when paying over NFC,
or new in iOS 10 you can also default
when paying with an application.
And also a website if you're taking advantage
of the new Apple Pay on the web stuff.

Now the great thing about most of this is that no API required.
It's actually built into the card itself.
All you need to do is get your app, and its Adam ID
and URL scheme into the pass when it's added to device.
Now to do that you can talk to your issuing bank,
or if you're an issuing bank, you can come talk
to us using the contact information at the end
of the session, or come and see us in the labs.
So that's some of the new stuff in PassKit.

I want to talk now about Apple Pay and what's new in Apple Pay.
And I also want to tell you how Apple Pay has been doing.
So Apple Pay is an easy, secure and private way
to pay both in-store and within applications.
And it's got amazing customer satisfaction.
It has one of the highest customer satisfaction rates
of any payment method.
And Apple Pay is usable today within applications.
You can pay using Apple Pay directly from apps.

And thousands of apps have already adopted worldwide
in the US, in China, an example here.
We've recently announced we're launching
in France, also Australia.
We've got many countries that support Apple Pay.
And millions of users are enjoying using Apple Pay.

And we've seen incredible growth of Apple Pay, both in-store
and within applications.
And developers such as yourselves have seen some great
results too.
Here's two apps that I want to talk about.
One of them is Chairish.

Now the Chairish app, they found
that when they used Apple Pay their conversion rate tripled
from other payment methods.

That's a huge increase.
I can't think of another payment method
that has such great results.

And StubHub in their iOS application found
that Apple Pay was driving twice as many new users
than any other payment method.

So this isn't just for your existing customers,
Apple Pay can bring you new customers as well.
Apple Pay apps are often highlighted on the app store
in their own sections.
We often run promotions of Apple Pay apps.
We've also seen some great results in some
of the new countries we've launched in.
One country I want to briefly talk about is China.
We've seen some great applications in China.

I was so lucky to go to Beijing a few months ago
and taught some developers using Apple Pay
and they've seen some great results too.

Apple Pay in China offers full support
for China UnionPay credit and debit cards.
And the Apple Pay API is accepted by CUP,
that's China Union Pay, PayEase, Lianlian Pay, YeePay, and UMS.
These are major Chinese payment processes.
We also have documentation both interface guidelines
and our Getting Started Guide are available in Chinese,
they're also now available in French as well,
now that we're launching in France.

You can check out our developer site for links to those.
Now I want to talk about some new API and if you're developing
for Apple Pay already,
you're probably really going to love this.
One of the problems with Apple Pay has been the need
to set your networks upfront.

You need to tell us the networks you want to use
in your payment request.
So that's hard coded into your application.

And adding new networks is difficult.
You either have to perform SDK availability checks to tell
if the constants are available, or you have to try
to hack something together, it's not ideal.
And for those of you who have Apple Pay apps maybe you
remember when we launched Discover on Apple Pay,
last year, unless you went and updated your app,
you probably weren't able to accept them even
if your payment processor could.

So we're introducing something new in iOS 10 to help with that,
it's dynamic networks and proxies.
Firstly, we're adding a new class method
onto PKPaymentRequest.
It's going to tell you all of the networks
that are available on that device.

There's PKPaymentRequest available networks.
We're also going to enable something else.
You're going to be able to set payment process
as supported networks.
And these proxy down to other networks.
So for example, if my payment processes supports Visa,
MasterCard, AmEx and it's enabled here, I just put them
in as the supported network and I'll get all
of the networks automatically.

And perhaps most importantly, I'll get new networks
as they're added to Apple Pay without needing to do anything.
So you can check our developer site for information
about payment processes that are going to participate in this.
It's a really cool feature, it's going to save a lot
of pain I think for writing Apple Pay applications.

One other thing we've changed, I just want to touch on, Swift 3,
maybe you've already seen some of the big changes in Swift 3.
We have improved our API for Swift users.

We've actually completely rewritten our sample code,
talk about that later.
One change that's coming, didn't make seed one,
but it will be in seed two.
PassKit now uses stringly typed enumerations.
If you're not sure what those are, they're a very cool way
in Swift to take string constants and turn them
into enums, which is going to make developing
for Apple Pay a lot easier.

Now let's talk about Apple Pay in general.
This year we've got three big new places
where we're adding support for Apple Pay.

We're adding support to WatchKit for WatchKit apps.
And we're adding support to new extension points on iOS.
And finally we're adding support to Safari,
both on MacOS Sierra and on iOS 10.
Now we just talked about Safari in the previous session.
It's online right now.

You can check it out.
Let's focus today, right now WatchKit and extensions.
I'm going to start off with WatchKit.

And to talk more about WatchKit and to show you how easy it is
to integrate Apple Pay on to Apple Watch, I'd like to ask Leo
from the WatchKit team to come up.

Leo.
Thanks, Nick.

Hello everyone.
My name is Leo and I'm a software engineer
on the Apple Watch team.

I'm really excited to tell you about what we are doing
with Apple Pay on the watch this year.
We're adding support for making payments within WatchKit apps.

We think this is going to enable a whole new category
of apps on the watch.
And the great news for you developers,
if you have implemented Apple Pay on your iOS app,
the same code with work on watchOS,
with very minimal changes.

So let's take a look at what we're going to be covering.
First we're going to do a quick recap
on how payments work on the platform.

I'm going to show you how to create a payment request and how
to present a payment sheet.
And then we're going to do a quick demo.

So you get an idea of how easy it is to get started
with Apple Pay on the Watch.
Finally, we're going to talk about some
of the design considerations that you should keep in mind
when designing specifically for the watch.
This is the Apply Pay experience
that your users are familiar with in iOS.
Now let's bring up the watch.
The first thing you notice is that the UI is very simple.

We only display the total amount
and the merchant name at the top.
And users can simply double press the side button
to pay at any time.
If they want to make any changes,
or review their information, they can scroll down.

And they can have access to their different payment cards,
as well as shipping, billing and contact information.
And they can see a detail of what they are paying for.

When they're ready to pay,
they simply double click the side button and it's done.
It is that simple.

Now let's take a look at how payments work
from a developer's point of view.
We follow the same flow that we have on iOS right now.

First you create a payment request and you pass that in
to a payment authorization controller.
This is the object that drives the payment sheet
on our platform.
As the user interact with the UI,
we're going to call your delegate,
for example in the payment method, or the shipping address.
And you may use this opportunity to perform some validations.
For example, you may not ship certain products
to some countries.
Or you may want to update the shipping cost
and the total amount on the UI.

When the user confirms the payment,
we talk to the secure element in our Apple servers
and we issue a payment token that you can use
to process the payment.
Now refer everyone to the code, a quick note,
there is some setup that you need to do
to enable Apple Pay on your apps.
First, you want to go to the Developer Portal
and register a merchant identifier and a certificate.

You may have done this already for your iOS app.
And then you want to enable Apple Pay
for your WatchKit extension separately.

And there are step by step instructions
on our website on how to do this.
Now let's take a look at the code.

This is how you create a payment request.
We use the same PKPaymentRequest object that we have on iOS.
You create one of this and you set it up with a country
and currency code, your merchant identifier,
and the payment network sync capabilities that you support.
And then you specify a list of summary items
that describe what the user is paying for.
Always remember that the last item
on the list represents a total amount.

And we recommend that you use your merchant name as the label,
since we display that at the top of the payment sheet.
When you want to present a payment sheet,
you create a PKPayment AuthorizationController
and you pass in the request that we just created.
Then you designate yourself or some other object as a delegate,
and you simply code present.
Now, since you're presenting the payment sheet,
you're also responsible for dismissing it.

So make sure to do that when we go
to payment authorization controller DidFinish
in your delegate.

So PKPayment AuthorizationController.
This is a new controller class provided
in the PassKit.framework.

It is responsible
for controlling the payment authorization flow.
And it has the same API semantics
as of PKPaymentAuthorization ViewController.
But since it's not view controller based,
it allows for presentation of the payment sheet
from your WatchKit extension.
It is supported across watchOS and iOS,
so you can share your user code across different apps
and across different platforms.
Now, let's put all of this together and see a quick demo.
So I have been working on this app for a coffee shop,
so that users can order and pay for their drinks right
on their watch and have it ready when they get to the shop.
Let's take a look at my interface so far.

Great. So we have a product view almost done, now we just need
to add a way for users to pay for this.
I'm going to go to the Option Library
in the bottom right corner and search for a payment button.
We provide you with this object that you can use when you want
to present the payment sheet.

We just need to drag and drop this into our view.
And now let's add some code.
I'm going to bring up the assistant editor
so I can have the code and the UI side by side.
I'm going to control drag from my button to my interface.
And create a new action that I'm going to name Buy.

Now let's just focus on the code.
First of all, since we're going
to be using the PassKit framework,
let's make sure we import that.
And now we're going to implement the buy method and it's going
to be pretty similar to what we saw on the slides before.

First, we're going to create a payment request.
In this case we're setting it up for the US,
we're going to be charging this in US dollars.

We specify the merchant identifier
that we registered is available portal,
and the payment networks sync capabilities list
that we support.
And finally a list of summary items,
in this case we're just using the total for the coffee.

Now, if you want to present the payment sheet,
we create a PK Payment Authorization Controller.
We pass in the request, we set our self
as a delegate, and we call present.
Now for seed one we ask you that you keep
around Payment Controller while the payment sheet is visible.

Let's define the state that we're using here.
And then since we're implementing the delegate
protocol let's conform to that.

And we only have to implement two
of the required methods for this to work.
The first one, PaymentAuthorizationController,
these authorize payment.
It's going to be called when the user confirms the payment.
And we provide you with all the information that you need
to send to your payment processor
and to confirm calling the completion handler
with a status.

The second one, as I mentioned earlier,
PaymentAuthorizationController DidFinish.
It's another opportunity for you to dismiss the payment sheet
and perhaps present an order status at the end.
This is all we have to do.
So let's try bill and run this.

Okay, there's our app.
I'm just going to click the Buy with Apple Pay Button,
and there we have the payment sheet.

It's very simple, we have different payment cards
that we can try.
And if you went to simulator,
user action of double clicking the side button,
there's a new option on the simulator menu, under Hardware,
and it's called Authorize Apple Pay.

We just click on this and it's done.
Our payment is confirmed and the coffee should be ready
pretty soon.

So that's our demo.
As you can see it's very simple to implement Apple Pay.

It only took us just a few minutes and less
than 50 lines of code.
Now, before we finish this section,
I want to talk about design.
How do we make something easy for users of Apple Watch?
Perhaps the most important thing here is to consider what kind
of experience you want to bring to the watch.
Users are not going to spend more
than just a few seconds interacting with your app.

So try to offer them something they want,
and direct them quickly to the payment sheet.
Remember that the interactions are short and screens are small.

Next, don't request information that you don't need.
This could be, for example, a contact email address.
While we offer users the same options that they have available
for billing and shipping on the iPhone, there's no way
to enter a new one right on the watch, so keep that in mind.
And then as we said in the demo,
use the Payment Button that we provide.
If it's available on the WatchKit framework,
it is supported on Interface Builder,
so it is super easy to add.
And please follow the guidelines that we have on our website.
This is probably more detail how the Payment Button should be
used in the context of your app.
So to summarize, if you have an iOS hub
that implements Apple Pay most of the same code will work.

You just need to make sure
to implement PKPayment AuthorizationController
and use the present and dismiss methods that it provides.

When you're designing apps for the Watch,
remember that the interactions are short,
and the screens are small.

And use the Payment Button
that we provide following our guidelines.
If you haven't done so already, I highly recommend you checking
out last year's session on Apple Pay We Announce,
which goes into a lot more detail on how
to create this kind of experiences,
and how to customize the payment sheet in different ways.
I'm really excited to see what you'll create
with Apply Pay on the Watch.

And now I'm going to turn it back to Nick who's going
to tell you more about extensions.
Thank you very much.

Thank you Leo.
Okay. Extensions.

In previous releases, Apple Pay hasn't really played
that well with extensions.
It's been difficult to support in extensions,
probably because we've always needed a view controller
to present from, and not all extensions are UI based.
Frankly, there also weren't
that many interesting places to use it.
There weren't that many extension points on iOS 9
and iOS 8 that really lend themselves to Apple Pay.

But that's changing in iOS 10.
We've got some new opportunities.
The new extensions, in iOS 10 work really well with Apple Pay
and they have built-in support for Apple Pay.
And we've solved the problem of not being able
to display in a non-UI context.

The PKPayment AuthorizationController API
that Leo showed you on watchOS, is also available on iOS.
You can actually use it anywhere in an app, or an extension.

I want to show you some extensions that use Apple Pay.
We gave the extension's API the iMessage app API to Fandango
and they use it to purchase movie tickets.

There's some other things you can use it for.
You can use it to split items and purchases,
send gifts to friends, organize outings.

So here you can see, Fandango you picked a movie,
suggest with your friends, bought the tickets,
we never leave messages, we're still in messages.

And you're done.
It's really easy.
I want to show you another use of Apple Pay.

It's Apple Pay in Siri and Maps in the Intents framework.
So there's a new ride sharing extension point
that works both in Siri and in Maps.

And you can use Apple Pay within that extension point,
it's actually built in.
So you can pay directly from the extension.

I'll show you a short video of that.
The sample code that we've developed this year,
actually has a ride sharing intent.

So here we're asking Siri
to book a ride using our sample app.
Siri asks us if we want to get a ride, we say yes.

The Apple Pay sheet's immediately displayed.
I can touch ID, and then I can be on my way.
It's that easy.

I never have to leave Siri, I stayed right there,
never have to go to another app,
never have to put any payment information in.

This is great if the user never has a relationship
with your app, if they've never used your app before,
they can still pay for things.

They don't need to have an account.
And so requesting and presenting payment
in these extension points is identical to WatchKit.

There's no difference.
You can use this new PKPayment AuthorizationController
in both your UI and your non UI extensions.

And I actually recommend that you share your payment code.
You can have a centralized payment class,
and you could share that between Watch,
iOS app, and iOS extension.
That's actually what we've done with our sample code.
So we've rewritten the Emporium sample app we released last
year, it's been rewritten in Swift 3.
It's been simplified.
So it's a lot easier to understand.

And it shows a shared Apple Pay model,
where the actual payment logic is the same,
regardless of the platform that you're on.

So, download that and try it out.
Of course, you might have a little problem trying it out,
and that brings me on to testing Apple Pay.

I saved the best until last for you.
Testing Apple Pay today
if you've developed an Apple Pay app,
you'll notice it's a little tricky.
You can test on the simulator.
And we've actually got some great new support
in the simulator.
You saw the new authorized Apple Pay Button on the simulator
for Watch, we're also bringing that to iPhone in seed two.

And you can test your iOS, your WatchKit, even Apple Pay
on the web, you can test on the simulator in Safari.
Now the simulator returns dummy payment data.

Its payment data is completely fake.
It's not real and it's not useable for anything.
So it's really useful for UI development and quick testing.

But it's not particularly useful for end-to-end testing.
It's not real card data, and the simulator is just not
representative of device behavior.

You know we always tell you, please don't use the simulator
of your sole way of developing, you have to test on hardware.
But with Apple Pay that's not always feasible.

Apple Pay is available in many countries,
but not all countries.
Maybe your developers work abroad,
or you don't have a card that's eligible.
Okay, we're going to solve that today.
We're going to introduce the Apple Pay Sandbox environment.

The Sandbox is a brand new testing environment
for Apple Pay and it lets you provision test cards directly
onto real devices and the data
that it returns is real payment data using these test cards.
So it's just like paying for something with a real credit
or debit card in Apple Pay.

It's really easy to use and it's really easy to set up.
And you can integrate it into your QA environments,
where previously perhaps you couldn't due to restrictions
on production financial data.
Getting set up with the Sandbox is really straightforward.
All you need to do is create a testing iCloud account
at iTunes Connect.
Now you can already do this for various other features,
so this already exists today.

You then just log into that account on your device.
If you're not in a region
that supports Apple Pay you can change your region to,
say the US, or to Canada.
And then you just use the test cards that are published
at developer.apple.com.

We have a list of test numbers that you can input.
There will be provisions
to Apple Wallet just like regular cards.

There's no developer setting or switch.
Environment's a switch automatically,
where you sign in and out of iCloud.

Now you should still validate your apps
with production cards before you launch.
You still should do an end-to-end transaction.

I think this is going to be a really great environment,
a really great feature to help you test.
And actually if you're using Apple Pay on the web,
which we talked about in previous session,
initially you're only able to test it in the Sandbox,
because we're not going to roll out production support
until later, nearer the time we actually GM iOS 10.
So the Apple Pay Sandbox today supports three networks,
it supports American Express, MasterCard and Visa.

And more networks will be coming on board overtime.
We're also hoping that the Sandbox can be integrated
in various payment processes.

So you can do that,
it's available today if you're on iOS 10.
So let's have a quick look at some
of the stuff we talked about today.
We talked about some new Wallet and Apple Pay API and features.
Some of the new things that we've introduced
over the past year and in iOS 10 that help host developers,
card issuers and retailers.
And we talked about Apple Pay and WatchKit.

I think Apple Pay WatchKit is really great.
I can't wait to hail a ride directly from my Apple Watch
without ever needing to pull out my phone.

We also talked about Apple Pay in extensions.
I think there's so much opportunity here
to enable really compelling experiences, where users can pay
for things without having to go into an app, straight from Siri,
straight from maps, straight from messages.
And then we talked about testing
in the Sandbox and the simulator.
There's one thing we didn't talk about that's very big this year,
that's Apple Pay on the Web.

So, you can use Apple Pay as well as in apps,
as well as in extensions, as well as in WebKit,
you can now use it on mobile websites and you can use it
on the desktop, on MacOS Sierra.
You can authorize payment
in Safari using your Apple Pay device,
both iPhone and Apple Watch.
Now, we talked about this in the previous session.
So if you're interested you can go
to the website, check it out now.
And if you want more information about anything we talked
about today you can check our sessions microsite.

Now I did promise some contact information,
and some other things.
I promised you bank and co-brand private label inquiries.

If you're interested in taking advantage of in-app provisioning
or any of the features I talked about for co-brands
and card issuers, you can email us here.

And if you're interested in value-added service passes,
you can visit our website,
the links up here, developer.apple.com/
contact/passkit.
And you can put in a request
to use the value-added service signing certificates.

We have some related sessions, like I said,
we just covered Apple Pay on the web.
There's also a WatchKit session tomorrow, upstairs in Presidio,
Designing Great Apple Watch Experiences.
I think you should definitely go to that
if you're interested in WatchKit.

See how you can really enable WatchKit apps especially
with the new changes on watchOS3.
So thank you so much for coming.

Thank you for making Apple Pay great
with your own applications.
And I can't wait to see some
of the amazing things you're going to build.
And hopefully I'll see you back here next year to talk
about even more cool things in Apple Pay.

Have a great WWDC.

Looking for something specific? Enter a topic above and jump straight to the good stuff.