Step 1: You pair the watch with certain iPhones, which will allow you to put the proper representational card numbers on ?Watch's Secure Element that it received from the bank via the iPhone.
Step 2: You use a PIN to authenticate the ?Watch. This stays authenticated until it's removed.
Step 3: You press the button next to the Digital Crown twice to set it up for an ?Pay payment, then accept or deny the payment info that comes on the ?Watch display after it connects with the merchant's NFC terminal.
Cool, thanks for that, so will that work with an iPhone 5 or 5s? I am happy with the iPhone 5 and 5 s for now but really want ?Pay so a (or is that an) ?Watch might be the solution ... he says hoping.
Cool, thanks for that, so will that work with an iPhone 5 or 5s? I am happy with the iPhone 5 and 5 s for now but really want ?Pay so a (or is that an) ?Watch might be the solution ... he says hoping.
Yes and no. You set it up with your iPhone, but then that's it. It's just an independent solution then. You wouldn't even need to have your iPhone on you. For example, lets say you get the Sport version and it's IP67 rated. You take that to Adventure Island in Tampa, put your iPhone in a locker but wear the watch. Now you're hungry and Adventure Island has NFC setup. You can then use your ?Watch to pay for a belly full of nitrates, saturated fats, and simple sugars.
Yes and no. You set it up with your iPhone, but then that's it. It's just an independent solution then. You wouldn't even need to have your iPhone on you. For example, lets say you get the Sport version and it's IP67 rated. You take that to Adventure Island in Tampa, put your iPhone in a locker but wear the watch. Now you're hungry and Adventure Island has NFC setup. You can then use your ?Watch to pay for a belly full of nitrates, saturated fats, and simple sugars.
Very nice write-up Soli. The first time I've seen it explained so clearly.
EDIT: That brings up one question, and you probably know the answer. I remember some mention during an Apple interview of iBeacons, Bluetooth/NFC and the Apple Watch but can't remember the exact context. Would using an Apple Watch (or iPhone with Apple Pay), then make you potentially "indentifiable" to a retailers beacons? If so could that be the sugar to make it palatable to some of the big retailers? Despite losing access to CC's they don't completely lose the ability to better understand (track) their shopper's preferences?
Very nice write-up Soli. The first time I've seen it explained so clearly.
EDIT: That brings up one question, and you probably know the answer. I remember some mention during an Apple interview of iBeacons, Bluetooth/NFC and the Apple Watch but can't remember the exact context. Would using an Apple Watch (or iPhone with Apple Pay), then make you potentially "indentifiable" to a retailers beacons? If so could that be the sugar to make it palatable to some of the big retailers? Despite losing access to CC's they don't completely lose the ability to better understand (track) their shopper's preferences?
No. iBeacons are primarily broadcast only to pass info of interest to customers devices. Some iBeacons can transmit and receive, but that's going to require you to allow your iPhone to respond.
It would be a nightmare if your iPhone responded to and sent back data to every iBeacon you encountered.
Actually, I thought iTunes was the repository for your credit card detail. The card on file with iTunes is the default. Other cards can be added. But all stored in iTunes... at least that is what I thought. Apple does not collect or store any detail about your transactions. But they have you card information, I think.
No. Apple Pay does not store credit card info - it stores an encrypted token in place of your card number. Only the bank can unencrypt the token to figure out the real card information.
Apple has made it possible to quickly add an existing card from iTunes to Appje Pay, but this is a one-way affair (card number from iTunes to Apple Pay) where it gets assigned a token. Think of it this way: you have a Visa set up as Apple Pay. You then decide to add that same Visa to iTunes. You have to manually add it since there's no way to get your card information from Apple Pay to iTunes. Once your Visa in is both systems, neither one (Apple Pay OR iTunes) will even know they both have the same Visa. There's NO information passed between either system.
The ONLY time anything would get shared is the initial setup of adding an existing card in iTunes to Apple Pay. That's only to save time when adding cards. After that nothing else ever gets shared.
No. iBeacons are primarily broadcast only to pass info of interest to customers devices. Some iBeacons can transmit and receive, but that's going to require you to allow your iPhone to respond.
It would be a nightmare if your iPhone responded to and sent back data to every iBeacon you encountered.
At it's essence wouldn't the Apple Watch itself be an expensive iBeacon? Not what I was originally referring to of course..
I blame the retailers for being too cheap to consider customer security as a major priority and the credit companies and their greed from making sure retailers changed terminals on a routine basis with upgrades.
Basiclly credit card companies make extra money but dont provide a sufficient service.
Compatible but not for Apply pay,
the retailers have to upgrade their terminals or the retailer not the Bank/credit card issuer will be responsible for fraudulent charges.
No. Apple Pay does not store credit card info - it stores an encrypted token in place of your card number. Only the bank can unencrypt the token to figure out the real card information.
I don't think that's accurately stated, even though it's essentially true.
The "token" isn't some hash that could ever be converted in the card number and PIN. It's an additional number and PIN that is created by the financial institution that is then associated and stored with your account* number. This is more like iCloud's new feature for creating app-specific passwords that will be able to be used once per app per device for a specific task, like getting access to your email which uses your standard username, but will not allow access to any other services, like Find my iPhone, iCloud.com, etc.
If you create this "token" and then delete it or get a new device, then create it again the bank's servers should create a new random number and PIN to give back to you to store in your iDevice's Secure Element, which is how the new app-specific passwords work with iCloud.com
I don't think that's accurately stated, even though it's essentially true.
The "token" isn't some hash that could ever be converted in the card number and PIN. It's an additional number and PIN that is created by the financial institution that is then associated and stored with your account* number. This is more like iCloud's new feature for creating app-specific passwords that will be able to be used once per app per device for a specific task, like getting access to your email which uses your standard username, but will not allow access to any other services, like Find my iPhone, iCloud.com, etc.
If you create this "token" and then delete it or get a new device, then create it again the bank's servers should create a new random number and PIN to give back to you to store in your iDevice's Secure Element, which is how the new app-specific passwords work with iCloud.com
* Account number, not your debit/CC number.
True, I wasn't clear enough. The token on your iPhone can't be hacked or unencrypted to get your actual card number. It's a number the bank has "associated" with your real card number. However, you can't just have a simple "lookup" where your token is seen by the bank, referenced to your real card number and then processed. Otherwise someone could just get access to the token and use it in place of your real card number to make purchases themselves.
With chip cards, there is a cryptogram in the chip along with your card number. When you insert your card into a terminal, transaction data is encrypted using the data in the chip along with the terminal and sent to the bank. Since the bank "knows" the cryptogram in this chip it's able to decrypt and verify the transaction as being "authentic".
With Apple Pay, the first time you register a card you are sent back a 16 digit "token" that looks like a card number along with a custom cryptogram. These both get stored in the secure element. When you make a payment, the cryptogram in your phone is what's used to encrypt the transaction details. So the secure element in your iPhone acts like the chip on a regular card (except we also have the token card number instead of a real number).
The cryptogram on a chip card is unique to each individual card. Obviously, the cryptogram for your iPhone will also be unique. What we don't know is the complexity of the cryptogram. One thing the A7/A8 processors (with ARMv8) excel at is encryption algorithms (about an 8X performance boost compared to ARMv7). POS terminals are based mainly on ARM processors, but also have secondary encryption processors. With the power available on 64bit iPhones, there is a possibility that it's taken advantage of to use higher-level encryption that would tax the processor in a terminal. Or the possibility the cryptogram used in an iPhone is more complex than the ones used in chip cards.
Where things get a little fuzzy is Touch ID. It appears Touch ID isn't just a "switch" that says "go ahead with the transaction", but rather an additional level of encryption. However, people in the know aren't saying exactly how it works - just that it plays an important role in the transaction itself. What seems probable is that Touch ID represents a more complex "PIN" than the usual 4 digit PIN people use with chip cards.
An even bigger question is the Apple Watch. If Touch ID is actually used as part of the security encryption, then how is this handled by someone wearing an Apple Watch without having an iPhone nearby? And if the 64bit processors are utilizing their considerable encryption power, how does the Apple Watch get around this?
Where things get a little fuzzy is Touch ID. It appears Touch ID isn't just a "switch" that says "go ahead with the transaction", but rather an additional level of encryption. However, people in the know aren't saying exactly how it works - just that it plays an important role in the transaction itself. What seems probable is that Touch ID represents a more complex "PIN" than the usual 4 digit PIN people use with chip cards.
An even bigger question is the Apple Watch. If Touch ID is actually used as part of the security encryption, then how is this handled by someone wearing an Apple Watch without having an iPhone nearby? And if the 64bit processors are utilizing their considerable encryption power, how does the Apple Watch get around this?
Now my head is starting to hurt...
1) You don't have to use Touch ID to access your phone or use ?Pay. There is always the passcode option.
2) Good question about S-series ARM chip. Perhaps it will be 64-bit, but my guess is it won't.
3) I'm also curious if the ?Watch will have its own unique device token associated with your account by the bank, or if it will simply use the same one, for instance, that your iPhone 6 series uses when setting it up. My guess is the iPhone will be a go between when the ?Watch giving it's cryptographic data to the bank and getting the bank to respond with it's unique card number. So the same exact account is unique on every device that uses ?Pay… as well as every time you delete and add that same account to a device.
On both you'll still have to answer whatever questions they want to ask on the POS.
Will these questions be transferred to (and displayed on) the phone so you can respond from your phone - or will you still have to interact with the POS terminal?
Will these questions be transferred to (and displayed on) the phone so you can respond from your phone - or will you still have to interact with the POS terminal?
My guess is that you'd have to interact with the POS screen for any additional info, like signing your name at Walgreens in order to approve some prescripton.
3) I'm also curious if the ?Watch will have its own unique device token associated with your account by the bank, or if it will simply use the same one, for instance, that your iPhone 6 series uses when setting it up. My guess is the iPhone will be a go between when the ?Watch giving it's cryptographic data to the bank and getting the bank to respond with it's unique card number. So the same exact account is unique on every device that uses ?Pay… as well as every time you delete and add that same account to a device.
I think CPU capabilities are going to be pretty insignificant for encrypting, decrypting the small amount of data that is actually exchanged during an Apple Pay transaction. It's really not all that taxing to to encrypt a few kilobytes of data.
I would also be willing to bet that each device you have associated with your card will have its own unique token. That way if you lose one device, the device that was lost/stolen can be deactivated/suspended yet all of your other devices will continue to work.
One point I think a lot of people don't understand is that the iPhone does not communicate with the card issuer (bank) during an Apple Pay transaction. It only communicates with the POS terminal and the POS terminal handles the conversation with your bank. One of the other things worth noting regarding Apple Pay is that this is not a system that Apple invented on their own. It is based on a new "standard" for mobile payments and Apple is the first to implement this new standard.
I think CPU capabilities are going to be pretty insignificant for encrypting, decrypting the small amount of data that is actually exchanged during an Apple Pay transaction. It's really not all that taxing to to encrypt a few kilobytes of data.
I agree, but I do wonder if there will be a noticeable time diffference between the ?Watch and iPhone because of the vast performance differences, despite the extremely minute payload that will need to be decrypted.
One point I think a lot of people don't understand is that the iPhone does not communicate with the card issuer (bank) during an Apple Pay transaction. It only communicates with the POS terminal and the POS terminal handles the conversation with your bank.
Sure. The same way your debit/CC gets read by the POS terminal which then contacts your financial agency.
One of the other things worth noting regarding Apple Pay is that this is not a system that Apple invented on their own. It is based on a new "standard" for mobile payments and Apple is the first to implement this new standard.
1) I haven't read anything about that. The only industry standard I'm aware of is the NFC communication.
2) Is Apple the the first to implement it or the first to implement it because they designed the end-to-end solution? Could be like mini-DisplayPort where Apple designed it, gave it to Vesa to include in their standard as a free license, which also got adopted by Intel's Thunderbolt port interface standard.
Oh good, another US only feature about to roll out. Maybe we in the UK could get iTunes Radio sometime soon. I am optimistic that apple pay will come here soon because we already have contact-less credit cards and readers are becoming commonplace so I guess it's just up to our banks to do the deal with Apple.
In Canada, one of our big 5 banks has announced that it will be "at least a year" before Apple Pay could make it to Canada - with emphasis on the "at LEAST". Of course, slow international rollout of features/capabilities is not something limited to Apple. In Canada, Google has been telling us for more than 10 years now that "Google Voice" will be "coming soon". I stopped holding my breath on that about 8 years ago. Here's hoping that Apple moves a lot faster than that with Apple Pay!
I agree, but I do wonder if there will be a noticeable time diffference between the ?Watch and iPhone because of the vast performance differences, despite the extremely minute payload that will need to be decrypted.
As I think about it a little more - is there anything at all that the phone would need to encrypt or decrypt "on the fly"? I would assume that the token is already encrypted while stored in the secure element, so couldn't the pre-encrypted data just be passed directly to the POS device for relay to the card issuer?
2) Is Apple the the first to implement it or the first to implement it because they designed the end-to-end solution? Could be like mini-DisplayPort where Apple designed it, gave it to Vesa to include in their standard as a free license, which also got adopted by Intel's Thunderbolt port interface standard.
I had a quick look for the article I read this in but couldn't find it. I'll look again after a few hours sleep - but I had the impression that the core of the Apple Pay system was the first implementation of a new industry standard - the NFC portion of it wasn't called out - I guess because it's already covered by a standard - but the details surrounding the tokenization of the card number and the obfuscation of the actual card number.
As I think about it a little more - is there anything at all that the phone would need to encrypt or decrypt "on the fly"? I would assume that the token is already encrypted while stored in the secure element, so couldn't the pre-encrypted data just be passed directly to the POS device for relay to the card issuer?
From the way I understand it the Secure Element is encrypted on each device so that would need to be decrypted to get the "token" value. That value is then sent to the POS terminal which is then forwarded to the bank, as you state, and the bank then checks that representational card value plus PIN as a 2-point check for the sale.
It's late for me and I'm exhausted but I don't think the banks will be sleeping the same encrypted data on the Secure Element on their servers.
I had a quick look for the article I read this in but couldn't find it. I'll look again after a few hours sleep - but I had the impression that the core of the Apple Pay system was the first implementation of a new industry standard - the NFC portion of it wasn't called out - I guess because it's already covered by a standard - but the details surrounding the tokenization of the card number and the obfuscation of the actual card number.
It very could be and definitely should be, but I'd bet Apple is at the heart of it. Once a bank gets setup to create multiple representational card numbers per account that is platform and OEM agnostic. Apple can't control that. Then there is the Secure Element, which Apple does own, but there is zero reason any other OEMs can't offer a similar, secure solution which makes it more secure than storing your card data in the device's regular NAND.
The beauty I see in ?Pay is that this isn't a logistical puzzle that no one else can utilize. In fact, I expect MS to move quickly to offer something similar to help pull in more marketshare at the expense of Android because they do have control over both the HW and OS with the Lumia.
1) I haven't read anything about that. The only industry standard I'm aware of is the NFC communication.
2) Is Apple the the first to implement it or the first to implement it because they designed the end-to-end solution? Could be like mini-DisplayPort where Apple designed it, gave it to Vesa to include in their standard as a free license, which also got adopted by Intel's Thunderbolt port interface standard.
One really smart move for Apple was getting TouchID right before moving on Apple Pay. While Apple may not have any lock on mobile payments and tokenization the fact that Touch ID helps ensure you are who you say you are makes Apple's implementation both unique and more profitable for the near future.
From the way I understand it the Secure Element is encrypted on each device so that would need to be decrypted to get the "token" value. That value is then sent to the POS terminal which is then forwarded to the bank, as you state, and the bank then checks that representational card value plus PIN as a 2-point check for the sale.
It's late for me and I'm exhausted but I don't think the banks will be sleeping the same encrypted data on the Secure Element on their servers.
It very could be and definitely should be, but I'd bet Apple is at the heart of it. Once a bank gets setup to create multiple representational card numbers per account that is platform and OEM agnostic. Apple can't control that. Then there is the Secure Element, which Apple does own, but there is zero reason any other OEMs can't offer a similar, secure solution which makes it more secure than storing your card data in the device's regular NAND.
The beauty I see in ?Pay is that this isn't a logistical puzzle that no one else can utilize. In fact, I expect MS to move quickly to offer something similar to help pull in more marketshare at the expense of Android because they do have control over both the HW and OS with the Lumia.
Do you see any reason why Apple Pay would or would not be compatible with pre-paid Visa and Mastercards?
I actually hope they extend the Apple Pay system (after they get the initial kinks worked out) with something similar to the new Family Sharing capabilities in iOS 8 - specifically, I'd like to be able to configure my son's device with MY credit card BUT have it prompt ME for approval whenever he tries to use it - that way we're prepared or true emergencies but I can still monitor and approve/deny other spendjg requests.
Comments
Cool, thanks for that, so will that work with an iPhone 5 or 5s? I am happy with the iPhone 5 and 5 s for now but really want ?Pay so a (or is that an) ?Watch might be the solution ... he says hoping.
Yes and no. You set it up with your iPhone, but then that's it. It's just an independent solution then. You wouldn't even need to have your iPhone on you. For example, lets say you get the Sport version and it's IP67 rated. You take that to Adventure Island in Tampa, put your iPhone in a locker but wear the watch. Now you're hungry and Adventure Island has NFC setup. You can then use your ?Watch to pay for a belly full of nitrates, saturated fats, and simple sugars.
EDIT: That brings up one question, and you probably know the answer. I remember some mention during an Apple interview of iBeacons, Bluetooth/NFC and the Apple Watch but can't remember the exact context. Would using an Apple Watch (or iPhone with Apple Pay), then make you potentially "indentifiable" to a retailers beacons? If so could that be the sugar to make it palatable to some of the big retailers? Despite losing access to CC's they don't completely lose the ability to better understand (track) their shopper's preferences?
No. iBeacons are primarily broadcast only to pass info of interest to customers devices. Some iBeacons can transmit and receive, but that's going to require you to allow your iPhone to respond.
It would be a nightmare if your iPhone responded to and sent back data to every iBeacon you encountered.
No. Apple Pay does not store credit card info - it stores an encrypted token in place of your card number. Only the bank can unencrypt the token to figure out the real card information.
Apple has made it possible to quickly add an existing card from iTunes to Appje Pay, but this is a one-way affair (card number from iTunes to Apple Pay) where it gets assigned a token. Think of it this way: you have a Visa set up as Apple Pay. You then decide to add that same Visa to iTunes. You have to manually add it since there's no way to get your card information from Apple Pay to iTunes. Once your Visa in is both systems, neither one (Apple Pay OR iTunes) will even know they both have the same Visa. There's NO information passed between either system.
The ONLY time anything would get shared is the initial setup of adding an existing card in iTunes to Apple Pay. That's only to save time when adding cards. After that nothing else ever gets shared.
Compatible but not for Apply pay,
the retailers have to upgrade their terminals or the retailer not the Bank/credit card issuer will be responsible for fraudulent charges.
I don't think that's accurately stated, even though it's essentially true.
The "token" isn't some hash that could ever be converted in the card number and PIN. It's an additional number and PIN that is created by the financial institution that is then associated and stored with your account* number. This is more like iCloud's new feature for creating app-specific passwords that will be able to be used once per app per device for a specific task, like getting access to your email which uses your standard username, but will not allow access to any other services, like Find my iPhone, iCloud.com, etc.
If you create this "token" and then delete it or get a new device, then create it again the bank's servers should create a new random number and PIN to give back to you to store in your iDevice's Secure Element, which is how the new app-specific passwords work with iCloud.com
* Account number, not your debit/CC number.
What about the 6 Plus?
Damn! Left out again! The 6 gets all the perks.
I don't think that's accurately stated, even though it's essentially true.
The "token" isn't some hash that could ever be converted in the card number and PIN. It's an additional number and PIN that is created by the financial institution that is then associated and stored with your account* number. This is more like iCloud's new feature for creating app-specific passwords that will be able to be used once per app per device for a specific task, like getting access to your email which uses your standard username, but will not allow access to any other services, like Find my iPhone, iCloud.com, etc.
If you create this "token" and then delete it or get a new device, then create it again the bank's servers should create a new random number and PIN to give back to you to store in your iDevice's Secure Element, which is how the new app-specific passwords work with iCloud.com
* Account number, not your debit/CC number.
True, I wasn't clear enough. The token on your iPhone can't be hacked or unencrypted to get your actual card number. It's a number the bank has "associated" with your real card number. However, you can't just have a simple "lookup" where your token is seen by the bank, referenced to your real card number and then processed. Otherwise someone could just get access to the token and use it in place of your real card number to make purchases themselves.
With chip cards, there is a cryptogram in the chip along with your card number. When you insert your card into a terminal, transaction data is encrypted using the data in the chip along with the terminal and sent to the bank. Since the bank "knows" the cryptogram in this chip it's able to decrypt and verify the transaction as being "authentic".
With Apple Pay, the first time you register a card you are sent back a 16 digit "token" that looks like a card number along with a custom cryptogram. These both get stored in the secure element. When you make a payment, the cryptogram in your phone is what's used to encrypt the transaction details. So the secure element in your iPhone acts like the chip on a regular card (except we also have the token card number instead of a real number).
The cryptogram on a chip card is unique to each individual card. Obviously, the cryptogram for your iPhone will also be unique. What we don't know is the complexity of the cryptogram. One thing the A7/A8 processors (with ARMv8) excel at is encryption algorithms (about an 8X performance boost compared to ARMv7). POS terminals are based mainly on ARM processors, but also have secondary encryption processors. With the power available on 64bit iPhones, there is a possibility that it's taken advantage of to use higher-level encryption that would tax the processor in a terminal. Or the possibility the cryptogram used in an iPhone is more complex than the ones used in chip cards.
Where things get a little fuzzy is Touch ID. It appears Touch ID isn't just a "switch" that says "go ahead with the transaction", but rather an additional level of encryption. However, people in the know aren't saying exactly how it works - just that it plays an important role in the transaction itself. What seems probable is that Touch ID represents a more complex "PIN" than the usual 4 digit PIN people use with chip cards.
An even bigger question is the Apple Watch. If Touch ID is actually used as part of the security encryption, then how is this handled by someone wearing an Apple Watch without having an iPhone nearby? And if the 64bit processors are utilizing their considerable encryption power, how does the Apple Watch get around this?
Now my head is starting to hurt...
1) You don't have to use Touch ID to access your phone or use ?Pay. There is always the passcode option.
2) Good question about S-series ARM chip. Perhaps it will be 64-bit, but my guess is it won't.
3) I'm also curious if the ?Watch will have its own unique device token associated with your account by the bank, or if it will simply use the same one, for instance, that your iPhone 6 series uses when setting it up. My guess is the iPhone will be a go between when the ?Watch giving it's cryptographic data to the bank and getting the bank to respond with it's unique card number. So the same exact account is unique on every device that uses ?Pay… as well as every time you delete and add that same account to a device.
Will these questions be transferred to (and displayed on) the phone so you can respond from your phone - or will you still have to interact with the POS terminal?
My guess is that you'd have to interact with the POS screen for any additional info, like signing your name at Walgreens in order to approve some prescripton.
I think CPU capabilities are going to be pretty insignificant for encrypting, decrypting the small amount of data that is actually exchanged during an Apple Pay transaction. It's really not all that taxing to to encrypt a few kilobytes of data.
I would also be willing to bet that each device you have associated with your card will have its own unique token. That way if you lose one device, the device that was lost/stolen can be deactivated/suspended yet all of your other devices will continue to work.
One point I think a lot of people don't understand is that the iPhone does not communicate with the card issuer (bank) during an Apple Pay transaction. It only communicates with the POS terminal and the POS terminal handles the conversation with your bank. One of the other things worth noting regarding Apple Pay is that this is not a system that Apple invented on their own. It is based on a new "standard" for mobile payments and Apple is the first to implement this new standard.
I agree, but I do wonder if there will be a noticeable time diffference between the ?Watch and iPhone because of the vast performance differences, despite the extremely minute payload that will need to be decrypted.
Sure. The same way your debit/CC gets read by the POS terminal which then contacts your financial agency.
1) I haven't read anything about that. The only industry standard I'm aware of is the NFC communication.
2) Is Apple the the first to implement it or the first to implement it because they designed the end-to-end solution? Could be like mini-DisplayPort where Apple designed it, gave it to Vesa to include in their standard as a free license, which also got adopted by Intel's Thunderbolt port interface standard.
In Canada, one of our big 5 banks has announced that it will be "at least a year" before Apple Pay could make it to Canada - with emphasis on the "at LEAST". Of course, slow international rollout of features/capabilities is not something limited to Apple. In Canada, Google has been telling us for more than 10 years now that "Google Voice" will be "coming soon". I stopped holding my breath on that about 8 years ago. Here's hoping that Apple moves a lot faster than that with Apple Pay!
As I think about it a little more - is there anything at all that the phone would need to encrypt or decrypt "on the fly"? I would assume that the token is already encrypted while stored in the secure element, so couldn't the pre-encrypted data just be passed directly to the POS device for relay to the card issuer?
I had a quick look for the article I read this in but couldn't find it. I'll look again after a few hours sleep - but I had the impression that the core of the Apple Pay system was the first implementation of a new industry standard - the NFC portion of it wasn't called out - I guess because it's already covered by a standard - but the details surrounding the tokenization of the card number and the obfuscation of the actual card number.
From the way I understand it the Secure Element is encrypted on each device so that would need to be decrypted to get the "token" value. That value is then sent to the POS terminal which is then forwarded to the bank, as you state, and the bank then checks that representational card value plus PIN as a 2-point check for the sale.
It's late for me and I'm exhausted but I don't think the banks will be sleeping the same encrypted data on the Secure Element on their servers.
It very could be and definitely should be, but I'd bet Apple is at the heart of it. Once a bank gets setup to create multiple representational card numbers per account that is platform and OEM agnostic. Apple can't control that. Then there is the Secure Element, which Apple does own, but there is zero reason any other OEMs can't offer a similar, secure solution which makes it more secure than storing your card data in the device's regular NAND.
The beauty I see in ?Pay is that this isn't a logistical puzzle that no one else can utilize. In fact, I expect MS to move quickly to offer something similar to help pull in more marketshare at the expense of Android because they do have control over both the HW and OS with the Lumia.
I think Square may have started implementing tokens last year (Square Wallet), using tech from Braintree, but probably not the first to do so. In fact Braintree looks to be inserting themselves into the Apple Pay stream.
https://www.braintreepayments.com/?partner_source=US_DT_SEA_GGL_TXT_RES_DEV_CPC_GW_YBR_m*e_c*38049420827_k*braintree_d*Braintree-Branded_g*[braintree]_f*c_p*1t1&gclid=CjwKEAjw8O2hBRDKur2lseLW6C8SJAC-r1J3D4dX1DIq8rtxZfzW3zTme0QHXPTYtL2ScBDCi0VnfBoC4ZPw_wcB
One really smart move for Apple was getting TouchID right before moving on Apple Pay. While Apple may not have any lock on mobile payments and tokenization the fact that Touch ID helps ensure you are who you say you are makes Apple's implementation both unique and more profitable for the near future.
EDIT: There's a rally good discussion of Apple Pay and the methods and standards it likely uses here:
http://pomcor.com/2014/09/20/apple-pay-must-be-using-the-mag-stripe-mode-of-the-emv-contactless-specifications/
Do you see any reason why Apple Pay would or would not be compatible with pre-paid Visa and Mastercards?
I actually hope they extend the Apple Pay system (after they get the initial kinks worked out) with something similar to the new Family Sharing capabilities in iOS 8 - specifically, I'd like to be able to configure my son's device with MY credit card BUT have it prompt ME for approval whenever he tries to use it - that way we're prepared or true emergencies but I can still monitor and approve/deny other spendjg requests.