 So, my talk is going to be about Apple Pay. My name is Kien, by the way. I'm working for a company in Singapore right now. It's a chat app for work at Pi. This is purely my hobby. I just had a chance to get the hands-on Apple Pay because I helped a friend build an app. He's in the US. So, I got the US card card and then I have to switch to the US app store and I find it's really, really fast to use Apple Pay. Like, I don't want to enter any more credit card information ever in any kind of app. So, it's a shopping app. I'll show you in a minute. And for—I also prepared some—I mirror my iPhone to here because on my iPhone I have a few apps that already accept an Apple Pay. And I think it's good for someone that haven't had a chance to take a look. So, a quick look about Apple Pay is introduced last year, 2014, together with iPhone 6. And for Singapore it's coming soon if everything goes well. I think it's going to be the same time with the Apple store in Orchard, I think. I think they will enable Apple Pay in-store but what we are talking about today is the Apple Pay in-apps, not the real device because I'll never try with the real device anyway. Also another thing is the shopping category recently introduced in the app store, which means they really want to expand its huge opportunity ahead for either app developers. You can have more projects with Apple Pay or you are shop owners that have—you have stuff to sell and you want to sell fast. So it's Apple Pay within apps, it's not everything Apple Pay today. And why shop if I would Apple Pay because so when I try, I realize there are a lot of things to do with you going to build a shopping backend because you have to worry about payment, products, everything. And I think it's nowadays it's not—unless you're going to do a lot of sophisticated things for your backend. Although a shopper should be good enough, it's since 2004 already from Canada. It's a shopping backend as a service, that's from what my point of view. I think it's a backend as a service. And around three months ago, they released an SDK for iOS app, which means it's very easy for iOS developer to integrate their Shopify backend if they only have the store for their web app and they want to enable the payment on the iPhone. This SDK is going to simplify a lot of things. A few other things that is much easier now to start developing on Apple Pay. You cannot debug on an Xcode. Previously, you need a real device, you need a real credit card. Your phone has to be the iPhone 6 or above to use to debug on Apple Pay. And from iOS 8.3 and above, they introduce a class called PK Payment Button. It's a black button or the white button with the black border depends on the style so that you don't have to start a button yourself. Before that from 8.0, basically when they introduced the iPhone 6, you have to start a button yourself, which is tedious, ridiculous. So if supporting Apple Pay, I think 8.3 and above. So let's dive into it first. Before jumping to the code, let's have a look. This is one screenshot from an app that supports Apple Pay. I think this one is fancy. So soon, I think even in Singapore App Store, you see apps starting to show two buttons instead of one. One is the traditional buy button. The second one is going to be buy with Apple Pay. Basically the app can recognize whether your phone has the capability to support. They will show the second button, otherwise you go with the traditional shopping flow. This is from Apple Slide, but it's very short. But there are three things. It's easy. So no registration. You don't need the user account to buy stuff now. It's secure because your credit card number will never be sent to the merchant. It's private, of course. So a few other screenshots. This one is from Best Buy. Best Buy has now. And you see that I've never locked in before. I have one. I tell me the card. And I can start checkout already. This one is Shop Ticks. They're all featured on the US App Store right now. This one is Livex I-L-I-F-X is to buy a light bulb. So you can see a lot of product categories in the App Store right now. And this is one screenshot from an app that I did recently. It's not released yet. So if there's one thing to get away from this talk is basically as a developer, what you need for your product, for your payment screen is first you check if the phone is eligible to use Apple Pay. If it's eligible, you present the payment sheet from Apple. The user will pay. You get a token. You pass the token back to your back end. And that's it. And this, we will dive into it more what the back end will be. So there will be action. So this one I'm trying. So I'm going to attempt to put my touch ID. It's secure. So if I put a wrong touch ID, it won't proceed. And after a few times, the flow is going to show the passcode, your usual passcode. You can pay with that. But then I decided, okay, I used the right finger. And done. After this, Apple is going to send you a token. And then we send back the token to the back end. In this case, it's Shopify. So you see, it's really fast. And before jumping to the code, this is a slide from Apple. But it's basically summarized everything that you need to prepare if you're going to use Apple Pay. If you're familiar with in-app purchase, you know a Storkit framework with the prefix SK. With Apple Pay, it's got to be passcode. So every prefix got to be PK. You see in the class name later on. And within app purchase, all the payment is actually done by Apple already. So you don't have to do anything else. Apple will just tell you they made the purchase. Then you can proceed to give them the content you want. But that's the difference. In-app purchase is for something like in-app content, services, subscription, something basically you can't touch. Physical goods and services is what Apple Pay is for, which is so far you have to use maybe PayPal SDK, for example, to pay, which you have to redirect. You have to have deep link, jump back to the app. Now with Apple Pay, it's much easier. So we need to build our own. And I'm not going to dive too much, but I will introduce four main classes you need to remember. First is because you need a cart before checkout. The class name is called payment summary items. This very basic is like your product name, the amount, and a type. Then you're going to pass all of these, it's like you have a cart. You're going to pass all of this into the cart. And the last item is going to be the final item that you use to charge the user. And there's one property that you just need to pay attention. Payment summary items, you just need to add all of your items into the cart. If you have only one product, you add one product. If it's an Uber app, it's only one charge, it's only one ride, so it's one item. And this is the payment sheet you saw just now. The name is long, but when you present this, Apple will take care of everything, including the user contacts, user cards, billing addresses, everything. And we just need to get the callbacks of this controller and decide what to do next. And PK payment is the class that you get from Apple. So one thing to note here, even though the payment is completed, but if you decide not to proceed with the PK payment, the user's cart will not be charged. And this is what you have to handle in your app flow, right? So I'm going to run very quickly through this line of code. This is basically to demonstrate how you should construct your PK summary items and then add into the PK payment request. So first I have a subtotal amount. I have a discount. This is what is great about what Apple is already preparing for you. They use NS decimal number. It's handled on the units and decimal number overflow, everything is already handled. And then finally, you have your total amount deducted from the subtotal and after discount. And you're going to set the total into your result. And this is the PK payment request. Summary items, subtotal, discount, and total. So no matter what you put before, the actual one is the last one. So if you stop right here, you're going to start to think about how should my back end work with this when the front end already have the PK payment. The back end needs to support and do all kind of stuff with the Apple server, right? So I think that part is handled by a lot of merchants right now, including Stripe, Brentree, Shopify, Brentree is from PayPal. But we have a look at Shopify today because Shopify actually handles a lot of other stuff like they have products, catalog for you, collections, everything stock management, shipment as well. And this kind of stuff is very complicated if you're going to do your own back end. And especially payment, they have a lot of payment. So you have your PayPal account, you can put into your Shopify. Money is going to go to your PayPal account. And refund, they also have refund mechanism, so you don't have to care about that. And they have Shopify apps which allows you to build your own custom flow for a certain hook in the Shopify back end. Okay, so this is what it looks like if you already have something support Apple Pay. You are using the mobile by SDK integration to give you an API key and a channel ID which you use to initiate, initialize in your code with those keys. And merchant ID is what you're going to create in the developer portal of Apple. So this is unique. And when you create that, actually, I'm going to run through this quickly. This is done by Shopify. They give you this CSR file, create the merchant ID. We're going to upload this CSR file to Apple, just like what you generate your distribution certificate, exactly the same. And then after everything is done, you're going to upload back to Shopify. And then in your Xcode, you activate the Apple Pay capability, which will look like this. So if everything is done, it's going to have a check mark with all the ticks here. If everything is configured correctly. So with Shopify, they basically simplify a lot of classes from Apple and they have their own callbacks for you so that it's very fast to implement. So you have a shop, you implement your shop, you have your own product. The variant is like a product has multiple colors, size, and then when you start your payment flow, you just need to initiate your card, add your variants, whatever the user has chosen. And create a buy checkout object. And this is the main object that you interact with. You don't have to care whether how to use the context framework from Apple to extract all the addresses, they have everything for you. You put the card in, and then in your controller that do the payment, you just need to inherit this class. And actually, they also have something called buy product view controller, which will render everything from the back end. Then you don't have to do anything. But if you have your custom UI, you inherit from this guy. And it has a method called, this should be start Apple Pay checkout. And then they give you a bunch of delegates, like fail, why it fails. Fail to get shipping rate as well, like if your product doesn't ship to the US, it will go here, and then you can display a proper error prompt to the user. Fail to complete the checkout could be due to internet connection or also missing information. And this is where it succeeds, and you can show the thank you screen just now. Yeah, and then when the user dismiss the payment sheet, you have all the information from the user through the checkout object. So there's one interesting here, which is I think it's better if I can demonstrate it. So you see the screen, right? These are all the apps I have right now to support Apple Pay. And let's dive into fancy, for example. So you choose this product, I'm not logged in at all. And if I choose buy with Apple Pay, this will prompt. And you can see here, basically here I can change my shipping address. Like your app doesn't have to care about all these things. You don't have to cache in your app or anything, it's already there. And you can change your phone number, contact email. If you want to ship it to your friend, it's always here. Basically, the payment is touch happy. Maybe another one, my card already have one. So see, always two buttons. All of the apps in 2016 in Singapore, from what I predict, is gonna support two buttons. Any questions so far? Yeah, if you go to the app store from the US in the feature page, they have a section called buy with Apple Pay. When you go inside, there are a lot already. UK, US and Canada yesterday, just support Apple Pay. So basically everything, I think they're gonna change the whole experience when you pay on the iPhone. I think that's it after this is, yeah, a few references. Basically, this is everything. If you want to know about Apple Pay, this video has everything, including the sample project from Apple in 2015, earlier this year. Mobile by SDK, very new. It's only version two, version one was beta. So they released this around two months ago, right the time when I started to do the app. And this is what you need to read if you want to enable Apple Pay with Shopify. And it's my tutor handle, in case you want to contact. Yeah, that's it guys. Can you actually still use the share sheet for iPhone 6 below? Oh, there is a method from PK Payment Request, I think. It's a static method, say is Apple Pay eligible? So if it doesn't support, you have to show the traditional UI. So I'm not sure if Apple's gonna reject it, if your app doesn't support device, don't have Apple Pay. But I don't think they will, because they want people to buy new phones, right? So iPhone 5 open, please use something else, maybe, yeah. So payment sheet is completely not accessible? Yeah, I actually never tried. It's quite strange if you could authenticate with your phone's PIN number, and you cannot use a FIAMS to buy it. I think it has something to do with the chip, the encryption chip. Oh, okay. It's when they encrypt the card information. So you got the question? Oh, okay. Okay, thank you. Thanks guys.