
Stripe – Apple Pay - Killswitch
https://stripe.com/blog/apple-pay
======
adamfeldman
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.

~~~
agnokapathetic
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...](https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_2014.pdf)

~~~
adamfeldman
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.

~~~
sliverstorm
_I upgraded to a 5s anticipating I wouldn 't be totally shut out of Apple's
impending launch of..._

I thought Apple was pretty _notoriously_ bad about this sort of thing?

~~~
jedrek
The iPhone 5 is fully supported under iOS 8.1, as far as what is technically
possible (no touchID, for example).

Find out which flagship Android phones have an official 5.0 ROM and let us
know.

~~~
andrewpi
There is no support for T-Mobile's Wi-Fi Calling on the iPhone 5, even though
its almost identical to the iPhone 5C.

------
gameguy43
"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?)

~~~
saurik
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.

~~~
arrrg
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.)

------
jonhmchan
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.

~~~
lyinsteve
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.

------
zrail
I know this is a long shot, but will it ever be possible to use Apple Pay with
Checkout from a webpage?

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

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

~~~
zrail
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.

[1]: [https://stripe.com/checkout](https://stripe.com/checkout)

~~~
gameguy43
Yeah, this is what I meant by my confusing question above.

~~~
druidsbane
One day they'll probably let you enter your user id and password to get it
started then scan your fingerprint on a device to confirm. Why not?

~~~
skinnybatch
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.

------
callmeed
So, what is the fallback for users on non-apple-pay devices? Just normal
"enter/save your billing information"?

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

------
xsb
What happened to Stripe Bitcoin payments?
[https://stripe.com/bitcoin](https://stripe.com/bitcoin)

~~~
StavrosK
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.

