Not sure that there would be much point in incorporating Pay into in-app purchases. iTunes already has your bank details on file, just charge it directly. Pay doesn't offer any end-user advantages over click to pay where the vendor already has your billing information.
Except, going forward,the vendor will not have your credit card info on their servers, where it can be hacked -- that's a very big advantage.
Doubtful that will be the case for Apple itself any time soon. Would any of the subscription services Apple offers be workable with Pay?
That's non-sequitur -- I suspect that 99% of most people's CC transactions aren't to Apple as the vendor.
Even so, I would expect Apple to accept ApplePay for any purchases -- online or stick and stucco.
Doubtful that will be the case for Apple itself any time soon. Would any of the subscription services Apple offers be workable with Pay?
That's non-sequitur -- I suspect that 99% of most people's CC transactions aren't to Apple as the vendor.
Even so, I would expect Apple to accept ApplePay for any purchases -- online or stick and stucco.
It's very sequitur since all in-app purchases currently go via Apple. If Apple were to implement Pay for in-app purchases to pay the vendor directly then that would be a major reworking, whereby the vendor would need to include their payment detail in the app, Apple would forego the 30% processing fee, and, as mentioned, the subscriptions options would have to be totally rethought, since this is currently managed by Apple through the iTunes payment system.
Doubtful that will be the case for Apple itself any time soon. Would any of the subscription services Apple offers be workable with Pay?
That's non-sequitur -- I suspect that 99% of most people's CC transactions aren't to Apple as the vendor.
Even so, I would expect Apple to accept ApplePay for any purchases -- online or stick and stucco.
It's very sequitur since all in-app purchases currently go via Apple. If Apple were to implement Pay for in-app purchases to pay the vendor directly then that would be a major reworking, whereby the vendor would need to include their payment detail in the app, Apple would forego the 30% processing fee, and, as mentioned, the subscriptions options would have to be totally rethought, since this is currently managed by Apple through the iTunes payment system.
Very doubtful that would happen.
Apple offers a few subscription services: Developer and iCloud come to mind. Apple also offers content sales through iTunes -- these are one-off sales or rentals.
Some apps, like Netflix, available through the App store offer subscription services and apple takes a cut of the subscription fee.
Yes, it would take some reworking, but I see no reason that ApplePay couldn't be used for all of the above.
IDK why you assume that Apple would have to forego the 30% processing fee -- but maybe that's your agenda.
For me, I use Discover for most Apple purchases: iTunes, iCloud, Developer. Therefore, Apple has my Discover CC information on file. I also have my Discover card, among others, on my iPhone and Apple Watches for ApplePay. For ApplePay, Apple sees the CC info when you setup your CCs for ApplePay in order to register them with the bank. After registration, Apple specifies that they do not retain the CC information.
If Apple were to accept ApplePay for its online services, it would be processed as any other ApplePay transaction -- and the CC information would be held at the issuing bank instead of Apple's servers.
Why can't a USB connected fingerprint reader be secure? Wired ethernet isn't necessarily secure, but it can be made secure in software. The same can be done over USB. Any data transmission can be encrypted. The program could accept only connections from readers with validly signed certificates. This would prevent copycat devices from working. The biggest problem with biometric readers is their design accepting poorly validated biometric data -- a camera accepting a cardboard cutout of the "owner," a fingerprint reader only checking fingerprint ridges/valleys and being fooled by a sticky tape impression or picture (http://www.theregister.co.uk/2014/12/29/german_minister_fingered_as_hackers_steal_her_thumbprint_from_a_photo/), etc.
Why do you need any of that on the Mac? The iPhone already has touchID, the secure element/enclave and the means to initiate and process ApplePay transactions. An AppleWatch, when paired with an iPhone assumes the ability to initiate ApplePay transactions -- while the processing of the transactions is left to the iPhone.
I assume that:
a Mac (and possibly other PCs) can be paired with the iPhone -- and the iPhone does the processing of ApplePay transactions initiated by the Mac.
when you're using your computer that you would have your iPhone with you within BT/WiFi range.
The transactions would be securely processed (by the iPhone) and the only information displayed on (sent to) the Mac is pictures of your credit cards showing the last 4 digits only.
The reason that others can't compete is that Apple:
has an install base of hundreds of millions of iPhones that qualify for ApplePay (and have a capable iOS version)
has secure, efficient, fast payment process that runs on this large install base
I wouldn't be surprised to see a later rollout where you can use your ApplePay on someone else's computer by ad hoc pairing.
The AW does the Apple Pay processing all on its own (setup of Apple Pay and adding cards is via phone) - no iPhone required.
The difference to what you propose is that the AW is secured with a password, and if watch comes off the device is locked and Apple Pay won't work. Just having a BT connection between a nearby iPhone and Mac doesn't seem as secure. Not saying this won't be how it is implemented, but noting the watch case is different.
Comments
That's non-sequitur -- I suspect that 99% of most people's CC transactions aren't to Apple as the vendor.
Even so, I would expect Apple to accept ApplePay for any purchases -- online or stick and stucco.
Very doubtful that would happen.
Apple offers a few subscription services: Developer and iCloud come to mind. Apple also offers content sales through iTunes -- these are one-off sales or rentals.
Some apps, like Netflix, available through the App store offer subscription services and apple takes a cut of the subscription fee.
Yes, it would take some reworking, but I see no reason that ApplePay couldn't be used for all of the above.
IDK why you assume that Apple would have to forego the 30% processing fee -- but maybe that's your agenda.
For me, I use Discover for most Apple purchases: iTunes, iCloud, Developer. Therefore, Apple has my Discover CC information on file. I also have my Discover card, among others, on my iPhone and Apple Watches for ApplePay. For ApplePay, Apple sees the CC info when you setup your CCs for ApplePay in order to register them with the bank. After registration, Apple specifies that they do not retain the CC information.
If Apple were to accept ApplePay for its online services, it would be processed as any other ApplePay transaction -- and the CC information would be held at the issuing bank instead of Apple's servers.
The difference to what you propose is that the AW is secured with a password, and if watch comes off the device is locked and Apple Pay won't work. Just having a BT connection between a nearby iPhone and Mac doesn't seem as secure. Not saying this won't be how it is implemented, but noting the watch case is different.