I'm so disappointed that the 5s doesn't support Apple Pay for in-app purchases of physical goods (the payments product Stripe partners with Apple to provide).
I've yet to discover any reason why except marketing/branding – ostensibly consumers would be confused that they can use their 5s for purchases through apps but not in retail stores, due to the lack of NFC.
From a technical perspective, there doesn't seem to be anything holding the 5s back. The A7 has a secure element/"enclave" like the A8 (a cryptographically secure place on the SoC to store payment tokens, fingerprints, and the like), and the 5s has an A7 and the TouchID sensor.
EDIT: The secure element is in fact distinct from the secure enclave. agnokapathetic explains below.
The technical reason is that while the iPhone 5s has the Secure Enclave co-Processor (SEP), it does not have an Apple Pay Secure Element (SE).
The SEP is a ARM TrustZone-like separate processor running a stripped down L4 derived microkernel. This manages encryption keys, the secure boot-loader and OS update signing.
The Apple Pay Secure Element is a separate chip which runs a Java-Card-OS. "Cards" in the java-card-OS are cryptographically "personalized" by the payment network (VISA, AMEX, MasterCard) with per-device keys and the device personal account number (DPAN)--the tokenized device only credit card.
This is the same java-card + payment network personalization that physical chip-and-pin cards, Google Wallet and most other NFC payments use.
So my guess is that the Payment Networks were not comfortable using the Secure Enclave Processor and preferred to reuse the same technology used by chip-and-pin, with a separate Secure Element chip.
Thanks for clearing that up. Assuming the Secure Enclave has a level of security comparable to the Secure Element, it'd be nice if the payment networks would trust it, but they're so notoriously conservative...and understandably want everyone using the same base tech to keep complexity lower.
I think the bulk of my disappointment is that I upgraded to a 5s anticipating I wouldn't be totally shut out of Apple's (at the time rumored) impending launch of a payments product. Oh well, at least we get TouchID auth for apps.
They're notoriously good about this. If a phone's processor lacks a component necessary to make it function, it will be difficult to compensate for that through software. I'm sure Apple would've loved to get an extra 50m folks using a payment network that they get a cut of, but they couldn't, so buy an iPhone 6 if you want to use it.
'"Cards" in the java-card-OS are cryptographically "personalized" by the payment network (VISA, AMEX, MasterCard) with per-device keys and the device personal account number (DPAN)--the tokenized device only credit card.'
Is this 'tokenized device only credit card' the same concept as the Point-of-Sale seeing a unique CC # (generated) for the transaction? (What I believe is one of the selling points for Apple Pay). Are there other products that do this?
I was under the impression that Secure Element is separate from Secure Enclave. Secure Element is for CC information and Secure Enclave for fingerprint data. Since the 5s lacks Secure Element, it makes sense why even Apple Pay in apps wouldn't work. I have not been able to find anything to suggest one way or the other, so I could be wrong. Please correct me if I said something wrong.
"Apple Pay doesn’t replace In-App Purchases. You should use Apple Pay when charging for physical goods (such as groceries, clothing, and appliances) or for services (such as club memberships, hotel reservations, and tickets for events). You should continue to use In-App Purchases to charge for virtual goods such as premium content in your app."
Anyone understand why this is? Is there a reason I shouldn't let my users use Apple Pay to buy the freemium digital content on my website?
I don't quite understand what capitalized In-App Purchases means...oh, maybe Apple Pay is only possible from an app, not from a mobile web browser? Is that true? (But like, why?)
Everyone here talks about Apple's "30% cut" (which of course is nowhere near what Apple actually gets, as people don't take into account costs for the high transaction costs on these small purchases), but as someone who runs an App Store (and who has had to on numerous occasions here on Hacker News dispel the weirdly-pervasive myth that Apple makes meaningful money from their App Store, something trivially disprovable using Apple's earning statements), I will assert the difference is more to do with license transfer and fraud mitigation, two things users and developers alike often fail to realize are either hard or even necessary until after it is too late.
In-App purchases are tied to your Apple ID and can be recovered and reactivated by a receipt API on other devices you are logged in to: Apple wants you to use their API for this purpose to guarantee that buying new devices will not lead to the user having lost a ton of money in their software investments. Some developers in the Cydia ecosystem sell things themselves, and they have either draconian or broken device license transfer restrictions. Users still complain to me, even though I had nothing to do with their payment. For Apple, the issue is even worse, as it could keep a user from buying a new device (where Apple actually makes money: anything that stands in the way of this Apple will not tolerate).
Physical goods are also very easy to build fraud contros for, due to the requirement of a physical shipping address; the same is not true of digital goods: Apple has spent a long time building out fraud management for their digital goods sales, and I doubt they want the Apple Pay platform to suddenly be inundated with tons of "app developers" (a class of developer Apple clearly doesn't trust very much) to make people start to think Apple's app ecosystem is a massive source of credit fraud. Apple also likes separating user data from developers: you don't know your customers, only Apple does; for a physical good, that is obviously an impossible separation to maintain, but for digital goods I think they would rather continue to have all purchases gated through them so that all developers see are anonymized identifiers.
Hey, I didn’t want to suggest it’s about squeezing money. You are certainly correct, Apple is much more directly involved with in-app purchases, so they also take much more ownership and responsibility for it. (Though I would also argue that this has a lot to do with the status quo. In-app purchases were quite new and there were no expectations about how to deal with them and who gets what. Credit card transactions are old and established and to get in on them you have to be competitive when it comes to fees and at least as convenient.)
For in-app purchases Apple collects their 30%, for Apple Pay substantially less. That’s what this comes down to.
In think it more or less comes down to this: If you buy something you (potentially) use inside the app (an ebook, access to some server-side service you can use with the app, …) it’s an in-app purchase. If what you buy is something you use outside the app (a taxi, a pizza, all physical goods, …) you can use Apple Pay.
This differentiation has always existed. Until now Apple just didn’t offer any help with payment with the second category and you had to do it all on your own.
Apple worked it out with Visa/Mastercard they they get a cut of the interchange fees, so the retailer pays no extra fees from what they would normally pay.
The retailer would only pay the Stripe fee. If I understand correctly, Apple collects some fees from the bank (that they take from the interchange fee)
I think Apple needs to check on this very careful just because of some services like Uber offer services through the app and don't sell a physical good.
The opposite of this is, that you can't use Apples tier-pricing for services like that just because of it's usage-dependant and is reflected through actions in the real world.
I wonder how much effort Apple is going to put into checking on this actually. Especially because of services like Uber sell the ride. But what if the direct contract partner would be the driver and any service provider like that would just process transactions for comfort - so acting like a payment gateway for drivers.
A valid point, but I guess Apple will change the terms of service or will define services like Uber as physical good, since the service affects the real world and can not be realised through in-app purchases.
I think that is what it is all about. They do not want Devs to opt out of in-app purchases and adopt ApplePay instead.
I'm pretty sure a cab ride is a real-world, physical thing. Besides, Apple's Guidelines are really just that, and they can enforce at their discretion.
Two big differences. In-App purchases allow for smaller transactions where Apple Pay with Stripe would actually cost 33% for $1 or 18% for $2.
In-App purchases are setup beyond just handling the payment. You can restore purchases across devices and the distribution is built in. You could replicate this experience but it is nice to avoid having to sign up specifically to use a Camera app that has an in-app purchase photo filter.
Actually, IAPs needs to be hosted and served by developers (contrary to standard app distribution). If the app sells virtual credits, it's not a problem; but if it sells data (e.g.: offline maps) then it might be one. Apple is not providing help there, they're only handling the financial transaction, and storing receipts of past purchases (so that apps can offer a button to reactivate past purchases).
I'm very impressed with how quickly Stripe has been able to get Apply Pay integration as part of their platform. I'll be looking into it for my own apps.
They were a launch partner when Apple announced Apple Pay. They most likely had advanced knowledge and have been working on integration for a long time.
Sure, that would be one way to hack around it. I'm wondering, specifically, if Stripe Checkout[1] will ever gain Apple Pay support. Presumably it's up to Apple to expose the relevant API to javascript.
my only issue with this has to do with the occasional lapse in recognition of the touch ID. if it can't read your fingerprint several times, it asks for your password code. touch ID is of course not theft-proof, but initially it's a slightly greater obstacle than a simple numeric code.
It would be beyond easy to make a generic app that registers a custom protocol handler on the phone that could handle this. Don't know if Apple would approve it but sending the user to, for example, myapplepayapp://transactions?Id=123 where the id could be used to grab all the order data from the shopping cart, identify the merchant, and grab their Stripe API credentials would be simple and useful.
They just enrolled me in the demo two or three days ago. It's pretty slick (well, very slick), it's just that their libraries don't yet support it (I think the API is going to change). It was very easy to add to Checkout, though.
Yea they just totally revamped the beta, its pretty awesome. Bitcoin went from being a completely separate API to integrated with the standard charge APIs. It also got integrated into Stripe checkout.
It's a lot of code to write, but extremely understandable when you come back to read it a year later and wonder "what the heck do the parameters to this function do?"
I've only just started learning iOS development (Swift, not Objective-C) and although initially the code looks quite complicated, Xcode more than makes up for it. Its auto-complete functionality makes it very fast to write these rather lengthy lines of code. Plus it's a really descriptive way of writing code.
Also, like with many languages, once you understand the basic syntax it doesn't look as complicated anymore. (First time you came across Ruby it might have looked quite complicated as well).
In fairness, the code in that screenshot is horrifically formatted, wrapped, and indented. Properly written and formatted, that code would suck much less.
I don't quite get why you would develop in XCode & Android unless you were trying to squeeze out the last x% in performance or were doing something super custom like Instagram.
I've yet to discover any reason why except marketing/branding – ostensibly consumers would be confused that they can use their 5s for purchases through apps but not in retail stores, due to the lack of NFC.
From a technical perspective, there doesn't seem to be anything holding the 5s back. The A7 has a secure element/"enclave" like the A8 (a cryptographically secure place on the SoC to store payment tokens, fingerprints, and the like), and the 5s has an A7 and the TouchID sensor.
EDIT: The secure element is in fact distinct from the secure enclave. agnokapathetic explains below.