Exploring Apple Pay with Swift

How to implement Apple Pay in your app.

My name is Wendy. I work on the iOS app at Pinterest, and today I'm gonna be talking about one of my favourite new frameworks in iOS, which is Apple Pay. So a little bit about me, I started iOS in 2010. I have been doing it for three years at Pinterest, and most recently I led the mobile launch of our Apple Pay product. This is a part of our buyable Pin's Feature, which features an in app discovery flow and a checkout flow. And of course, when we found out that Apple Pay was coming out, we jumped on the opportunity to use it.

Today, my goal is to really give all of you a working knowledge of how to use Apple Pay APIs and talk a little bit about when you would want to use it, why you would use it, and then we'll go through a code example of making our first charge.

When trying to find innovation, look for the intersection between the physical and the digital worlds.


When do you want to use Apple Pay? I found this quote the other day and it says, "When trying to find innovation, look for the intersection between the physical and the digital worlds.” Apple Pay is primarily used for physical goods and services, so these are things like products, reservations, tickets, ride sharing, and, of course, we still have our In-App Purchase API for digital goods such as premium content or subscriptions.

Even though you might not be selling physical products in the apps you're working on right at this moment, you never know in the future as our digital and physical worlds get more and more blended when you might want to take advantage of this.


What are the reasons you might want use Apple Pay and what are some of the benefits? Of course, credit card forms suck. Everyone agrees. No one should have to go through them just by looking through the number of keystrokes that we have. You can see why this leads to decreased revenue and decreased conversion rates. With Apple Pay we eliminate all lengthy forms, we eliminate registration, and it all boils down to one touch. It's also more secure than credit cards and finally, it's cool and people like using it. So this says “Apple Pay takes longer than using a credit card if you count the 45 minutes that you spend telling people about it afterwards”.

It's kind of a fun experience and your users will probably enjoy it

It's kind of a fun experience and your users will probably enjoy it. So let's get to the interesting part of making our first charge. This is what we'll build today. We have this nice payment sheet, pre-populated with information and then we'll handle the payment at the end. So, before we get started with the code, of course, there's some prereqs and this is mostly boring certificate stuff. The most important thing here is that this is way easier if you use an existing payment gateway or a payment processor, so someone like Stripe, or Braintree, or Chase. Apple has a bunch of them on their website. You also need to create a merchant ID and certificate in the developer portal, and this mostly creates the public and private keys that your payment data will be encrypted with. So that's the end of this boring certificate stuff.


Now we can get started with the code. So, before we decide whether or not to show this Apple Pay button, we want to know whether the device we're on is Apple Pay-enabled. And we can do this with this nice PassKit method; .canMakePayments. Sometimes your merchant only takes certain card brands or certain networks, and if that's the case you can use this method; canMakePaymentsUsingNetworks and pass in an array of brands like, here we have Visa and Discover.

To present the actual payment sheet, there are three main classes that we'll need to deal with. The first is the PKPaymentRequest, and the request object encapsulates all the metadata of what we wanna display on the payment sheet, as well as other data on the transaction. So we'll have support and networks, country, currency, merchant ID, and additional capabilities.

The real interesting part is here, the payment summary items.

The real interesting part is here, the payment summary items. Each payment summary item corresponds to a single line item on the Apple Pay sheet. So it has a label and an amount. You'll see here we have a subtotal item with a hundred dollars. We have tax, that's 8.74 and finally, we have this total item of the total. And the total item is a little special, the label needs to be the merchant name because this merchant name is what they're gonna pull out for the final line item on the sheet that says, "Pay" and then your merchant name. So here our merchant name is Grass-fed Jeans Inc and we set this in our summary items. The total item has to a be the very last item, and we can set this on our request.


So that's your PKPaymentRequest. The next class we'll deal with is our PKPaymentAuthorizationViewController. This view controller corresponds to the actual Apple Pay payment sheet. So, it's pretty straightforward, you can initialize it with the request that we just created and then set it's delegate to yourself and once you present it, this is what we have. This is a very simple payment sheet with the line ends that we specified.

For some apps, this might be enough, right? If you're doing a ride sharing app, you might not need that much more information. But for apps where you're selling actual physical goods, you do need to collect some sort of address to ship this to. We can do that by adding this requiredShippingAddressFields in our request object and specifying what fields we want. So for example, here we want our postal address and our phone number.

Once you pass control to the Apple Pay sheet by presenting it, you pretty much pass control over to Apple and there's very little customization you can do. But the way you know whether users are interacting with it is through a set of delegate methods. For example, when they select a new shipping address, you get this delegate method; paymentAuthorizationViewController: didSelectShippingContact and this will pass you a PKContact item. This is a lot like CNContact, so it makes it really easy. First of all; hooray for the new Contacts Framework! It makes it really easy now to parse out things in that CNContact item. It was really difficult before. We won't get into that.

First of all; hooray for the new Contacts Framework!


So it makes it easy to pull things out like the postal code which we're doing right up here. And then we can do things like update the tax, for example if they're in a different state, maybe you wanna charge a different tax amount. So things like that. So this is what our payment sheet looks like now. You'll see when I enter a Seattle, Washington address, I think their tax is 9.6 so that recalculates the tax, updates the tax and also updates the total. 

So finally, once the user authorizes the payment by putting their finger down on the touch ID, we get our final object of interest, the PKPaymentToken. And this is again returned to us in a delegate call back paymentAuthorizationViewController, didAuthorizePayment. There's a bunch of stuff going on behind the scenes before this is actually called. It deals with nonces and encrypting the data with multiple keys before we finally get this, but I won't go into too much detail about that right now.

All we need to know is that when we get our final PKPayment object, the token is one of the fields. It's this last one; PKPaymentToken among other metadata like our shipping contact and billing or shipping methods if we specified that. Once we get the token, we can then send the token to our merchant or our payment processor and they will be able to decrypt the token and then process the payment. 

So it's pretty seamless integrating Apple Pay on the client side and I just wanted to go over a couple of interesting things that I encountered when doing this implementation...


So it's pretty seamless integrating Apple Pay on the client side and I just wanted to go over a couple of interesting things that I encountered when doing this implementation. If you have a custom in-app checkout flow as well as wanna use Apple Pay, you have to include those buttons side by side and they have to be of the same size. So right here we have our Apple Pay button and our in-app checkout button and they're the same size which is specified in the human interface guidelines and it's also okay with Apple if you wanna make the Apple Pay button larger than yours.

To protect the user's privacy, you only get the full contact information after authorizing the payment. So after the user actually puts their finger down on touch ID. Before that, you get a subset of the contact information. You'll get city, state, zip code and country and hopefully, that should be enough for you to update your tax and pull for qualified shipping methods. Payment summary item amounts are stored as NSDecimalNumber’s and this is a base ten representation of the amount. It's slightly less convenient to initialize in a float or a double, but, of course, floats or doubles mean base two are not accurate enough for financial calculations. So for example .42 in a float is actually .41 with many 9s, so these can lead to errors that we don't really want.


Finally, of course with new APIs there are some debugger issues. I've noticed that when building from Xcode to my device and I'm attached to the debugger, sometimes Apple Pay doesn't recognize my device as being Apple Pay-enabled and I'm not sure why that is. So it's sort of unfortunate. If you run into this, just disconnect your device and test without the debugger. 

Finally, that's the end of my talk. I wish Apple Pay came preloaded with some of U2's money instead of their songs so look out for the next keynote, you never know what they might announce. I’d love to hear about any of your experiences integrating Apple Pay and take any questions that you might have.

Q&A (09:57) 

Q1: When I test my application that just goes to a database, I have a phoney database and I put in phoney records and stuff. That's what I need to use to test it out to make sure everything works. What do you do when money is involved? Do you put in funny money or funny bank or how does that work?

Wendy: Yeah, it's actually interesting. The testing environment is not too developed on Apple Pay yet. You can test it in the simulator and they have simulated card types. So they'll have a simulated card for each Visa card or American Express, so that's one way you can test it. For the payment processors that I mentioned, like Stripe, Braintree, whoever, those will also offer sandbox environments so you can test transactions in the sandbox environment before going live. That's sort of one way that you can make sure that everything is up to par with the app before actually going live with payments.

Q2: Can you talk about how Apple Pay deals with cancelled payments and refunds?

Wendy: I believe that every merchant or payment processor that Apple Pay works with is required to support certain types of transactions. So they're required to support refunds, recurring payments, payments where you have to split up an order into different segments. So all merchants should be able to handle that.

Audience: And you said also PCI compliance by default using Apple Pay?

Wendy: So PCI compliance, this is another reason why it's extremely advised to use an existing payment gateway that's integrated because all of these payment processors and gateways will be PCI compliant. The alternative is to build out your own payment infrastructure for payment, receiving payments, and processing payments on your servers.  It's usually pretty involved unless you already have that in place and are already PCI compliant.