Stripe – Apple Pay

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.

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.

Source: https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_20...

The apple watch will allow for contactless payments via apple pay for people with the iphone 5/5s

Apple's guidelines. In-App purchases can't be used for physical goods, but must be used for anything that does stuff through the app.

Apple wants to take their cut on In-App purchases, with a lesser cut for Apple Pay purchases.

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.

How long can Apple maintain this somewhat fictional dichotomy? 30% App Store / 2% Apple Pay. It's a HUGE delta.

> I don't quite understand what capitalized In-App Purchases means

https://developer.apple.com/in-app-purchase/

(sometimes abbreviated IAP)

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.

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.

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.

Generate a visual code on checkout screen >> Scan with app + camera >> Apple pay.

Or use "continuity" on Yosemite if it is Mac > iOS

If you use Stripe-iOS it should auto fall back to a card number entry box.

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.