NexusPhan suggested Bluetooth as a solution (I hadn't thought of that) and it seems that it could be a nice solution. The iPhone would do all the security work (dealing with the token etc) and the browser would just pass through the secured blob. This would neatly sidestep the security problems with a browser interface. It would also open up the solution to suitably-equipped Windows machines (I would expect that more than a few iPhone 6 users use Windows).
I think that's fine, if it's going directly to an NFC system, but I don't like the idea of this representational card number plus pin being and recorded by an untold number of sites because that hurts the overall security. I'd like to see unique representational card numbers for each person for each website (or groups of websites owned a single entity) for securing payments so that the breach of one financial server will not affect any other card number on file. This also means that scams like we saw last year where hackers were able to see the last-four CC digits is shown on an Amazon account and then use to verify their ID with an Apple CSR will not be able to exist.
I fully believe that Apple will go from 0 to the lead in mobile payments, and push the industry forward as a whole. It has been thus with Apple over last (almost) 2 decades - not always first, but with best overall implementation and most impact on industry. Its impact on the user in convenience varies by country - within Canada and many European countries where NFC is already widely deployed, the convenience improvement isn't as great (though still some - generally easier to pull out phone than a card from wallet), but the security and privacy improvements will be significant. The thing with Apple Pay, is that it basically benefits all players in the system (user, merchant, payment network, card issuer).
Although not discussed as much, I think Apple Pay will have a similar effect on online/e-commerce as well. I haven't seen any analyst mention that with TouchID, that biometric reading with Apple Pay will greatly reduce fraud for on-line, which should translate to a lower rate for merchants that use it. I have read that the rates could be same/close to the card present rate, and that itself will drive the merchants to adopt it quickly - they pay less on every transaction. Being able to use the common method across on-line merchants, paying with TouchID, massively increased security for the user (hello Target and Home Depot disasters), simple setup - the benefits for merchant, issuer, and user are huge. While the Apple keynote only mentioned "Apps", it should be possible to support Apple Pay for general web payment as well - would require work on the Apple (method for exchanging information over HTTPS) and merchant side. Perhaps this will be a "phase 2", but the benefits to seem clear.
Right now Apple has a good lead here. While Google Wallet is of course available for Android devices, getting the combination of reliable biometric authentication, secure information storage, payment ecosystem buy-in, & ability to bypass the mobile operators (who have a competing solution), is a challenge. Samsung have a fingerprint reader (how reliable?), but they can't just tie that into Google Wallet in the secure manner that Apple has. Not sure Samsung's carrier partners will support it.
This is why I expect the new iPads to support Apple Pay - not for the NFC part (might be useful in business as a terminal?), but as iPads are much more used for online/e-commerce. This might not drive a huge upgrade demand in iPads initially (e.g. this quarter), as this usecase/feature is not as easily understood as physical features like "Retina Screen" or thinner/lighter in the past, but it will build over time.
When the details emerged, I was surprised at the low percentage that Apple gets. Small enough to ask myself "why?". It's 0.15% whereas the banks/issuers get 2.5 - 3.0% So Apple is certainly not doing it for the money. And the revenue comes as part of the existing "fee" and is not an additional fee on top of the 2.5 - 3.0% It seems that the banks/FIs are willing to give up this small amount in return for a reduction in fraud. And in addition, on-line transactions ("card not present"[CNP]) made via Apple Pay are to be charged the lower "card-present" rate - because of the solid authentication. (*) This is a big deal for on-line merchants. They will be very happy to accept Apple Pay. I expect that banks and card issuers will be OK with giving up 0.15% to Apple if it does indeed reduce fraudThey will come out ahead. Some reports have said that, in return for the 0.15%, Apple will accept some liability but that percentage seems to me to be too low for that.
* I have no idea how Apple Pay will work for on-line transactions. It clearly cannot be NFC, although I guess the token data is stored in the secure element in the NFC chip. This will indeed be interesting to see.
Completely agree, and so far, I have not seen any mention if Apple is going to work on a method to do this (for general e-commerce transactions with an online merchant via Safari) yet. The benefit seems so large though for Apple's drive into payment facilitation that they would find a way. If Apple will support it for Apps via an API, it should be possible I would think.
Would it only work on iOS devices? Would they extend to the Mac in some way, or even more broadly as is mentioned in this thread, use a means of linking an iPhone with a PC as well (not sure I see the benefit to Apple as much in that method).
This is why I expect the new iPads to support Apple Pay - not for the NFC part (might be useful in business as a terminal?), but as iPads are much more used for online/e-commerce.
I agree. It is much easier to shop on iPad than iPhone !
Quote:
Originally Posted by brucemc
Right now Apple has a good lead here. While Google Wallet is of course available for Android devices, getting the combination of reliable biometric authentication, secure information storage, payment ecosystem buy-in, & ability to bypass the mobile operators (who have a competing solution), is a challenge. Samsung have a fingerprint reader (how reliable?), but they can't just tie that into Google Wallet in the secure manner that Apple has. Not sure Samsung's carrier partners will support it.
Wow - you touch on lots of hot buttons !
- carrier lock-in: this has indeed been a problem. The carriers feel that they "own" the phone and therefore want a slice of the action with any payment solution. Ideally, payments would run through your monthly bill. Google did not want this, nor does Apple. But Apple has the advantage in that it has never allowed carriers to control the customer relationship. This is a crucial point that many folks still do not appreciate - Samsung's customers are Verizon, ATA&T, Sprint, T-Mobile, etc whereas Apple's customers are you, you and you. That is why you get iOS updates directly from Apple, and security fixes in a timely fashion. But people with, for example, Samsung phones, have to wait for security fixes until Verizon, ATA&T, Sprint, T-Mobile, etc get around to it. Which may take a while, as we have seen.
- fingerprint reader: reviews of Samsung's effort have been less-than-complimentary. David Pogue said it was hard to use and not very accurate, unlike the Apple reader. Every other one I've seen has made similar comments. Almost that it's a check-box on the feature-list rather than being an actual usable capability. Not having used one, I can't comment from personal experience.
- Samsung partners: who know how this will work? A number of people [including me] were surprised that the Apple Pay announcement did not include PayPal. Yes - it's sort of a competitor but there are some synergies. It could well have been a win-win. But now we know that it was eBay's CEO that insisted upon the earlier PayPal-Samsung deal. And his imminent departure gives a clue about how well that deal has gone down. PayPal would love to have that deal back and, after the spin-out, maybe they will. Maybe.
Would it only work on iOS devices? Would they extend to the Mac in some way, or even more broadly as is mentioned in this thread, use a means of linking an iPhone with a PC as well (not sure I see the benefit to Apple as much in that method).
Working on Windows will be just as important as it was for iPod, back in that day. And we know how important that was.
If there's a way to make it work safely on Windows then that's what will happen. A quick look at this chart
shows just how much of Apple's revenue comes from iPhone. Enabling Apple Pay via Windows will help sell more iPhones. Apple isn't about to kill that in order to encourage Mac sales.
NexusPhan suggested Bluetooth as a solution (I hadn't thought of that) and it seems that it could be a nice solution. The iPhone would do all the security work (dealing with the token etc) and the browser would just pass through the secured blob. This would neatly sidestep the security problems with a browser interface. It would also open up the solution to suitably-equipped Windows machines (I would expect that more than a few iPhone 6 users use Windows).
Don't you love having good, technical discussions between people that just love technology for the sake of technology!??
Too bad most times it seems to get lost in useless rhetoric of them vs. us.
Nice talking with you, plovell and SolipsismX. You remind me of how good the vast majority Apple (and the other guys too) fans are.
Comments
I think that's fine, if it's going directly to an NFC system, but I don't like the idea of this representational card number plus pin being and recorded by an untold number of sites because that hurts the overall security. I'd like to see unique representational card numbers for each person for each website (or groups of websites owned a single entity) for securing payments so that the breach of one financial server will not affect any other card number on file. This also means that scams like we saw last year where hackers were able to see the last-four CC digits is shown on an Amazon account and then use to verify their ID with an Apple CSR will not be able to exist.
+1 Good comment. My thoughts are similar.
When the details emerged, I was surprised at the low percentage that Apple gets. Small enough to ask myself "why?". It's 0.15% whereas the banks/issuers get 2.5 - 3.0% So Apple is certainly not doing it for the money. And the revenue comes as part of the existing "fee" and is not an additional fee on top of the 2.5 - 3.0% It seems that the banks/FIs are willing to give up this small amount in return for a reduction in fraud. And in addition, on-line transactions ("card not present"[CNP]) made via Apple Pay are to be charged the lower "card-present" rate - because of the solid authentication. (*) This is a big deal for on-line merchants. They will be very happy to accept Apple Pay. I expect that banks and card issuers will be OK with giving up 0.15% to Apple if it does indeed reduce fraud They will come out ahead. Some reports have said that, in return for the 0.15%, Apple will accept some liability but that percentage seems to me to be too low for that.
* I have no idea how Apple Pay will work for on-line transactions. It clearly cannot be NFC, although I guess the token data is stored in the secure element in the NFC chip. This will indeed be interesting to see.
Completely agree, and so far, I have not seen any mention if Apple is going to work on a method to do this (for general e-commerce transactions with an online merchant via Safari) yet. The benefit seems so large though for Apple's drive into payment facilitation that they would find a way. If Apple will support it for Apps via an API, it should be possible I would think.
Would it only work on iOS devices? Would they extend to the Mac in some way, or even more broadly as is mentioned in this thread, use a means of linking an iPhone with a PC as well (not sure I see the benefit to Apple as much in that method).
This is why I expect the new iPads to support Apple Pay - not for the NFC part (might be useful in business as a terminal?), but as iPads are much more used for online/e-commerce.
I agree. It is much easier to shop on iPad than iPhone !
Right now Apple has a good lead here. While Google Wallet is of course available for Android devices, getting the combination of reliable biometric authentication, secure information storage, payment ecosystem buy-in, & ability to bypass the mobile operators (who have a competing solution), is a challenge. Samsung have a fingerprint reader (how reliable?), but they can't just tie that into Google Wallet in the secure manner that Apple has. Not sure Samsung's carrier partners will support it.
Wow - you touch on lots of hot buttons !
- carrier lock-in: this has indeed been a problem. The carriers feel that they "own" the phone and therefore want a slice of the action with any payment solution. Ideally, payments would run through your monthly bill. Google did not want this, nor does Apple. But Apple has the advantage in that it has never allowed carriers to control the customer relationship. This is a crucial point that many folks still do not appreciate - Samsung's customers are Verizon, ATA&T, Sprint, T-Mobile, etc whereas Apple's customers are you, you and you. That is why you get iOS updates directly from Apple, and security fixes in a timely fashion. But people with, for example, Samsung phones, have to wait for security fixes until Verizon, ATA&T, Sprint, T-Mobile, etc get around to it. Which may take a while, as we have seen.
- fingerprint reader: reviews of Samsung's effort have been less-than-complimentary. David Pogue said it was hard to use and not very accurate, unlike the Apple reader. Every other one I've seen has made similar comments. Almost that it's a check-box on the feature-list rather than being an actual usable capability. Not having used one, I can't comment from personal experience.
- Samsung partners: who know how this will work? A number of people [including me] were surprised that the Apple Pay announcement did not include PayPal. Yes - it's sort of a competitor but there are some synergies. It could well have been a win-win. But now we know that it was eBay's CEO that insisted upon the earlier PayPal-Samsung deal. And his imminent departure gives a clue about how well that deal has gone down. PayPal would love to have that deal back and, after the spin-out, maybe they will. Maybe.
Would it only work on iOS devices? Would they extend to the Mac in some way, or even more broadly as is mentioned in this thread, use a means of linking an iPhone with a PC as well (not sure I see the benefit to Apple as much in that method).
Working on Windows will be just as important as it was for iPod, back in that day. And we know how important that was.
If there's a way to make it work safely on Windows then that's what will happen. A quick look at this chart
http://www.asymco.com/wp-content/uploads/2014/10/Screen-Shot-2014-10-07-at-8.51.05-AM.png
shows just how much of Apple's revenue comes from iPhone. Enabling Apple Pay via Windows will help sell more iPhones. Apple isn't about to kill that in order to encourage Mac sales.
NexusPhan suggested Bluetooth as a solution (I hadn't thought of that) and it seems that it could be a nice solution. The iPhone would do all the security work (dealing with the token etc) and the browser would just pass through the secured blob. This would neatly sidestep the security problems with a browser interface. It would also open up the solution to suitably-equipped Windows machines (I would expect that more than a few iPhone 6 users use Windows).
Don't you love having good, technical discussions between people that just love technology for the sake of technology!??
Too bad most times it seems to get lost in useless rhetoric of them vs. us.
Nice talking with you, plovell and SolipsismX. You remind me of how good the vast majority Apple (and the other guys too) fans are.