Correct me if I'm way off, but when Apple launched it, iPhones had a separate secure element with applets that use keys stored in slots, very similar to chip/pin cards. The protocols for payments (EMV standards) all used symmetric keys, and so any issuer who wants to be a part of Apple Pay needs Apple to get a key into their SE.

It's possible to do this through a process called "personalization," where in general, a secure element has "initialization" keys that are installed at manufacture, but then the keys get updated (personalized) once the user gets it.

I'd speculate that Stripe could get integrated using a personalization protocol, with new keys over the existing protocols, and not require its own intitialization keys in the SE. A further speculation would be that Apple's pay partnership with GS may have facilitated a different protocol that uses more manageable asymmetric keys for doing reconciliations, and all the complexity is in integrating with generic payment terminals, whereas for anything that doesn't depend on that, you can use more sensible protocols that aren't freighted with backward compatability to chip/pin cards.

Square would probably be the easier integration, but Stripe may have some secret sauce for this. Anyway, wildly speculative, and would be interested what's way off in that.

It's designed to work through a mobile app via the iOS SDK: https://stripe.com/docs/terminal/payments/setup-sdk?terminal....

Thanks -- appreciate the reply.

As a future product option I'd love to be able to treat these as standalone terminals, so we can offer a web based POS app (running on a different device) and the phone as a payment terminal without having to deploy our own mobile app.