You may have missed it — with the rapid-fire announcements and intermittent Chinese translation, there was a lot to keep track of during last week’s Apple keynote — but sandwiched between the unveiling of the new iPhones-for-Giants and the much-rumored watch, Apple quietly revolutionized mobile e-commerce.
I’m talking about Apple Pay. The headline was NFC, which lets you pay for retail goods by waving your phone (or watch) at a point of sale terminal (and which Prolific’s own Russ Wallace had an excellent writeup on last week). But buried in a footnote was an API for third parties to securely accept payments in-app. Here at Prolific, we make a lot of apps that accept payments, and we’re very excited about Apple Pay for two major reasons:
The first is experience. We all know checking out on mobile can suck. Sure, we can make the forms elegant, and snapping a photo of your card goes a long way when it actually works. But ultimately, you’re left entering a ton of information on a tiny iPhone keyboard and wondering if you really need to buy that dog hammock after all. Now imagine if your app didn’t even need to pop up the keyboard once during the checkout process. Apple promises to make that dream a reality. Buying a product from an app can finally be as simple as buying it in a store.
The second reason is trust. Every month or so there’s a new high-profile exploit targeting a major brand. And who hasn’t heard of a friend or relative getting their identity stolen? Each time I hear one of these stories, I think a little harder before giving up my credit card details — and that’s to say nothing of the irrational fears lodged deep in the hearts of the less tech-savvy among us. (“But if I give them my credit card, the criminals will mine me for Bitcoin! I heard it on CNN.”) Apple Pay really is more secure: credit card numbers aren’t even stored on the phone, and merchants only receive a one-time payment token. And with Apple’s marketing clout, users will surely be in the loop, and the engendered trust will transfer to your app. (For more info on Apple Pay’s security features, I recommend checking out Russ Wallace’s aforelinked summary.)
How does it work?
From the user’s perspective, it couldn’t be any simpler — you tap a “Pay with Pay” button, and a standardized sheet pops up. Choose your billing address and credit card from a list of pre-filled options, and maybe shipping address too if it’s different from billing. Pick your shipping method right from the sheet. Then hold the Touch ID sensor to verify your identity, and… that’s it! The checkout process is complete. Wasn’t that painless?
Now that we know what the experience looks like, let’s dig into some code!
…But first, some caveats
In order to process an Apple Pay-ment, you’ll need to be using a compatible payment processor. Apple provides the following list:
- Chase Paymentech
- First Data
Apparently you can also handle the encryption and decryption of the payment token on your own — but there’s zero documentation and it’s definitely not the sanctioned way to do it. Quoth Apple (PDF link): “Handling credit and debit card payments can be complicated and unless you already have the expertise and systems in place, an SDK from a payment provider is the quickest and most reliable way to support Apple Pay in your app.” So if you want to support Apple Pay, sign up for one of those processors.
There’s also a limit to how much of the flow we can test so far. To complete the checkout process, you’ll need an Apple Pay Merchant ID, certificate, and entitlement from the Developer Center. Conveniently, none of those are available as of this post. And since you can’t test Touch ID or Secure Element on the simulator, you’ll need to test on-device on an iPhone 6.
But even if we can’t complete a payment, we can still test a lot of the flow. I’ll keep this pretty high-level, but I’ve put some well-commented sample code on Github for a bit more info.
We’ll start with an instance of PKPaymentRequest. This class (and all is part of PassKit, the framework that handles Passbook, which makes sense since that’s where users enter their credit card info to begin with. The PKPaymentRequest instance will hold all of the cart items, shipping methods, and options for our checkout process — think of it as Apple Pay’s cart.
PKPaymentRequest *request = [PKPaymentRequest new];
Let’s add some items to buy:
PKPaymentSummaryItem *item1 = [PKPaymentSummaryItem summaryItemWithLabel:@“Dog Hammock” amount:[[NSNumber numberWithFloat:25.99f] decimalValue]]];
PKPaymentSummaryItem *item1 = [PKPaymentSummaryItem summaryItemWithLabel:@“Total” amount:[[NSNumber numberWithFloat:25.99f] decimalValue]]];
request paymentSummaryItems = @[item1, total];
We’ll want to set some more properties on our request — including shipping methods, our merchant ID, and various configuration options. You can find those all in the demo code on Github or in Apple’s documentation. Meanwhile, let’s skip to the good part: presenting the payment interface to the user:
PKPaymentAuthorizationViewController *authVC = [[PKPaymentAuthorizationViewController alloc] initWithPaymentRequest:request];
authVC.delegate = self;
[self presentViewController:authVC animated:YES completion:nil];
Now the user should be presented with a screen that looks something like this:
If we want to get the results of the transaction, or updates on its progress, we’ll have to implement some delegate methods. Besides reacting to a successful, failed, or cancelled payment, we can get a notification when the user updates their shipping address, and update the shipping methods accordingly (or cancel the transaction, if they’re outside our shippable zone). Similarly, we can learn when the user chooses a shipping method and update the total to account for the added cost. (For a complete list of these methods, look at the docs for PKPaymentAuthorizationViewControllerDelegate).
Here at Prolific, we can’t wait to integrate Apple Pay into our apps — it promises to provide a first-party solution to many of our checkout woes. I’m sure we’ll have more posts to come as we learn more about how it works in the wild and its adoption among users of our apps. In the meantime, feel free to play with the sample app and, if you discover anything cool, submit a pull request. We’d love to explore these new APIs together!
Apple has an Apple Pay page for developers, though it’s remarkably light on technical details. It’s a good place to start, and presumably they’ll update it with more info as the platform approaches production. They also provide documentation for all of the classes related to Apple Pay. Start with the docs for PKPaymentRequest.
Stripe announced support for Apple Pay in their SDK on day 1, including processing tokens and convenience methods for generating the PKPaymentRequest and PKPaymentAuthorizationViewController. Look through their docs for more info. It’s also worth referencing their SDK on Github, as well as their sample app.