No, the retailer will have to follow the protocol that Apple established in order for the request to go through. The request for payment will have to come from the point of sales terminal, and Iphone will have to response to the request in a format that the POS terminal understand. So the retailer and Apple will have to work together. And at the end of the process, the retailer will need to be able to take the "authorization code" and get payment from the credit card company. It is easy to talk very high level what will happen, the detail implementation is going to be very complicate. For now only Apple has the scale and infrastructure in place to implement a solution like this. Exisiting Itune codes will be front and center in getting the request to the CC companies and getting the authorization back in a secure way.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Pay Details: Apple Gets 0.15% Cut of Purchases, Higher Rates for Bluetooth Payments
- Thread starter MacRumors
- Start date
- Sort by reaction score
No, the retailer will have to follow the protocol that Apple established in order for the request to go through. The request for payment will have to come from the point of sales terminal, and Iphone will have to response to the request in a format that the POS terminal understand. So the retailer and Apple will have to work together. And at the end of the process, the retailer will need to be able to take the "authorization code" and get payment from the credit card company. It is easy to talk very high level what will happen, the detail implementation is going to be very complicate. For now only Apple has the scale and infrastructure in place to implement a solution like this. Exisiting Itune codes will be front and center in getting the request to the CC companies and getting the authorization back in a secure way.
However, if you use the correct amount (0.15%), Apple gets 1.5 billion from 1 trillion of charges viapay. That's hardly pocket change.
Over time, this is going to be a significant revenue stream for Apple.
And how big a computer center Apple have to build up to handle 1 Trillion dollars worth of the transactions in real time? the real value of this Apple pay is that it become a "hard" lock on it's user bases. Anyone who use Apple pay will have to own an Iphone and they will become an Apple user for life. Today Apple only offer "soft" lock to user by having their Itune purchase and the time users spend in learning IOS + unique apps on IOS. It is a brilliant move on Apple's part. If they pull it off, the entire mobile platform competitive landscape will change and the high end Android in countries that have Apple pay will have a very hard time competing with Apple.
The have your PIN they don't store it, and the card info is useless except in the rare transaction where you only need PAN and expiration date. There isn't enough info to create a counterfeit card nor is there a CVV2.
Thanks for your detailed and courteous reply, this is greatly appreciated in times when people tend to be at each other throats in forumsIt's great that you described what you think is the process of phone payment. From what I read in Apple's website the process is simpler than what you describe.
* Take iPhone
* Move it close to credit card reader
* place finger on Touch ID fingerprint sensor
* No need for PIN, or unlock, just wait for confirmation beep and vibration.
* Done!
This is obviously if you pay with a default card (which is my case). If you have to choose another card, then I guess the steps that you describe would have to be done and the convenience goes down quickly from there if you need to involve Passbook
If someone need to select a different CC card for different store, they will appreciate Apple pay the most. Have you ever try to go through your wallet (or god forbidden woman with big purse full of 'stuff") and try to pull out the right credit cards? I only have 3 credit cards with 10 or so other cards (theater cards, grocery cards, library cards, gas station cards.. need I say more?). It takes me quite a bit of time at the counter to pull the right card out. If Apple pay offer some way to optimize CC rebate or other simple criteria that user can pick in picking the right CC credit (e.g. Discover gives 3% rebate on all restaurant bill for two weeks, so Apple pay suggest using my discover card instead of my master card to pay the bill tonight..wouldn't it be great?)
----------
And Chip and sign (US) or Chip and passcode (Europe) don't offer any solution for online shopping.. With Apple pay, you can use the iphone to make payment for online shopping as well as store purchase. In the online shopping case, they don't even need the NFC chip, all it need is to tie the shopping website with Apple and they are done...
Ever dropped your card or wallet? Forgot it in a bar? I can't wait until we start reading the stories on here.
----------
Reality is most people have the same PIN for all their cards (and their phone usually).
Most people only have one card though, so no big deal.
So ApplePay will be incompatible with current NFC terminals? that would make ApplePay dead on arival in Australia. Here almost all retailer and credit cards already have NFC.
It seems to me that ApplePay is designed around the US, were iOS has a significant market share and NFC is not widespread.
I don't believe so, I'm pretty sure it is just standard EMV contactless. It first detects (but ignores) the reader, then you authenticate and it presents itself as a payment card, I believe.
I'm pretty sure this is incorrect. An ApplePay transaction looks the same to the NFC terminal as any other NFC payment. The magic sauce is how your phone and bank communicate to generate the token and secure it with TouchID. Everything is the same to the retailer.
This is totally incorrect.
An Apple Pay transaction is, to a POS terminal, a standard EMV transaction.
The terminal has no idea that temporary tokens were sent in place of the card account number, card expiry date, and chip cryptogram. The detokenization is handled way up at the payment network level.
As far as I can tell, the ONLY thing that MIGHT need to be done to some EMV terminals to facilitate accepting Apple Pay, is for them to be provisioned with the special Bank Identification Numbers that Mastercard, VISA, et al, now associate with tokenized cards. In most cases, this is done automatically, and would have to be done anyway.
(Google Wallet uses an existing Mastercard BIN, and thus was always okay.)
Ignoring the fact that your example is bogus because Discover hasn't signed with Apple yet...
At this time, Apple claims to not have (direct) access to the transaction details, and thus cannot do what you suggest. Nor does the retailer have any idea who you are, because of the card tokenization.
Google Wallet does, and could do your idea.
At this point, with iOS, the push seems to be for retailers to do their own custom payment apps. This allows them access to both their own information about you, and to Apple Pay.
I don't think it will be such a difficult transition to switch from Apple Pay to Google Wallet here in a few years. I imagine that almost all POS terminals will have the capability to work with both systems, in order to avoid losing half of their potential revenue stream. Google Wallet has so far not taken off, but the success of Apple Pay will change that, as companies are incentivized to upgrade their systems.
ApplePay 101
Most of these assumptions are wrong and the answers are in the ApplePay docs and the fact that it is only initially available for use with US banks. That implies they are using, for MasterCard anyway, PayPass MagStripe, so no EMV for now.
The mechanism also uses the tokenised method of credential exchange announced by Mastercard, Visa and AMEX recently.
So what happens is that when your card is registered an exchange takes place with the issuing bank to transfer a onetime payment 'token' and a cryptogram used for the terminal auth. When the user indicates payment the cryptogram and the token are exchanged. The terminal passes the token to the issuer who decrypts and auth's the transaction. The iPhone then needs a new payment load of token and cryptogram for the next payment. This is really fact - fast enough for transport applications.
So Apple never sees the transaction detail and so cannot charge a %age of its value. QED. Apple acts a a transport channel only and not a financial intermediary. Smart huh?
Most of these assumptions are wrong and the answers are in the ApplePay docs and the fact that it is only initially available for use with US banks. That implies they are using, for MasterCard anyway, PayPass MagStripe, so no EMV for now.
The mechanism also uses the tokenised method of credential exchange announced by Mastercard, Visa and AMEX recently.
So what happens is that when your card is registered an exchange takes place with the issuing bank to transfer a onetime payment 'token' and a cryptogram used for the terminal auth. When the user indicates payment the cryptogram and the token are exchanged. The terminal passes the token to the issuer who decrypts and auth's the transaction. The iPhone then needs a new payment load of token and cryptogram for the next payment. This is really fact - fast enough for transport applications.
So Apple never sees the transaction detail and so cannot charge a %age of its value. QED. Apple acts a a transport channel only and not a financial intermediary. Smart huh?
ALSO most likely incorrect, because if they follow EMVco specs the terminal needs to know it is receiving tokenised data, because there are situations where detokenisation is possible - and necessary.
To give you an example of a merchant who needs to know they're getting a token and needs to be able to detokenise - Transport for London. Implementing contactless on the Tube. If tokenisation wasn't visible touch-in/touch-out on the Tube wouldn't track properly. This is a big reason why buses were first with contactless - no touch-out is needed.
The terminal can, of course, inspect the BIN and/or payload and figure out if it's a tokenized transaction, but the point is that it does not need to know in order to process a normal purchase.
As for EMVCo specs, I see nothing that says a merchant terminal must have any way to detokenize the transaction itself. The whole point is that they (and anyone listening in) cannot see the real account number.
Then they're going to have to figure that one out
Perhaps the optional Token Requestor Id can be used for the system to notice that it's the same person.
Biased much?
I've drenched my wallet a lot more often than I've lost it. A wet $20 bill is still worth $20 and a wet credit card still works.
I come home with a dead phone battery a few times a year. The iPhone battery life is pathetic to start with.
I recently had my CC information compromised in the Home Depot hacking incident. My bank informed me of this last Thursday and put a very low limit on the card to protect it until they could send me a new one. This of course put a damper on me ordering my iPhone as I didn't catch how low the limit was until my CC was turned down while trying to order.
I went to the bank and they issued me a new card on the spot, and I got my iPhone ordered with a ship date of 9/23 to 10/02 instead of this Friday.
However, reading this thread I could not help but think that ifPay had already been in effect then my card would not have been compromised, and I would not have to go through all my accounts, on line and otherwise, to update the information.
Since the charge on the card at Home Depot was only about $20.00 then Apples cut, if you will, is only about 3 cents. The vast majority of card charges are like this. Do I mind being charged an extra 3 cents on a $20.00 charge so I don't have to go through all the hassle that I'm doing now? You bet I don't mind.
Plus I like the idea of the bad guys losing sleep while trying to figure out a way to hack this system.
Go Apple - goPay!
I went to the bank and they issued me a new card on the spot, and I got my iPhone ordered with a ship date of 9/23 to 10/02 instead of this Friday.
However, reading this thread I could not help but think that if
Pay had already been in effect then my card would not have been compromised, and I would not have to go through all my accounts, on line and otherwise, to update the information. Since the charge on the card at Home Depot was only about $20.00 then Apples cut, if you will, is only about 3 cents. The vast majority of card charges are like this. Do I mind being charged an extra 3 cents on a $20.00 charge so I don't have to go through all the hassle that I'm doing now? You bet I don't mind.
Plus I like the idea of the bad guys losing sleep while trying to figure out a way to hack this system.
Go Apple - go
Pay!NFC is just a communication hardware and protocol.. You need much more higher software in Iphone and retailer's terminal to make Apple pay work.
----------
NFC is just like a bluetooth or wifi communication protocol. There are a lot of details about the protocol itself. But once you get pass the ability to talk to each other, the interest part is what is Iphone going to tell the terminal and what is the terminal going to tell Iphone to complete those transaction. Those are the details that the software on both hardware (Iphone and POS terminal) has to support. Supporting NFC just means that they can talk to each other and nothing more. Apple already talked on a very high level of what the magic is. They are going to use Itune to talk to CC companies to generate the tokens..
----------
As far as I can tell, there is a fundamental difference between Google wallet vs Apple pay. Apple want to be just a channel while Google want to download all your transactions. And the fact that they want to know our transaction step on a lot people's toes...
I think you are assuming a lot more than what Apple tell us to this point. The use the term "token" for the information that they sent to the POS terminal. There is no discussion of whether the transaction will looks exactly like a standard credit card number or not. The details has a lot to do with what the token looks like and what processing is necessary to authentic the token itself is a valid token and how would retailer take the token and collect money from retailer. So far Apple announcement use the term "token" and not a one time credit card number, so it is not quite right for us to assume that it is a standard transaction.
With Itune our card number, so Apple know what credit card we are using. I don't invent this stuff. Apple has applied for an Iwallet patent in 2012 and I read the patent summary. It listed a lot manage function of Iwallet which include real time authorization of credit limit by card owner to attachment card (e.g. cards that we give the kids), real time fraud reporting, access to the credit card company and get real time purchasing summary etc. etc. How many of these features will go into the eventual implementation of Iwallet is an open questions. But it is a very powerful tool for Apple to lock it's customer to the ecosystem.
NFC stand for near field communication. It is a communication standard allowing different devices that support the protocol to talk to each other and nothing more. What happen to the data passing back and forth once they establish their communication is up to the individual software running on both sides. And my simple point is that so far from what Apple tell us, someone need to write the software on the Iphone and Itune side, someone need to write software on the credit card company side, and someone need to write software on the retailers POS and corporate processing side. None of these thing will magically happen, so the roll out is going to be slow...
For Google, that's kinda the point in Google Wallet. Apple has a partnership with banks to pass transactions through as-is for a cut of profit.
Google acts as a merchant aggregator and provides a proxy card, a situation where they take a LOSS on most transactions. They're willing to do this in exchange for the marketing value of the transaction data.
Thus, it's actually a very good thing that Google's method lets them see all your transactions and analyse them - that's the whole point in Google Wallet.
There is tons of information coming out, especially from related companies like First Data, Mastercard, Visa, et al, that Apple Pay is basically using the new card branded tokenization standards derived from the EMV specs, just as I said.
I'm really busy today, but I'm going to start with just a few quotes pointing out that Apple Pay is standard EMV.
First, what industry observers say:
Then, more to the point, what Mastercard says:
Finally, very specific info from First Data, who is deeply involved with both Google's original, and Apple's current, wallets:
The EMV standards already tell us that the transactions re-use current transaction fields so it looks like a regular transaction. The virtual account numbers are de-tokenized in the payment cloud, outside of the merchant systems.
It also looks like Apple Pay is probably similar to Google Wallet in that a single virtual account number is used for multiple transactions, along with dynamic cryptograms for that particular purchase.
The virtual account number can change if needed, but it's really not necessary to keep it secret, since it's useless without the right keys to create the transaction cryptograms.
Last edited:
Question: Do contactless cards from one country work in another? For instance it seems both Canada and Australia have widely used contactless infrastructures, so can an Australian go to Canada and wave their card over a reader to make a purchase? And vice versa?
I'm asking because if this does work, then US users should be able go abroad and use ApplePay as soon as it works on our phones, correct? The only thing that makes it US only initially getting it integrated into the card issuing banks here. Once that's done and we're set up with our card issuing banks, shouldn't we be able to travel abroad and use ApplePay even if it's not technically active in that country yet? Our phones will simply be emulating a US based contactless card.
I'm asking because if this does work, then US users should be able go abroad and use ApplePay as soon as it works on our phones, correct? The only thing that makes it US only initially getting it integrated into the card issuing banks here. Once that's done and we're set up with our card issuing banks, shouldn't we be able to travel abroad and use ApplePay even if it's not technically active in that country yet? Our phones will simply be emulating a US based contactless card.