The issuing company stores it because they issued it.
Probably not. The processor stores it and issues the token. That is, for example, how First Data runs their tokenized system (the company I work for has their API and other system documents on how to use this since we have been/will be integrating with them as a processor [we started, but is currently on hold for non technical business reasons]). The issuer is not involved in the process except at the end of the chain when the processor approves it with them.
The question is, with Apple Pay, is the "processor" in this chain Apple, or Apple's processor. I suspect it is Apple since this works across a bunch of issuer's and processors.
But I don't know. They may be embedded much more deeply into AMEX, Visa, and MC that a typical processor to make this work. It may go back to the issuer since Apple showed partnerships with various issuers in a slide, but if it does, it has to end up at the processor eventually to actually process the transaction.
We'll eventually see analysis of how it all works to get the details.
Probably not. The processor stores it and issues the token. That is, for example, how First Data runs their tokenized system (the company I work for has their API and other system documents on how to use this since we have been/will be integrating with them as a processor [we started, but is currently on hold for non technical business reasons]). The issuer is not involved in the process except at the end of the chain when the processor approves it with them.
The question is, with Apple Pay, is the "processor" in this chain Apple, or Apple's processor. I suspect it is Apple since this works across a bunch of issuer's and processors.
But I don't know. They may be embedded much more deeply into AMEX, Visa, and MC that a typical processor to make this work. It may go back to the issuer since Apple showed partnerships with various issuers in a slide, but if it does, it has to end up at the processor eventually to actually process the transaction.
We'll eventually see analysis of how it all works to get the details.
Even if Apple is involved it's folly to have a one-time token that needs to be linked over a network to Apple every time you use it. If Apple is involved it make more sense to generate a token and pin per-device to be stored LOCALLY. You need to be able to use this when your'e OFFLINE.
Even if Apple is involved it's folly to have a one-time token that needs to be linked over a network to Apple every time you use it. If Apple is involved it make more sense to generate a token and pin per-device to be stored LOCALLY. You need to be able to use this when your'e OFFLINE.
This makes no sense.
Your phone does not have to be online, but the merchant does. The merchant is not going to let you walk out with $100s of dollars of merchandise without the transaction being approved.
The local device token is transferred to the merchant through NFC. The merchant passes this through its encrypted channels to the backend processor.
Your phone does not have to be online, but the merchant does. The merchant is not going to let you walk out with $100s of dollars of merchandise without the transaction being approved.
The local device token is transferred to the merchant through NFC. The merchant passes this through its encrypted channels to the backend processor.
Someone has to be online.
You can't get a one-time token to give to the merchant unless you've been given a one-time token to give to the merchant! Not just someone, the merchant has to be online to verify the transaction with the token stored LOCALLY on your device.
You can't get a one-time token to give to the merchant unless you've been given a one-time token to give to the merchant! Not just someone, the merchant has to be online to verify the transaction with the token stored LOCALLY on your device.
Non sense. You can give a one time token generated on the phone based on the stored token. The backend can then decrypt that one time token to maybe retrieve the stored token or to identify the user/card. Lots of things that could be done. We don't know the details on how it works. But there are lots of ways it could work.
Non sense. You can give a one time token generated on the phone based on the stored token. The backend can then decrypt that one time token to maybe retrieve the stored token or to identify the user/card. Lots of things that could be done. We don't know the details on how it works. But there are lots of ways it could work.
Right from Apple's own site just as I envisioned it.
With Apple Pay, instead of using your actual credit and debit card numbers when you add your card, a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element, a dedicated chip in iPhone. These numbers are never stored on Apple servers. And when you make a purchase, the Device Account Number alongside a transaction-specific dynamic security code is used to process your payment. So your actual credit or debit card numbers are never shared with merchants or transmitted with payment.
Right from Apple's own site just as I envisioned it.
Local and device specific, no one-time use tokens for each transaction.
What Apple describes sounds awfully like a token to me. "the Device Account Number alongside a transaction-specific dynamic security code is used to process your payment."
"transaction-specific dynamic security code plus the Device Account Number seems to be functionally the same as a one time dynamic token...
What Apple describes sounds awfully like a token to me. "the Device Account Number alongside a transaction-specific dynamic security code is used to process your payment."
"transaction-specific dynamic security code plus the Device Account Number seems to be functionally the same as a one time dynamic token...
IT IS A TOKEN BUT IT'S NOT A ONE TIME USE TOKEN SENT FROM APPLE'S SERVERS. IT'S A REUSABLE TOKEN SPECIFIC FOR THAT CARD FOR THAT DEVICE. THIS IS WHAT I'VE BEEN EXPLAINING. THIS IS HOW IT'S MORE SECURE AND YET MORE CONVENIENT THAN YOUR SYSTEM THAT USES A CENTRALIZED SERVER TO GET THE TOKEN. ONLY THE MERCHANT NEEDS TO BE ONLINE TO VERIFY WITH THE FINANCIAL INSTITUTION. IT'S LIKE GMAIL'S PER DEVICE EMAIL PASSWORD TOKENS THAT ARE USED AS A PASSWORD FOR ACCESSING GMAIL VIA A 3RD PARTY APP INSTEAD OF USING YOUR STANDARD GMAIL USERNAME AND PASSWORD.
IT IS A TOKEN BUT IT'S NOT A ONE TIME USE TOKEN SENT FROM APPLE'S SERVERS. IT'S A REUSABLE TOKEN SPECIFIC FOR THAT CARD FOR THAT DEVICE. THIS IS WHAT I'VE BEEN EXPLAINING. THIS IS HOW IT'S MORE SECURE AND YET MORE CONVENIENT THAN YOUR SYSTEM THAT USES A CENTRALIZED SERVER TO GET THE TOKEN. ONLY THE MERCHANT NEEDS TO BE ONLINE TO VERIFY WITH THE FINANCIAL INSTITUTION. IT'S LIKE GMAIL'S PER DEVICE EMAIL PASSWORD TOKENS THAT ARE USED AS A PASSWORD FOR ACCESSING GMAIL VIA A 3RD PARTY APP INSTEAD OF USING YOUR STANDARD GMAIL USERNAME AND PASSWORD.
CAPS KEY STUCK?
I never claimed that a one time token was retrieved by the phone from Apple Servers and then presented by the phone to the POS system. I said (you can see it above, here paraphrased) that the phone presents itself to the POS system, the POS system talks to the backend (Apple) servers, which then processes the transactions and the Apple servers return a success token to the POS system signifying that the transaction went through (or not). In a nutshell, that seems to be how Apple Pay will work (in an overview sort of way).
You were claiming that the CC info itself was stored on the phone in the inaccessible part (now known as the secret enclave). That is what I was refuting and you never once, refuted my claim that this was not true.
You were claiming that the CC info itself was stored on the phone in the inaccessible part.
No I wasn't. As previously stated, since Touch ID came out I've been saying that's how it will work. Touch ID doesn't store your actual finger print, so neither will the Secure Element.
(now known as the secret enclave).
No it's not. It's the Secure Element. Secure Enclave is what they use last year for Touch ID. Whether it's a new chip or just a new name I don't know.
That is what I was refuting and you never once, refuted my claim that this was not true.
No, your comments were very much referring to the device having to poll Apple's servers to get a token. I said that was ridiculous for ease of use.
No I wasn't. As previously stated, since Touch ID came out I've been saying that's how it will work. Touch ID doesn't store your actual finger print, so neither will the Secure Element.
No it's not. It's the Secure Element. Secure Enclave is what they use last year for Touch ID. Whether it's a new chip or just a new name I don't know.
No, your comments were very much referring to the device having to poll Apple's servers to get a token. I said that was ridiculous for ease of use.
Ok, secret element. Whatever.
My posts were NEVER about the device having to poll Apple's servers to get a token. NEVER.
I said :
Quote:
I think this is backwards. The CC info never has to be on your phone. Your phone communicates with the POS (point of sale system) which communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security.
I never once said that the device was polling Apple's servers for a token. It is vert clear that the phone communicates with the merchant (POS) which communicates with the Apple backend system. The Apple backend system facilitates the transaction authorization and returns an authorized token back to the POS system (which signifies the results of the transaction).
But you never once made the claim that the CC info is not being stored on the phone. I brought it up many times as your claim and you never refuted it my doing so.
My posts were NEVER about the device having to poll Apple's servers to get a token. NEVER.
I said :
I never once said that the device was polling Apple's servers for a token. It is vert clear that the phone communicates with the merchant (POS) which communicates with the Apple backend system. The Apple backend system facilitates the transaction authorization and returns an authorized token back to the POS system (which signifies the results of the transaction).
But you never once made the claim that the CC info is not being stored on the phone. I brought it up many times as your claim and you never refuted it my doing so.
1) That's the issue I repeatedly took with your comments. You clearly stated otherwise.
2) The CC info is being stored on the iPhone. That's the whole point! It's LOCAL. It's not in plaintext and it's not a representational value, just like with Touch ID, but it's still your CC info that allows for the transaction to be made otherwise none of this would work.
3) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
This is what I said all along. While people are arguing about which methods to transfer data are safer (NFC vs BT vs WiFI vs LTE and claiming NFC is safer due to the short distance) I stated that security lies not in the method of data transfer but not sending personal/confidential data in the first place, and replacing that data with some type of ID or key (token if you like) that is useless to thieves even if they did capture it.
I thought that's the way other "wallets" like Google Wallet and PayPal Mobile worked too.
"Your actual credit card number is not stored. Only the virtual prepaid card is stored and Android's native access policies prevent malicious applications from obtaining the data. In the unlikely event that the data is compromised, Wallet also uses dynamically rotating credentials that change with each transaction and are usable for a single payment only."
1) That's the issue I repeatedly took with your comments. You clearly stated otherwise.
2) The CC info is being stored on the iPhone. That's the whole point! It's LOCAL. It's not in plaintext and it's not a representational value, just like with Touch ID, but it's still your CC info that allows for the transaction to be made otherwise none of this would work.
#1) Where did I clearly state otherwise? I already quoted what I did say. And what I did say is not what you claim I said. Please show me.
#2) The CC info is NOT being stored on the phone. Some sort of unique ID is being stored on the phone, with which Apple can look up the CC details on the backend. The normal CC info is number, expiration date, security code. That data is NOT being stored.
#1) Where did I clearly state otherwise? I already quoted what I did say. And what I did say is not what you claim I said. Please show me.
#2) The CC info is NOT being stored on the phone. Some sort of unique ID is being stored on the phone, with which Apple can look up the CC details on the backend. The normal CC info is number, expiration date, security code. That data is NOT being stored.
1) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
2) Yes, it is stored in the Secure Element just like a numerical representation of your fingerprint is stored in the Secure Enclave. That's the what the token is! It's your info that is needed to make a payment. It's not your 16-ish-digit CC number, with the 3 to 4 security digits on the back, with your full name, and expiration date but no one said that it would be. When people refer to the iPhone 5S storing your fingerprint data to unlock your device with Touch ID are you telling people it's not actually a picture of your fingerprint? Of course not!
1) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
2) Yes, it is stored in the Secure Element just like a numerical representation of your fingerprint is stored in the Secure Enclave. That's the what the token is! It's your info that is needed to make a payment. It's not your 16-ish-digit CC number, with the 3 to 4 security digits on the back, with your full name, and expiration date but no one said that it would be. When people refer to the iPhone 5S storing your fingerprint data to unlock your device with Touch ID are you telling people it's not actually a picture of your fingerprint? Of course not!
#1) Adding a card that is not in iTunes most certainly DOES add it to Apple's back end. You input them in your device, and Apple goes and verifies and approves the card and adds it to your account. Go watch the video. What you say makes no sense that it is ONLY on the device. Apple has clearly said a unique device ID is stored for each card, not the card info itself. Your #1 makes absolutely no sense and is in opposition to what you previously said (and say in #2).
#2) The card info is NOT stored in the "Secure Element". What is stored is the unique device ID for that card, which in generic technical jargon would be called a token. I am talking technical talk here, so no, I would not tell someone in a technical discussion that their fingerprint is stored in the phone. I would explain that characteristics of their fingerprint are stored and matched against new fingerprint scans that are analyzed for characteristics, all done in a secure, probably one-way (like good password implementations are one way), way.
You are talking out of both sides of your bum and each time you say something, it contradicts what you say earlier, even if you don't realize it. From a technical perspective, it does.
1) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
Constructive editing. You conveniently left off that the POS is communicating with the Apple backend system, which I clearly state, to give the allusion that I say the phone is doing so. The POS system passes the transaction info (amount and probably some ID info) plus the phone communicate token (unique device ID as passed to the POS by NFC) to the backend system for authorization and the backend system passes back a token that represents the success of that, which can be stored by the merchant safely but can be used to look up the transaction later in case of need.
#1) Adding a card that is not in iTunes most certainly DOES add it to Apple's back end. You input them in your device, and Apple goes and verifies and approves the card and adds it to your account. Go watch the video. What you say makes no sense that it is ONLY on the device. Apple has clearly said a unique device ID is stored for each card, not the card info itself. Your #1 makes absolutely no sense and is in opposition to what you previously said (and say in #2).
#2) The card info is NOT stored in the "Secure Element". What is stored is the unique device ID for that card, which in generic technical jargon would be called a token. I am talking technical talk here, so no, I would not tell someone in a technical discussion that their fingerprint is stored in the phone. I would explain that characteristics of their fingerprint are stored and matched against new fingerprint scans that are analyzed for characteristics, all done in a secure, probably one-way (like good password implementations are one way), way.
You are talking out of both sides of your bum and each time you say something, it contradicts what you say earlier, even if you don't realize it. From a technical perspective, it does.
1) No it's not. Apple is not storing your card on their iTunes Servers.
2) Yes it is. Apple is not storing your card on their iTunes Servers. That token is references your specific CC info. That's how it authenticates with the payment center to verify your purchase.
Constructive editing. You conveniently left off that the POS is communicating with the Apple backend system, which I clearly state, to give the allusion that I say the phone is doing so. The POS system passes the transaction info (amount and probably some ID info) plus the phone communicate token (unique device ID as passed to the POS by NFC) to the backend system for authorization and the backend system passes back a token that represents the success of that, which can be stored by the merchant safely but can be used to look up the transaction later in case of need.
That just makes it even more stupid. The merchant isn't talking to Apple to get a token for CC info stored on Apple's servers. For ****'s sake! Apple set this up exactly how I've been stating ever since Touch ID came out.
Probably not. The processor stores it and issues the token. That is, for example, how First Data runs their tokenized system (the company I work for has their API and other system documents on how to use this since we have been/will be integrating with them as a processor [we started, but is currently on hold for non technical business reasons]). The issuer is not involved in the process except at the end of the chain when the processor approves it with them.
The question is, with Apple Pay, is the "processor" in this chain Apple, or Apple's processor. I suspect it is Apple since this works across a bunch of issuer's and processors.
But I don't know. They may be embedded much more deeply into AMEX, Visa, and MC that a typical processor to make this work. It may go back to the issuer since Apple showed partnerships with various issuers in a slide, but if it does, it has to end up at the processor eventually to actually process the transaction.
We'll eventually see analysis of how it all works to get the details.
No, no, no. Apple issues the "token"... This was all explicitly described in their digital transactions patent that was shown here and on Patently Apple a while ago. You need to do the basic research before you post.
Comments
The issuing company stores it because they issued it.
Probably not. The processor stores it and issues the token. That is, for example, how First Data runs their tokenized system (the company I work for has their API and other system documents on how to use this since we have been/will be integrating with them as a processor [we started, but is currently on hold for non technical business reasons]). The issuer is not involved in the process except at the end of the chain when the processor approves it with them.
The question is, with Apple Pay, is the "processor" in this chain Apple, or Apple's processor. I suspect it is Apple since this works across a bunch of issuer's and processors.
But I don't know. They may be embedded much more deeply into AMEX, Visa, and MC that a typical processor to make this work. It may go back to the issuer since Apple showed partnerships with various issuers in a slide, but if it does, it has to end up at the processor eventually to actually process the transaction.
We'll eventually see analysis of how it all works to get the details.
Even if Apple is involved it's folly to have a one-time token that needs to be linked over a network to Apple every time you use it. If Apple is involved it make more sense to generate a token and pin per-device to be stored LOCALLY. You need to be able to use this when your'e OFFLINE.
Even if Apple is involved it's folly to have a one-time token that needs to be linked over a network to Apple every time you use it. If Apple is involved it make more sense to generate a token and pin per-device to be stored LOCALLY. You need to be able to use this when your'e OFFLINE.
This makes no sense.
Your phone does not have to be online, but the merchant does. The merchant is not going to let you walk out with $100s of dollars of merchandise without the transaction being approved.
The local device token is transferred to the merchant through NFC. The merchant passes this through its encrypted channels to the backend processor.
Someone has to be online.
You can't get a one-time token to give to the merchant unless you've been given a one-time token to give to the merchant! Not just someone, the merchant has to be online to verify the transaction with the token stored LOCALLY on your device.
You can't get a one-time token to give to the merchant unless you've been given a one-time token to give to the merchant! Not just someone, the merchant has to be online to verify the transaction with the token stored LOCALLY on your device.
Non sense. You can give a one time token generated on the phone based on the stored token. The backend can then decrypt that one time token to maybe retrieve the stored token or to identify the user/card. Lots of things that could be done. We don't know the details on how it works. But there are lots of ways it could work.
Right from Apple's own site just as I envisioned it.
Local and device specific, no one-time use tokens for each transaction.
Right from Apple's own site just as I envisioned it.
Local and device specific, no one-time use tokens for each transaction.
What Apple describes sounds awfully like a token to me. "the Device Account Number alongside a transaction-specific dynamic security code is used to process your payment."
"transaction-specific dynamic security code plus the Device Account Number seems to be functionally the same as a one time dynamic token...
IT IS A TOKEN BUT IT'S NOT A ONE TIME USE TOKEN SENT FROM APPLE'S SERVERS. IT'S A REUSABLE TOKEN SPECIFIC FOR THAT CARD FOR THAT DEVICE. THIS IS WHAT I'VE BEEN EXPLAINING. THIS IS HOW IT'S MORE SECURE AND YET MORE CONVENIENT THAN YOUR SYSTEM THAT USES A CENTRALIZED SERVER TO GET THE TOKEN. ONLY THE MERCHANT NEEDS TO BE ONLINE TO VERIFY WITH THE FINANCIAL INSTITUTION. IT'S LIKE GMAIL'S PER DEVICE EMAIL PASSWORD TOKENS THAT ARE USED AS A PASSWORD FOR ACCESSING GMAIL VIA A 3RD PARTY APP INSTEAD OF USING YOUR STANDARD GMAIL USERNAME AND PASSWORD.
IT IS A TOKEN BUT IT'S NOT A ONE TIME USE TOKEN SENT FROM APPLE'S SERVERS. IT'S A REUSABLE TOKEN SPECIFIC FOR THAT CARD FOR THAT DEVICE. THIS IS WHAT I'VE BEEN EXPLAINING. THIS IS HOW IT'S MORE SECURE AND YET MORE CONVENIENT THAN YOUR SYSTEM THAT USES A CENTRALIZED SERVER TO GET THE TOKEN. ONLY THE MERCHANT NEEDS TO BE ONLINE TO VERIFY WITH THE FINANCIAL INSTITUTION. IT'S LIKE GMAIL'S PER DEVICE EMAIL PASSWORD TOKENS THAT ARE USED AS A PASSWORD FOR ACCESSING GMAIL VIA A 3RD PARTY APP INSTEAD OF USING YOUR STANDARD GMAIL USERNAME AND PASSWORD.
CAPS KEY STUCK?
I never claimed that a one time token was retrieved by the phone from Apple Servers and then presented by the phone to the POS system. I said (you can see it above, here paraphrased) that the phone presents itself to the POS system, the POS system talks to the backend (Apple) servers, which then processes the transactions and the Apple servers return a success token to the POS system signifying that the transaction went through (or not). In a nutshell, that seems to be how Apple Pay will work (in an overview sort of way).
You were claiming that the CC info itself was stored on the phone in the inaccessible part (now known as the secret enclave). That is what I was refuting and you never once, refuted my claim that this was not true.
No I wasn't. As previously stated, since Touch ID came out I've been saying that's how it will work. Touch ID doesn't store your actual finger print, so neither will the Secure Element.
No it's not. It's the Secure Element. Secure Enclave is what they use last year for Touch ID. Whether it's a new chip or just a new name I don't know.
No, your comments were very much referring to the device having to poll Apple's servers to get a token. I said that was ridiculous for ease of use.
No I wasn't. As previously stated, since Touch ID came out I've been saying that's how it will work. Touch ID doesn't store your actual finger print, so neither will the Secure Element.
No it's not. It's the Secure Element. Secure Enclave is what they use last year for Touch ID. Whether it's a new chip or just a new name I don't know.
No, your comments were very much referring to the device having to poll Apple's servers to get a token. I said that was ridiculous for ease of use.
Ok, secret element. Whatever.
My posts were NEVER about the device having to poll Apple's servers to get a token. NEVER.
I said :
I never once said that the device was polling Apple's servers for a token. It is vert clear that the phone communicates with the merchant (POS) which communicates with the Apple backend system. The Apple backend system facilitates the transaction authorization and returns an authorized token back to the POS system (which signifies the results of the transaction).
But you never once made the claim that the CC info is not being stored on the phone. I brought it up many times as your claim and you never refuted it my doing so.
1) That's the issue I repeatedly took with your comments. You clearly stated otherwise.
2) The CC info is being stored on the iPhone. That's the whole point! It's LOCAL. It's not in plaintext and it's not a representational value, just like with Touch ID, but it's still your CC info that allows for the transaction to be made otherwise none of this would work.
3) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
I thought that's the way other "wallets" like Google Wallet and PayPal Mobile worked too.
"Your actual credit card number is not stored. Only the virtual prepaid card is stored and Android's native access policies prevent malicious applications from obtaining the data. In the unlikely event that the data is compromised, Wallet also uses dynamically rotating credentials that change with each transaction and are usable for a single payment only."
1) That's the issue I repeatedly took with your comments. You clearly stated otherwise.
2) The CC info is being stored on the iPhone. That's the whole point! It's LOCAL. It's not in plaintext and it's not a representational value, just like with Touch ID, but it's still your CC info that allows for the transaction to be made otherwise none of this would work.
#1) Where did I clearly state otherwise? I already quoted what I did say. And what I did say is not what you claim I said. Please show me.
#2) The CC info is NOT being stored on the phone. Some sort of unique ID is being stored on the phone, with which Apple can look up the CC details on the backend. The normal CC info is number, expiration date, security code. That data is NOT being stored.
1) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
2) Yes, it is stored in the Secure Element just like a numerical representation of your fingerprint is stored in the Secure Enclave. That's the what the token is! It's your info that is needed to make a payment. It's not your 16-ish-digit CC number, with the 3 to 4 security digits on the back, with your full name, and expiration date but no one said that it would be. When people refer to the iPhone 5S storing your fingerprint data to unlock your device with Touch ID are you telling people it's not actually a picture of your fingerprint? Of course not!
1) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
2) Yes, it is stored in the Secure Element just like a numerical representation of your fingerprint is stored in the Secure Enclave. That's the what the token is! It's your info that is needed to make a payment. It's not your 16-ish-digit CC number, with the 3 to 4 security digits on the back, with your full name, and expiration date but no one said that it would be. When people refer to the iPhone 5S storing your fingerprint data to unlock your device with Touch ID are you telling people it's not actually a picture of your fingerprint? Of course not!
#1) Adding a card that is not in iTunes most certainly DOES add it to Apple's back end. You input them in your device, and Apple goes and verifies and approves the card and adds it to your account. Go watch the video. What you say makes no sense that it is ONLY on the device. Apple has clearly said a unique device ID is stored for each card, not the card info itself. Your #1 makes absolutely no sense and is in opposition to what you previously said (and say in #2).
#2) The card info is NOT stored in the "Secure Element". What is stored is the unique device ID for that card, which in generic technical jargon would be called a token. I am talking technical talk here, so no, I would not tell someone in a technical discussion that their fingerprint is stored in the phone. I would explain that characteristics of their fingerprint are stored and matched against new fingerprint scans that are analyzed for characteristics, all done in a secure, probably one-way (like good password implementations are one way), way.
You are talking out of both sides of your bum and each time you say something, it contradicts what you say earlier, even if you don't realize it. From a technical perspective, it does.
1) Note that you clearly state in that one post you oddly think is supporting what you said, "…communicates with the Apple backend system. The CC info stays in the Apple backend system and Apple authorizes it and returns an authorized token back to the POS which completes the sale. That is the only sane and logical way it could work and be an advance in security." No! You input the cards on your device. That's it! The only option, for convenience, is if you already have a CC on file with Apple, then that card info can be transferred to the device, but adding cards to the device directly will not save them to Apple's back end..
Constructive editing. You conveniently left off that the POS is communicating with the Apple backend system, which I clearly state, to give the allusion that I say the phone is doing so. The POS system passes the transaction info (amount and probably some ID info) plus the phone communicate token (unique device ID as passed to the POS by NFC) to the backend system for authorization and the backend system passes back a token that represents the success of that, which can be stored by the merchant safely but can be used to look up the transaction later in case of need.
1) No it's not. Apple is not storing your card on their iTunes Servers.
2) Yes it is. Apple is not storing your card on their iTunes Servers. That token is references your specific CC info. That's how it authenticates with the payment center to verify your purchase.
That just makes it even more stupid. The merchant isn't talking to Apple to get a token for CC info stored on Apple's servers. For ****'s sake! Apple set this up exactly how I've been stating ever since Touch ID came out.
Probably not. The processor stores it and issues the token. That is, for example, how First Data runs their tokenized system (the company I work for has their API and other system documents on how to use this since we have been/will be integrating with them as a processor [we started, but is currently on hold for non technical business reasons]). The issuer is not involved in the process except at the end of the chain when the processor approves it with them.
The question is, with Apple Pay, is the "processor" in this chain Apple, or Apple's processor. I suspect it is Apple since this works across a bunch of issuer's and processors.
But I don't know. They may be embedded much more deeply into AMEX, Visa, and MC that a typical processor to make this work. It may go back to the issuer since Apple showed partnerships with various issuers in a slide, but if it does, it has to end up at the processor eventually to actually process the transaction.
We'll eventually see analysis of how it all works to get the details.
No, no, no. Apple issues the "token"... This was all explicitly described in their digital transactions patent that was shown here and on Patently Apple a while ago. You need to do the basic research before you post.