If the token used is relatively short, it could be manually entered in a text field rather than been exchanged by NFC.
To me that means it needs an entirely unique token for each site, which is cumbersome, otherwise you can just input your CC number. You could do a unique token that is the length of a CC number but still representational of your original number (think: email alias) which will protect you from losing the original number and having to redo your ?Pay cards again, but that's still really solving the issue of complexity or security.
I don't think you understand.
The token references a single credit card/Bank.
When you ApplePay, the device generates a token which references the above plus a one-time dynamic security code and time stamp.
Even if you did store the token on a web site it would be worthless ...
That's the whole point!
The token is created, ad hoc, by the act of making that specific payment (some with TouchID, others without).
When you ApplePay, the device generates a token which references the above plus a one-time dynamic security code and time stamp.
Even if you did store the token on a web site it would be worthless ...
That's the whole point!
The token is created, ad hoc, by the act of making that specific payment (some with TouchID, others without).
Are you saying that's how the standard ?Pay on the iPhone 6 will work? If so, then how do you make a payment if your device isn't online? It sounds like ?Pay creates a one-time token per card per device that is synced with the bank, not a one-time USE token that needs to be synced from the device end every time to get the token.
The reason that Walmart and Best Buy have not joined is that they want to be in position to tell the customer which card to use- the one with a lower discount rate. With apple pay, the retailers have to accept whatever the iPhone user has designated on their iPhone.
They want you to use it as a Debit Card so there is no fees on their end. They got called out a few years ago for refusing credit if the MC was a MC Debit. The terms of MC says they must accept as credit if user wants to do it that way. With Applepay, it will be straight credit and they don't have the option to push the user into a debit transaction vs a credit transaction. My opinion on one possible reason.
As I understand it, ApplePay supports debit cards -- it just does it conveniently and securely at lower cost to the customer, merchant and transaction processor.
"You sound like some elitist snob. Wal-mart sells the iPhone and other Apple products, so clearly not everyone who shops there are poor, on welfare, or beneath you as you suggest. This is why some do not like Apple supporters, some come across as pompous. Is Best Buy for the poor also, or just conveniently left them out to make a misguided comment?"
He's an "elitist snob"? Said like a true Walmart devotee. The demographic profile of the average Walmart customer doesn't come remotely close to that of the average Apple consumer. That you choose to take personal offense to his satire seems to indicate you think he is talking about you. I guess he is.
it can be used with iPhones as demoed (iPhone supplies the TouchID and AppleWatch supplies the NFC connection).
If no NFC POST is available, the AppleWatch can use BLE/WiFi to communicate with a non-NFC POST.
On non-NFC Apple devices (current iPhones, iPads, AppleTVs, Macs, MacBooks) it uses Handoff to communicate with the AppleWatch.
Just as iCloud/Keychain can securely generate, store, retrieve and fill in UserIDs and Passwords -- it will be able to handle ApplePay tokens if no TouchID device is available.
As to the latter -- I think that Apple will offer a free iCloud account and supporting software for all popular platforms and devices -- it will just work better on Apples hardware and software.
That sounds horrible to me. If I'm making a purchase in my browser I want to complete it in the browser. At least with sites that take PayPal it opens up a portal that connects to their back end. I don't want to have to use multiple HW devices in order to make a simple purchase online.
The above is a transitional solution.
Look at the last point above -- When I go to any web site on my Macs or iDevices, if I have so chosen, the browser fills in the UserID and Password -- i merely tap or click the login button. What's this diff??
You go to check out, select the cc service (not the card number) and the browser/icloud generates an ad hoc token token and file it in -- You click Pay!
When you ApplePay, the device generates a token which references the above plus a one-time dynamic security code and time stamp.
Even if you did store the token on a web site it would be worthless ...
That's the whole point!
The token is created, ad hoc, by the act of making that specific payment (some with TouchID, others without).
Are you saying that's how the standard ?Pay on the iPhone 6 will work? If so, then how do you make a payment if your device isn't online? It sounds like ?Pay creates a one-time token per card per device that is synced with the bank, not a one-time USE token that needs to be synced from the device end every time to get the token.
I don't understand " then how do you make a payment if your device isn't online? ",
Obviously you can't pay with ApplePay if you don't have the device (the AppleWatch, at a minimum) online ... Just as you can't pay with a credit card if you don't have the credit card ... or cash, if you don't have the cash ...
As I understand it, ApplePay has an encrypted token that consists of (at least):
The DAC (DAN, or somesuch) is one-time generated by the Bank (when you add your cc to ApplePay). It represents your cc account -- it contains no data about you or your credit card (that's between your bank, you and your creator)..
The Dynamic security code is generated through the act of paying (I suspect it uses an algorithm known only to ApplePay and the bank.
The Timestamp limits the the time for which the token is valid -- say plus or minus n seconds -- depending on credit ca®d traffic.
So, if you have an AppleWatch or NFC TouchID device -- it can communicate with an NFC POST. If no NFC POST is available, your device can display the token which could be BLE/WiFi transmitted or hand keyed into whatever POST the merchant has available.
If no POST is available ... "The Store is Offline -- we'll be back real soon now!"
My guess is customer tracking. If they take Apple Pay, they do not have the CC information, address, and name for any transactions, so they cannot slam you with stupid offers all the time. If you use your CC, they have a history of purchases, and can use that to send you marketing materials.
You're credit card does not contain your address and is not transmitted during a sale. There are laws surrounding what you can and can't keep in regards to credit card info. I think it's much more likely that Wal-Mart isn't taking Apple Pay because it would require an overhaul of their equipment and Wal-Mart probably already has a game plan in place for these types of payments later down the road.
I don't understand " then how do you make a payment if your device isn't online? ",
Obviously you can't pay with ApplePay if you don't have the device (the AppleWatch, at a minimum) online ... Just as you can't pay with a credit card if you don't have the credit card ... or cash, if you don't have the cash ...
As I understand it, ApplePay has an encrypted token that consists of (at least):
The DAC (DAN, or somesuch) is one-time generated by the Bank (when you add your cc to ApplePay). It represents your cc account -- it contains no data about you or your credit card (that's between your bank, you and your creator)..
The Dynamic security code is generated through the act of paying (I suspect it uses an algorithm known only to ApplePay and the bank.
The Timestamp limits the the time for which the token is valid -- say plus or minus n seconds -- depending on credit ca®d traffic.
So, if you have an AppleWatch or NFC TouchID device -- it can communicate with an NFC POST. If no NFC POST is available, your device can display the token which could be BLE/WiFi transmitted or hand keyed into whatever POST the merchant has available.
If no POST is available ... "The Store is Offline -- we'll be back real soon now!"
IOW SOL, UR SOL
If your ApplePay device also has to be online, not just the mercahnt's syatem, when making a payment then that is a horrible system that will not stop CC and/or cash from being carried.
Yes but my question "alongside a transaction-specific dynamic security code is used to process your payment" --- to generate this DYNAMIC security code, does your iPhone need an Internet connection? Seems pretty clear it will. Hence my post #18 above.
I am pretty sure that when you add a new card into Passbook, you will go through an authentication process to ensure that this card is yours. i.e. you can't just snap a pic of your friends card and add it to Passbook/Apple Pay. That process will require an internet connection and will be a highly encrypted connection. In turn the DAN "Device Account Number" would be created on the device and transmitted to your issuing bank, since the bank would obviously need that number in order to link transactions to your normal credit card number. The Dynamic Security code's algorithm is probably Apple Proprietary and supplied to the issuing banks. Thus, if you think in terms of Google Authentication, Secure ID, etc both sides have the algorithm used to create those unique codes and and probably sync'd by using the same Clock to create the DYMAMIC part. Or, this is completely done on the Apple device itself. So, if Apple supplies the issuing banks software that can interpret the Dynamic number as being valid, its probably based on a hash of particulars related to the card transaction itself (like Clock, Transaction Amount, Credit Card Holder, Issuing Bank, Merchant, etc), which could be decrypted on the issuing banks end via the purchase info. Thus, no internet connection is needed at all. Data sent via phone into the NFC terminal, which is connected to the internet or phone line to the issuing bank and verify's its valid and processes the transaction.
I thought I read, this whole ID "DAN + DYNAMIC" is very long. Not the length of a typical card number for high security
At that point you can then ditch the physical card altogether.
I imagine the image of the CC stored in your iPhone will show the front and the back of the card. I do a lot of shopping online while away from home either at the office or while traveling which clearly does not support NFC so I would need to see the reverse of the card to get the CCV # before I could actually ditch the physical card.
I don't understand " then how do you make a payment if your device isn't online? ",
Obviously you can't pay with ApplePay if you don't have the device (the AppleWatch, at a minimum) online ... Just as you can't pay with a credit card if you don't have the credit card ... or cash, if you don't have the cash ...
As I understand it, ApplePay has an encrypted token that consists of (at least):
The DAC (DAN, or somesuch) is one-time generated by the Bank (when you add your cc to ApplePay). It represents your cc account -- it contains no data about you or your credit card (that's between your bank, you and your creator)..
The Dynamic security code is generated through the act of paying (I suspect it uses an algorithm known only to ApplePay and the bank.
The Timestamp limits the the time for which the token is valid -- say plus or minus n seconds -- depending on credit ca®d traffic.
So, if you have an AppleWatch or NFC TouchID device -- it can communicate with an NFC POST. If no NFC POST is available, your device can display the token which could be BLE/WiFi transmitted or hand keyed into whatever POST the merchant has available.
If no POST is available ... "The Store is Offline -- we'll be back real soon now!"
IOW SOL, UR SOL
If your ApplePay device also has to be online, not just the mercahnt's syatem, when making a payment then that is a horrible system that will not stop CC and/or cash from being carried.
By "online" do you mean online to the Internet.
If so, that would be horrible ...
But, think about it:
case #1 you just wave your iPhone 6 as demoed (I bet the iPhone could even be in Airplane mode with all radios disabled except NFC).
case #2 when you put on your iWatch -- it contacts your iPhone and gets TouchID enabled until the AppleWatch is taken off (or until overtly disabled).
In both of the above cases, the ApplePay device (AppleWatch or iPhone 6) could communicate with the POST through NFC, BLE or WiFi.
There is no need for either device to be online to the Internet -- The POST receives the ApplePay data and the POST communicates with the bank (passes the token) over the Internet -- and receives an approval or not.
When you think about it -- giving someone your credit card (or credit card info) is [potentially] worse than just handing over your wallet.
How does it work at a restaurant? In the CC world, you can make a pending transaction without executing it. Normally, the restaurant verifies the payment first but amends it after the client adds the gratuity. Can Apple Pay do that?
If your ApplePay device also has to be online, not just the mercahnt's syatem, when making a payment then that is a horrible system that will not stop CC and/or cash from being carried.
I concur with all that Dick Applebaum detailed. The token will probably be encrypted by a public key that will authenticate the transaction (maybe supplied by the device in the preliminary phase). In case of an HTTPS transaction, the encryption is pointless since the link is secure.
In case of an HTTPS transaction, the encryption is pointless since the link is secure.
If you are shopping online, you have no idea whether the merchant is storing your card info or not. Some just pass it through to the gateway and some store to later be stolen by hackers. In either case they have your name and address, unlike shopping at a local store with Apple Pay.
How does it work at a restaurant? In the CC world, you can make a pending transaction without executing it. Normally, the restaurant verifies the payment first but amends it after the client adds the gratuity. Can Apple Pay do that?
If the terminal is offline (I mean, the device of the merchant) when the transaction is performed, then you cannot verify the transaction, not until the terminal is put back on its base, or whatever, and connected to the network.
I concur with all that Dick Applebaum detailed. The token will probably be encrypted by a public key that will authenticate the transaction (maybe supplied by the device in the preliminary phase). In case of an HTTPS transaction, the encryption is pointless since the link is secure.
If you are shopping online, you have no idea whether the merchant is storing your card info or not. Some just pass it through to the gateway and some store to later be stolen by hackers. In either case they have your name and address, unlike shopping at a local store with Apple Pay.
What I meant is that if you shop online, you can just use the plain token the iPhone gives you (without encrypting it) because the link to the merchant is secure and the token is obsoleted once it is used.
If the terminal is offline (I mean, the device of the merchant) when the transaction is performed, then you cannot verify the transaction, not until the terminal is put back on its base, or whatever, and connected to the network.
I'm not understanding your message.
I'm not sure how typical restaurant payments are conducted in Europe since I never took notice when I was there. We only ate at small lunch spots where there was no gratuity and we paid in cash, except for a few times when our hosts would invite us out for dinner and then it usually ended up where the host and the restaurant owner would politely argue over the tab. The owner refusing to accept payment from his friend but the friend insisting on paying.
Anyway in the US, typically after the meal, one first receives the bill, then after review, the guest offers their credit card. The waiter takes the card to the cashier who issues and verifies a pending credit card transaction for the exact amount of the bill. When the waiter returns with the card and the receipt, the guest adds the gratuity and signs the merchant's copy of the receipt. Then the waiter goes back to the cashier who brings up the pending transaction, amends the new total and executes the final charges.
My question, is the sequence I described possible with Apple Pay? Perhaps the waiter will bring a wireless device to your table where you can enter the amount of the gratuity and pay the entire amount at once. I remember there was a credit card reader terminal manufacturer in the US that proposed something like that for restaurants but I have never seen one.
I thought Apple libcrypto was immune to HeartBleed because it was not based on the OpenBSD code.
1) You specifically mentioned encryption is poiness because HTTPS was being used, hence my comment.
2) Apple not using that unsecured version of SSL doesn't mean there aren't other security issues so never assume that an acronym is impenetrable because one hole was plugged or a vendor isn't accepted by a particular hole.
Comments
I don't think you understand.
The token references a single credit card/Bank.
When you ApplePay, the device generates a token which references the above plus a one-time dynamic security code and time stamp.
Even if you did store the token on a web site it would be worthless ...
That's the whole point!
The token is created, ad hoc, by the act of making that specific payment (some with TouchID, others without).
Are you saying that's how the standard ?Pay on the iPhone 6 will work? If so, then how do you make a payment if your device isn't online? It sounds like ?Pay creates a one-time token per card per device that is synced with the bank, not a one-time USE token that needs to be synced from the device end every time to get the token.
As I understand it, ApplePay supports debit cards -- it just does it conveniently and securely at lower cost to the customer, merchant and transaction processor.
He's an "elitist snob"? Said like a true Walmart devotee. The demographic profile of the average Walmart customer doesn't come remotely close to that of the average Apple consumer. That you choose to take personal offense to his satire seems to indicate you think he is talking about you. I guess he is.
The above is a transitional solution.
Look at the last point above -- When I go to any web site on my Macs or iDevices, if I have so chosen, the browser fills in the UserID and Password -- i merely tap or click the login button. What's this diff??
You go to check out, select the cc service (not the card number) and the browser/icloud generates an ad hoc token token and file it in -- You click Pay!
I don't understand " then how do you make a payment if your device isn't online? ",
Obviously you can't pay with ApplePay if you don't have the device (the AppleWatch, at a minimum) online ... Just as you can't pay with a credit card if you don't have the credit card ... or cash, if you don't have the cash ...
As I understand it, ApplePay has an encrypted token that consists of (at least):
The DAC (DAN, or somesuch) is one-time generated by the Bank (when you add your cc to ApplePay). It represents your cc account -- it contains no data about you or your credit card (that's between your bank, you and your creator)..
The Dynamic security code is generated through the act of paying (I suspect it uses an algorithm known only to ApplePay and the bank.
The Timestamp limits the the time for which the token is valid -- say plus or minus n seconds -- depending on credit ca®d traffic.
So, if you have an AppleWatch or NFC TouchID device -- it can communicate with an NFC POST. If no NFC POST is available, your device can display the token which could be BLE/WiFi transmitted or hand keyed into whatever POST the merchant has available.
If no POST is available ... "The Store is Offline -- we'll be back real soon now!"
IOW SOL, UR SOL
My guess is customer tracking. If they take Apple Pay, they do not have the CC information, address, and name for any transactions, so they cannot slam you with stupid offers all the time. If you use your CC, they have a history of purchases, and can use that to send you marketing materials.
You're credit card does not contain your address and is not transmitted during a sale. There are laws surrounding what you can and can't keep in regards to credit card info. I think it's much more likely that Wal-Mart isn't taking Apple Pay because it would require an overhaul of their equipment and Wal-Mart probably already has a game plan in place for these types of payments later down the road.
If your ApplePay device also has to be online, not just the mercahnt's syatem, when making a payment then that is a horrible system that will not stop CC and/or cash from being carried.
Yes but my question "alongside a transaction-specific dynamic security code is used to process your payment" --- to generate this DYNAMIC security code, does your iPhone need an Internet connection? Seems pretty clear it will. Hence my post #18 above.
I am pretty sure that when you add a new card into Passbook, you will go through an authentication process to ensure that this card is yours. i.e. you can't just snap a pic of your friends card and add it to Passbook/Apple Pay. That process will require an internet connection and will be a highly encrypted connection. In turn the DAN "Device Account Number" would be created on the device and transmitted to your issuing bank, since the bank would obviously need that number in order to link transactions to your normal credit card number. The Dynamic Security code's algorithm is probably Apple Proprietary and supplied to the issuing banks. Thus, if you think in terms of Google Authentication, Secure ID, etc both sides have the algorithm used to create those unique codes and and probably sync'd by using the same Clock to create the DYMAMIC part. Or, this is completely done on the Apple device itself. So, if Apple supplies the issuing banks software that can interpret the Dynamic number as being valid, its probably based on a hash of particulars related to the card transaction itself (like Clock, Transaction Amount, Credit Card Holder, Issuing Bank, Merchant, etc), which could be decrypted on the issuing banks end via the purchase info. Thus, no internet connection is needed at all. Data sent via phone into the NFC terminal, which is connected to the internet or phone line to the issuing bank and verify's its valid and processes the transaction.
I thought I read, this whole ID "DAN + DYNAMIC" is very long. Not the length of a typical card number for high security
At that point you can then ditch the physical card altogether.
I imagine the image of the CC stored in your iPhone will show the front and the back of the card. I do a lot of shopping online while away from home either at the office or while traveling which clearly does not support NFC so I would need to see the reverse of the card to get the CCV # before I could actually ditch the physical card.
By "online" do you mean online to the Internet.
If so, that would be horrible ...
But, think about it:
case #1 you just wave your iPhone 6 as demoed (I bet the iPhone could even be in Airplane mode with all radios disabled except NFC).
case #2 when you put on your iWatch -- it contacts your iPhone and gets TouchID enabled until the AppleWatch is taken off (or until overtly disabled).
In both of the above cases, the ApplePay device (AppleWatch or iPhone 6) could communicate with the POST through NFC, BLE or WiFi.
There is no need for either device to be online to the Internet -- The POST receives the ApplePay data and the POST communicates with the bank (passes the token) over the Internet -- and receives an approval or not.
When you think about it -- giving someone your credit card (or credit card info) is [potentially] worse than just handing over your wallet.
How does it work at a restaurant? In the CC world, you can make a pending transaction without executing it. Normally, the restaurant verifies the payment first but amends it after the client adds the gratuity. Can Apple Pay do that?
If your ApplePay device also has to be online, not just the mercahnt's syatem, when making a payment then that is a horrible system that will not stop CC and/or cash from being carried.
I concur with all that Dick Applebaum detailed. The token will probably be encrypted by a public key that will authenticate the transaction (maybe supplied by the device in the preliminary phase). In case of an HTTPS transaction, the encryption is pointless since the link is secure.
In case of an HTTPS transaction, the encryption is pointless since the link is secure.
If you are shopping online, you have no idea whether the merchant is storing your card info or not. Some just pass it through to the gateway and some store to later be stolen by hackers. In either case they have your name and address, unlike shopping at a local store with Apple Pay.
How does it work at a restaurant? In the CC world, you can make a pending transaction without executing it. Normally, the restaurant verifies the payment first but amends it after the client adds the gratuity. Can Apple Pay do that?
If the terminal is offline (I mean, the device of the merchant) when the transaction is performed, then you cannot verify the transaction, not until the terminal is put back on its base, or whatever, and connected to the network.
How quickly we forget HeartBleed.
If you are shopping online, you have no idea whether the merchant is storing your card info or not. Some just pass it through to the gateway and some store to later be stolen by hackers. In either case they have your name and address, unlike shopping at a local store with Apple Pay.
What I meant is that if you shop online, you can just use the plain token the iPhone gives you (without encrypting it) because the link to the merchant is secure and the token is obsoleted once it is used.
How quickly we forget HeartBleed.
I thought Apple libcrypto was immune to HeartBleed because it was not based on the OpenBSD code.
If the terminal is offline (I mean, the device of the merchant) when the transaction is performed, then you cannot verify the transaction, not until the terminal is put back on its base, or whatever, and connected to the network.
I'm not understanding your message.
I'm not sure how typical restaurant payments are conducted in Europe since I never took notice when I was there. We only ate at small lunch spots where there was no gratuity and we paid in cash, except for a few times when our hosts would invite us out for dinner and then it usually ended up where the host and the restaurant owner would politely argue over the tab. The owner refusing to accept payment from his friend but the friend insisting on paying.
Anyway in the US, typically after the meal, one first receives the bill, then after review, the guest offers their credit card. The waiter takes the card to the cashier who issues and verifies a pending credit card transaction for the exact amount of the bill. When the waiter returns with the card and the receipt, the guest adds the gratuity and signs the merchant's copy of the receipt. Then the waiter goes back to the cashier who brings up the pending transaction, amends the new total and executes the final charges.
My question, is the sequence I described possible with Apple Pay? Perhaps the waiter will bring a wireless device to your table where you can enter the amount of the gratuity and pay the entire amount at once. I remember there was a credit card reader terminal manufacturer in the US that proposed something like that for restaurants but I have never seen one.
1) You specifically mentioned encryption is poiness because HTTPS was being used, hence my comment.
2) Apple not using that unsecured version of SSL doesn't mean there aren't other security issues so never assume that an acronym is impenetrable because one hole was plugged or a vendor isn't accepted by a particular hole.