1) Good ol' SecurID. I kind of miss using their 2-factor authentication.
2) That's the assumption. Didn't Cook even say the device generates a one-time use token? Before he stated that I assumed it would be a one-time token per card per device, which is already inherently much safer than a physical card, but it sounded like he meant there is a one-time token per card per device that generates one-time use tokens to send to the payment agent.
This is directly from Apple's website.
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.
Sounds like there's a one-time token attached to device identifier.
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
Cool.
Yes, this was stated by Rene Ritchie on MacBreak Weekly on the day of the reveal. He was the only person I know of who asked that question.
2) That's the assumption. Didn't Cook even say the device generates a one-time use token? Before he stated that I assumed it would be a one-time token per card per device, which is already inherently much safer than a physical card, but it sounded like he meant there is a one-time token per card per device that generates one-time use tokens to send to the payment agent.
So what does the payment agent do with this one-time token generated by the Device Account Number created when the card is added to the device (per Apple)? How does the payment agent translate this token into a usable card number so that the payment can be processed? At the end of the day, a user's account for a specific card needs to be charged with the transaction so somewhere there has to be a "translation" (reverse tokenization, card lookup, or something).
Also, note the article on AI that claims Apple will get a cut of the "swipe fees." I don't think that is possible if Apple's servers never see any part of the transaction.
The more I think about this, the more it looks to me like Apple is bypassing the traditional payment processor all together -- i.e., Apple is not handing this off to First Data or PaymentTech or any other processor -- Apple IS the processor and works directly with Visa/MC/AMEX and the issuing banks as if it were First Data or PaymentTech (or whoever), itself. Maybe Visa/MC/AMEX will issue a token to Apple that Apple associates on its servers with the Device Account Number assigned for a specific card/device pair and when a transaction comes in, the merchant passes this Device Account Number and the transaction security key Apple spoke of, looks up the actual token from Visa/MC/AMEX and pass that token to Visa/MC/AMEX to process, so that the number itself doesn't leave the issuer/network. Apple clearly says in the video that when you take a picture of the card, the card data is uploaded for authentication/verification (and the diagram for the patent in the root of the article these comments are for shows this). That could be when Visa/MC/AMEX also issue Apple a token to associate with it. (This is just logically thinking through things to their conclusion plus public comments, not based on insider knowledge.) If this is the case, Apple does not store the CC data to look up when passed the Device Account Number stuff, but a proxy, the token issued by the network (Visa et al).
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
Cool.
Yes, cool! I was not that excited about the watch until I watched the Jony Ive narrated Apple Watch video... Now, me want (and I don't currently and have not in almost 8 years, wear a watch)
So what does the payment agent do with this one-time token generated by the Device Account Number created when the card is added to the device (per Apple)? How does the payment agent translate this token into a usable card number so that the payment can be processed? At the end of the day, a user's account for a specific card needs to be charged with the transaction so somewhere there has to be a "translation" (reverse tokenization, card lookup, or something).
Also, note the article on AI that claims Apple will get a cut of the "swipe fees." I don't think that is possible if Apple's servers never see any part of the transaction.
The more I think about this, the more it looks to me like Apple is bypassing the traditional payment processor all together -- i.e., Apple is not handing this off to First Data or PaymentTech or any other processor -- Apple IS the processor and works directly with Visa/MC/AMEX and the issuing banks as if it were First Data or PaymentTech (or whoever), itself. Maybe Visa/MC/AMEX will issue a token to Apple that Apple associates on its servers with the Device Account Number assigned for a specific card/device pair and when a transaction comes in, the merchant passes this Device Account Number and the transaction security key Apple spoke of, looks up the actual token from Visa/MC/AMEX and pass that token to Visa/MC/AMEX to process, so that the number itself doesn't leave the issuer/network. Apple clearly says in the video that when you take a picture of the card, the card data is uploaded for authentication/verification (and the diagram for the patent in the root of the article these comments are for shows this). That could be when Visa/MC/AMEX also issue Apple a token to associate with it. (This is just logically thinking through things to their conclusion plus public comments, not based on insider knowledge.) If this is the case, Apple does not store the CC data to look up when passed the Device Account Number stuff, but a proxy, the token issued by the network (Visa et al).
Could it be that Apple handles the transaction the way they do with media purchases?
Could it be that Apple handles the transaction the way they do with media purchases?
Anything is of course possible, but I think not. For media purchases, Apple IS the merchant and goes through a 3rd part processor like First Data or PaymentTech or one of the others. They pay the merchant fees associated with the purchase. They work with most any credit card, regardless of the issuer.
What we know about Apple Pay: works only with certain credit cards -- AMEX, Visa, MC and only those issued by certain banks or issuers (see Apple.com/apple-pay/ I believe for details). According to AI, Apple will be GETTING (a piece of the) merchant fees, not paying them. Apple is not a merchant, but acts more like a processor in some way, facilitating the transaction.
If Apple were a pass through processor (like PayPal or Venmo) then they would be paying fees on every transaction you did with Apple Pay at McDonalds etc. which they would have to add on to the normal merchant fees so it would be more expensive for a merchant to accept Apple Pay, which is a big turn-off. (This is why PayPal cannot offer you as good a rate to process a credit card for you as you can usually get yourself if you have a business [in my experience taking credit cards for 18 years]). Your credit card bill would also say Apple on it plus the merchant, similar to what PayPal charges look like on your card, most likely.
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
Cool.
That function has been at the core of my Apple wearable desire from the start, but in regards to the wrist-worn device that will un/lock your Mac and iPhone when the wearable is x-many feet away.
Anything is of course possible, but I think not. For media purchases, Apple IS the merchant and goes through a 3rd part processor like First Data or PaymentTech or one of the others. They pay the merchant fees associated with the purchase. They work with most any credit card, regardless of the issuer.
What we know about Apple Pay: works only with certain credit cards -- AMEX, Visa, MC and only those issued by certain banks or issuers (see Apple.com/apple-pay/ I believe for details). According to AI, Apple will be GETTING (a piece of the) merchant fees, not paying them. Apple is not a merchant, but acts more like a processor in some way, facilitating the transaction.
If Apple were a pass through processor (like PayPal or Venmo) then they would be paying fees on every transaction you did with Apple Pay at McDonalds etc. which they would have to add on to the normal merchant fees so it would be more expensive for a merchant to accept Apple Pay, which is a big turn-off. (This is why PayPal cannot offer you as good a rate to process a credit card for you as you can usually get yourself if you have a business [in my experience taking credit cards for 18 years]). Your credit card bill would also say Apple on it plus the merchant, similar to what PayPal charges look like on your card, most likely.
Here's what I think. Now, when retailers swipe your CC into their reader, they are sending your CC and amount of charge to the CC issuer for pre-approval for that amount. If the card is good and the account has enough to cover the charge, an approval transaction number is sent back to the retailer and the funds are transfered to the retailers account. When a retailer does this, there's a fee for using this pre-approval process. It's added to the discount fee that they have to pay the CC issuer on each charge. That's because when the CC charge is pre-approved by the CC issuer, the issuer is on the hook if the CC turns up stolen and the funds are transfered to the retailer account before it's collected from the CC holder. The retailer only has to get a signature from the CC user for the transaction.
With Apple Pay, a one time use token is sent to the CC issuer, the CC issuer decrypt the token to get the CC number and Apple account it was issued to. Then it connects with Apple Server to verify account ID with the iPhone being used. If Apple verifies the info, the CC issuer sends back to the retailer an approval transaction number (if there's enough credit on the CC to cover the charge) and a new token to the user's iPhone. Apple also gets a record of the token issued to that account and iPhone for future verification when it's used. If the iPhone is reported stolen, the token is rendered useless. Even if the thief was able to hack the stolen iPhone to access the token.
The fee that Apple collects is a portion of the fee that the retailer would had to pay the CC card issuer as part of the discount fee, for pre-approving the charges. If Apple Pay is 100% secure and unhackable, that's nearly a 100% profit margin and adds up quickly even if it's a very small portion of each transaction. Apple would have to pay out nothing to retailer to cover unauthorized charges. The only cost would be maintaining the server that processes the transaction. It's almost free money.
Apple server does not have the CC number, only a record of the token, the account it was issued to and when it was used. Apple server keeps track of each token used in order to collect their fee for their part in pre-approving the charge. Plus in case there's any contesting of the charges. Apple may also return a portion of the fee they collect to retailers as an incentive to buy into their Apple Pay. The CC card issuer also gain as the profit margin for the portion of the fee they get from pre-approving Apple Pay charges is also nearly 100%.
Android is totally insecure period. I would never use it for that reason and I certainly would not type my credit card info into an Android phone,. jeez... that would be like putting a target, (pun intended) on my back.
I'm assuming the CC data would be stored locally on the phone in the secure enclave (same as your fingerprint). That way it could work even if there's no network connection available.
no it isn't stored locally, the cc data is stored with Apple , that is what makes it so secure! and no the network connection is from the retailer to the bank thru their network, not from the watch/phone thru the cellular network. The retailer gets an encrypted token and is transferred all the way from the POS thru to the bank., No one sees your cc info at all , or you name or your zip code - nothing. The retailer simply gets an ack back from the bank saying sufficient funds were available to pay for your purchase. This pretty much eliminates fraud at POS, and in transmission. The only way an attacker could compromise this is if they managed to get a hold of the private key at the bank. or hack into the itunes account to get the cc data.
Comments
This is directly from Apple's website.
Sounds like there's a one-time token attached to device identifier.
http://tinyurl.com/prhbjjk
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
Cool.
More on Apple Pay security as it concerns the Apple Watch.
http://tinyurl.com/prhbjjk
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
Cool.
Yes, this was stated by Rene Ritchie on MacBreak Weekly on the day of the reveal. He was the only person I know of who asked that question.
2) That's the assumption. Didn't Cook even say the device generates a one-time use token? Before he stated that I assumed it would be a one-time token per card per device, which is already inherently much safer than a physical card, but it sounded like he meant there is a one-time token per card per device that generates one-time use tokens to send to the payment agent.
So what does the payment agent do with this one-time token generated by the Device Account Number created when the card is added to the device (per Apple)? How does the payment agent translate this token into a usable card number so that the payment can be processed? At the end of the day, a user's account for a specific card needs to be charged with the transaction so somewhere there has to be a "translation" (reverse tokenization, card lookup, or something).
Also, note the article on AI that claims Apple will get a cut of the "swipe fees." I don't think that is possible if Apple's servers never see any part of the transaction.
The more I think about this, the more it looks to me like Apple is bypassing the traditional payment processor all together -- i.e., Apple is not handing this off to First Data or PaymentTech or any other processor -- Apple IS the processor and works directly with Visa/MC/AMEX and the issuing banks as if it were First Data or PaymentTech (or whoever), itself. Maybe Visa/MC/AMEX will issue a token to Apple that Apple associates on its servers with the Device Account Number assigned for a specific card/device pair and when a transaction comes in, the merchant passes this Device Account Number and the transaction security key Apple spoke of, looks up the actual token from Visa/MC/AMEX and pass that token to Visa/MC/AMEX to process, so that the number itself doesn't leave the issuer/network. Apple clearly says in the video that when you take a picture of the card, the card data is uploaded for authentication/verification (and the diagram for the patent in the root of the article these comments are for shows this). That could be when Visa/MC/AMEX also issue Apple a token to associate with it. (This is just logically thinking through things to their conclusion plus public comments, not based on insider knowledge.) If this is the case, Apple does not store the CC data to look up when passed the Device Account Number stuff, but a proxy, the token issued by the network (Visa et al).
More on Apple Pay security as it concerns the Apple Watch.
http://tinyurl.com/prhbjjk
"Apparently, the Apple Watch is going to use a PIN code to authorize Apple Pay, after which the device will remain authorized as long as it remains on your wrist. It accomplishes this using one or more of the sensors on the back of the watch, which can intelligently determine if you’ve taken it off. After you’ve taken it off, the watch is locked out from being to work with Apple Pay until you enter your PIN again."
Cool.
Yes, cool! I was not that excited about the watch until I watched the Jony Ive narrated Apple Watch video... Now, me want (and I don't currently and have not in almost 8 years, wear a watch)
Could it be that Apple handles the transaction the way they do with media purchases?
Could it be that Apple handles the transaction the way they do with media purchases?
Anything is of course possible, but I think not. For media purchases, Apple IS the merchant and goes through a 3rd part processor like First Data or PaymentTech or one of the others. They pay the merchant fees associated with the purchase. They work with most any credit card, regardless of the issuer.
What we know about Apple Pay: works only with certain credit cards -- AMEX, Visa, MC and only those issued by certain banks or issuers (see Apple.com/apple-pay/ I believe for details). According to AI, Apple will be GETTING (a piece of the) merchant fees, not paying them. Apple is not a merchant, but acts more like a processor in some way, facilitating the transaction.
If Apple were a pass through processor (like PayPal or Venmo) then they would be paying fees on every transaction you did with Apple Pay at McDonalds etc. which they would have to add on to the normal merchant fees so it would be more expensive for a merchant to accept Apple Pay, which is a big turn-off. (This is why PayPal cannot offer you as good a rate to process a credit card for you as you can usually get yourself if you have a business [in my experience taking credit cards for 18 years]). Your credit card bill would also say Apple on it plus the merchant, similar to what PayPal charges look like on your card, most likely.
That function has been at the core of my Apple wearable desire from the start, but in regards to the wrist-worn device that will un/lock your Mac and iPhone when the wearable is x-many feet away.
Anything is of course possible, but I think not. For media purchases, Apple IS the merchant and goes through a 3rd part processor like First Data or PaymentTech or one of the others. They pay the merchant fees associated with the purchase. They work with most any credit card, regardless of the issuer.
What we know about Apple Pay: works only with certain credit cards -- AMEX, Visa, MC and only those issued by certain banks or issuers (see Apple.com/apple-pay/ I believe for details). According to AI, Apple will be GETTING (a piece of the) merchant fees, not paying them. Apple is not a merchant, but acts more like a processor in some way, facilitating the transaction.
If Apple were a pass through processor (like PayPal or Venmo) then they would be paying fees on every transaction you did with Apple Pay at McDonalds etc. which they would have to add on to the normal merchant fees so it would be more expensive for a merchant to accept Apple Pay, which is a big turn-off. (This is why PayPal cannot offer you as good a rate to process a credit card for you as you can usually get yourself if you have a business [in my experience taking credit cards for 18 years]). Your credit card bill would also say Apple on it plus the merchant, similar to what PayPal charges look like on your card, most likely.
Here's what I think. Now, when retailers swipe your CC into their reader, they are sending your CC and amount of charge to the CC issuer for pre-approval for that amount. If the card is good and the account has enough to cover the charge, an approval transaction number is sent back to the retailer and the funds are transfered to the retailers account. When a retailer does this, there's a fee for using this pre-approval process. It's added to the discount fee that they have to pay the CC issuer on each charge. That's because when the CC charge is pre-approved by the CC issuer, the issuer is on the hook if the CC turns up stolen and the funds are transfered to the retailer account before it's collected from the CC holder. The retailer only has to get a signature from the CC user for the transaction.
With Apple Pay, a one time use token is sent to the CC issuer, the CC issuer decrypt the token to get the CC number and Apple account it was issued to. Then it connects with Apple Server to verify account ID with the iPhone being used. If Apple verifies the info, the CC issuer sends back to the retailer an approval transaction number (if there's enough credit on the CC to cover the charge) and a new token to the user's iPhone. Apple also gets a record of the token issued to that account and iPhone for future verification when it's used. If the iPhone is reported stolen, the token is rendered useless. Even if the thief was able to hack the stolen iPhone to access the token.
The fee that Apple collects is a portion of the fee that the retailer would had to pay the CC card issuer as part of the discount fee, for pre-approving the charges. If Apple Pay is 100% secure and unhackable, that's nearly a 100% profit margin and adds up quickly even if it's a very small portion of each transaction. Apple would have to pay out nothing to retailer to cover unauthorized charges. The only cost would be maintaining the server that processes the transaction. It's almost free money.
Apple server does not have the CC number, only a record of the token, the account it was issued to and when it was used. Apple server keeps track of each token used in order to collect their fee for their part in pre-approving the charge. Plus in case there's any contesting of the charges. Apple may also return a portion of the fee they collect to retailers as an incentive to buy into their Apple Pay. The CC card issuer also gain as the profit margin for the portion of the fee they get from pre-approving Apple Pay charges is also nearly 100%.
I'm assuming the CC data would be stored locally on the phone in the secure enclave (same as your fingerprint). That way it could work even if there's no network connection available.
no it isn't stored locally, the cc data is stored with Apple , that is what makes it so secure! and no the network connection is from the retailer to the bank thru their network, not from the watch/phone thru the cellular network. The retailer gets an encrypted token and is transferred all the way from the POS thru to the bank., No one sees your cc info at all , or you name or your zip code - nothing. The retailer simply gets an ack back from the bank saying sufficient funds were available to pay for your purchase. This pretty much eliminates fraud at POS, and in transmission. The only way an attacker could compromise this is if they managed to get a hold of the private key at the bank. or hack into the itunes account to get the cc data.