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.
Admitting I pay with my CC in a restaurant, the waiter comes with a mobile device in which I insert my card, (s)he enters the amount due, I type my four-digit PIN and it's over. The tip is (exclusively) given in cash, since the ‘gratuity’ is included in the price charged by the restaurant.
Quote:
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.
It wouldn't be possible here. To avoid any fraud, nor the waiter nor anybody else is entitled to carry your card away. That’s why all restaurants have mobile terminals (which, I surmise are WiFi-connected to their base).
It wouldn't be possible here. To avoid any fraud, nor the waiter nor anybody else is entitled to carry your card away. That’s why all restaurants have mobile terminals.
That is probably better, however, not as elegant. When dining at a fine restaurant the payment is traditionally handled very discreetly and almost unnoticed by the other guests. Bringing a mobile device to the table might appear a bit tacky to some people.
That is probably better, however, not as elegant. When dining at a fine restaurant the payment is traditionally handled very discreetly and almost unnoticed by the other guests. Bringing a mobile device to the table might appear a bit tacky to some people.
In fine restaurants, the tradition is that the guest that treats pays directly at the desk – no check is given.
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.
<span style="font-size:16px;line-height:1.4em;">I thought I read, this whole ID "DAN + DYNAMIC" is very long. Not the length of a typical card number for high security</span>
IDK the length ... I'm an Apple Developer and I can't find any information ... yet.
But, even when the SDK becomes available, I suspect the token package contents and algorithms will be privy only to Apple and the Banks providing the ccs and accepting the tokens -- neither you, the customer, the app developer nor the merchant need to know.
But I suspect that the token doesn't to be as long as the 23 characters included in a cc swipe (or key entered) transaction:
16 char card #
4 char valid thru date code
3 char security code
Consider that to be valid the ApplePay token includes 2 algorithmically generated codess -- the DAN and the Security Code. Since these need to be paired/synched to be valid, they need not be long.
The timestamp could be included in the above algorithms, or not -- just generated by the POST.
The Feds identify individual Americans with a 9-digit Social Security
Without going into elaborate base system conversions -- each [displayed] character (byte) could contain 2 numeric digits ...
So, the SS number would be 5 characters long, maybe 3 characters representing the Bank ID (1,000,000 BankIDs) plus some algorithmically generated security code -- say 2 characters ...
So, with 10 [weird-looking] characters you could securely tie 1,000,000,000 Americans to 1,000,000 banks with 10,000 security codes.
Now, I don't think that there are 1 million banks, each providing cc services to 1 billion americans ...
More like 100 Banks, each with 100,000 customers ...
So, for practical purposes the token could be:
1 char BankID (99 banks)
3 char CustomerID (999,999 unique customers of that specific bank)
2 char security code
Without breaking a sweat, your AppleWatch or iPhone could generate and display a 6-character secure token that could displayed and sent (or keyed into the merchant's POST.
I THINK for restaurants its a little different. Opentable seems to be the method discussed for payment. Thus, you use the opentable app, at participating restaurants and pay with your bill and tip via the app. Fast food would be different since no tipping is involved. Also, unless it was a diner or other restaurant, where you walk up and pay, there wouldn't be an NFC terminal anyway. The waiter/Waitress isn't going to walk around with an NFC Terminal strapped to their arm for payment tableside. I think the Opentable method was a way to deal with using a card in these situations. No idea if there is a way to split a check, etc. Both sides would benefit, since this would drive up adoption of Opentable at more restaurants.
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.
When you shop online, you do it via the stores App. Is that store enables Apple Pay, in their App, you are presented with Apple pay as an option and you use touch id to authorize the transaction and your unique code for that specific purchase is transmitted to the seller. This would all be done via encryption.
The people using ?Pay with an iPhone 6 probably aren't shopping at Walmart.
They're probably shopping at Target (another MCX member).
Also of note: the CurrentC.com site has no link to download their vaporware mobile app (and what looks like a placeholder fake screenshot). Instead, it has a form which requires both email address and zip code.
"We're not in the business of collecting your data."
- MCX i mean Apple
I'm not saying MCX won't take off, or that it could even provide some good competition to Apple Pay (which I'm in favor of, since competition drives improvement). I do think Apple will win in the end, though. And I am saying that the creepy warning light goes off when I look at MCX.
When you shop online, you do it via the stores App. Is that store enables Apple Pay, in their App, you are presented with Apple pay as an option and you use touch id to authorize the transaction and your unique code for that specific purchase is transmitted to the seller. This would all be done via encryption.
If you use an iOS App on your iPhone, yes. But if you buy something on your Mac or whatever, it has to be different. Or maybe you'll have to tether your iPhone to your Mac and they will use a special handshake built in OS X 10.10 / iOS 8?
That is probably better, however, not as elegant. When dining at a fine restaurant the payment is traditionally handled very discreetly and almost unnoticed by the other guests. Bringing a mobile device to the table might appear a bit tacky to some people.
In fine restaurants, the tradition is that the guest that treats pays directly at the desk – no check is given.
Ha!
There are some things that that just won't work with ApplePay ... and maybe not even a credit card.
I'm reminded about a semi-fashion mail-order apparel house we were trying to automate (while I worked at IBM).
The least obvious (but most interesting) part of the process -- was opening the mail ... Opening the mail??
Yes, Opening the mail! The two partners would arrive each day (even if they had to get off their death beds) to open the mail
Each envelope contained an order form (magazine, prior order, mailing, etc.) and payment in the form of check, cc info, money order or cash ...
The order forms were sent (handed to) Order Processing (family), the checks, cc forms and were sent (handed to) accounting (owners' wives) for immediate deposit approval -- to be reconciled with Order Processing prior to shipment ...
The cash ... the cash just disappeared into the pockets of the owners ...
There was just no way that some guy form IBM was going to automate this process!
Then there was the time that a bartender friend let me assist him tending bar on a busy Halloween night.
He 'Splained as follows:
Normal customers get and pay (and tip) for what they ask ...
A lady comes in and orders a vodka tonic or somesuch -- charge her, but don't put any alcohol in her drink -- that's not why she's there ...
A guy comes in and orders, say, Wild Turkey on the rocks ... pays for it in cash, then lays a big wad of bills on the bar ... he drinks for free all night ... the wad of bills is a signal and a tip for the bartender ...
The owner is happy (the liquor/proceeds work out even), the bartender is happy -- good tips (some especially good), the customers are happy -- they socialized and are in [just the amount they desired of] good spirits.
If you use an iOS App on your iPhone, yes. But if you buy something on your Mac or whatever, it has to be different. Or maybe you'll have to tether your iPhone to your Mac and they will use a special handshake built in OS X 10.10 / iOS 8?
So far Apple pay is only available via iPhone 6 models or iPhone 5/5s via the watch, which is months away. Maybe there are things in the pipeline to address the mac, but my guess is that it will use a method of handoff and require the use of the phone. Don't forget iPad's haven't been discussed with Apple Pay either. This is why I am so sure there are going to be allot of refreshes coming and keynotes to tie this whole ecosystem together.
But, you need to remember a key aspect. The credit card is tied to your device and the secure enclave. Thus, that info would not be sync'd to any of your other devices. Institutions would have to then be able to store multiple device identfiers per card number, in order for you to process transations with a combo of an Pad, iPhone, Mac, etc. The watch uses a link between the phone so only the phone device identifier would be needed. I would see it as a PITA to have to handoff a transaction from my iPad to my iPhone to make a purchase, which would probably be the case if only a single device identifier could be associated with the card. At this point, Apple doesn't have to say anything since the rollout is strictly based on the iPhone6 at this point. But... there is another interesting thought. One new feature is the ability to make calls from your Mac via your iPhone clear across the room or house. What if you could process transactions the same way. Phone could be across the room. But in this case you use TouchID on your iPad to authenticate and then have access to process transactions via "your" phone clear across the room. Maybe a new TouchiID embeded magic trackpad for you Mac. Hmmmmm.
When you shop online, you do it via the stores App. Is that store enables Apple Pay, in their App, you are presented with Apple pay as an option and you use touch id to authorize the transaction and your unique code for that specific purchase is transmitted to the seller. This would all be done via encryption.
If you use an iOS App on your iPhone, yes. But if you buy something on your Mac or whatever, it has to be different. Or maybe you'll have to tether your iPhone to your Mac and they will use a special handshake built in OS X 10.10 / iOS 8?
Mavericks and Yosemite can use HandOff to do the job without tethering.
I suspect that all new Apple hardware (Macs, MacBooks, AppleTV, iPhones, iPads, etc.) will have NFC and TouchID.
Any or all of these device can be used as an ApplePay paying device -- or as an ApplePay/General NFC/Credit card merchant POST.
There are some things that that just won't work with ApplePay ... and maybe not even a credit card.
[…]
ApplePay -- No Way!
So quaint. The world was a funny place full of anecdotes like these before the big companies forced standardization on us. Now it is becoming increasingly bland.
There are some things that that just won't work with ApplePay ... and maybe not even a credit card.
[…]
ApplePay -- No Way!
So quaint. The world was a funny place full of anecdotes like these before the big companies forced standardization on us. Now it is becoming increasingly bland.
Not so much if you include lobbyists/politicians in the mix ... They've just institutionalized the processes!
Mavericks and Yosemite can use HandOff to do the job without tethering.
I suspect that all new Apple hardware (Macs, MacBooks, AppleTV, iPhones, iPads, etc.) will have NFC and TouchID.
Any or all of these device can be used as an ApplePay paying device -- or as an ApplePay/General NFC/Credit card merchant POST.
See my previous post of my thoughts regarding handoff and multiple devices. Curious as to your input.
As far as online transactions, I am not sure if one would be able to buy off a web page. Via iOS, you use the merchants APP and Applepay built into the OS for a secure direct link transaction. Maybe there will be Apple pay built into web pages and work only via Safari, to ensure that the link is secure but not sure. This is a whole other area Apple has not touched on and really doesn't have to, since they limited the scope to just iOS at the moment. Goal now is to drive adoption of the iPhone6. I believe there will be tons of announcements later that will help drive adoption further and enrich the entire ecosystem further.
Not so much if you include lobbyists/politicians in the mix ... They've just institutionalized the processes!
How true! We precisely had one ludicrous story just a couple of days ago over here in France.
Quitting for tonight. US maybe leading technologically, but Europe has always been ahead when it comes to time! Bye!
Enjoyed talking ...
Back in 1973, my parents took my wife, 7-year-old daughter and me on a grand tour of Europe ... after a few days in London, we went to Paris -- Stayed in the Intercontinental (now the Westin) on the Rue de Rivoli ... could see the Eiffel tower from our balcony. After a $10 each ham and egg breakfast in the hotel my wife and I convinced my parents to try some recommendations from Europe on $5 a day ...
They were game and we tried a recommendation of a little cafe frequented by Employees of the Bourse. The food was fantastic, †he prices were great -- but the congeniality was the most attractive. We sat at a large table, family style, surrounded French who [mostly] didn't speak English (or wouldn't admit it -- and we spoke no French.
We had a ball and somehow managed to communicate and enjoy each others' company on a more primitive level. We had 5 days in Paris/Versailles with a private guide and driver (Mercedes limo). We asked both for their recommendations of non-anglicized places and they all turned out to be excellent choices ... we'd go from a private tour of the Louvre to some fantastic hole in the wall.
It was a totally memorable highlight of our trip!
Sadly, the next phase was a Rhine Cruise -- with little opportunity to socialize with the locals.
[QUOTE]Bank Innovation turned to one of Apple Pay’s partners, MasterCard, for the lowdown. In an interview with Bank Innovation, Jorn Lambert, group executive of digital channels at MasterCard, shared the technical details for how Apple Pay will work when it is launched next month.
When a consumer wants to make a transaction with EMV debit or credit cards today, the card’s chip and the point-of-sale terminal generate a cryptogram — the transaction’s security key — and attach it to the consumer’s personal account number (PAN). The cryptogram is generated, in part, by the chip on the card, which was previously given to the consumer by the issuer. The cryptogram is then sent back to the issuing bank, which processes the transaction.
Because the issuer — in other words, the banks that work with the card networks — gave the consumer his card, the issuer is responsible for the quality and security of the cryptogram.
In transactions, Apple Pay will not only use a cryptogram, but a token as well. Lambert explained that the networks — Visa, MasterCard, and American Express — will generate the tokens which, in the case of Apple Pay, will be a 16-digit number that looks exactly like a credit card number, but it generated dynamically.
The process starts when a consumer inputs his credit card into his iPhone. When the card is inputted — the iPhone 6 allows for the card to be inputted via scanning — the networks send a token and a cryptogram to the iOS device, which stores them on a special chip (more about that in a moment). The iOS device, in this state with the cryptogram and token installed, is known as the “token requester.” (Some fintech folks had wondered whether Apple would be the “token provider,” but in actuality it — or its devices, really — are “token requesters.”) Again, Apple stores the token and cryptogram data on the phone in a “secure element” — which is a separate, secure chip within the iPhone especially dedicated to its security. This secure chip is also the only element within the device that can produce a token and cryptogram.
Getting back to our transaction, the consumer walks up to a checkout counter holding his iPhone stocked with a token and cryptogram. Apple Pay asks the consumer whether he wants to pay using his device and the NFC terminal sitting there on the checkout counter. He “says” yes in only one way: by using his fingerprint scan. This is the only authentication of the transaction.
This authentication prompts the “secure element” to send the token and cryptogram to the merchant. The network decrypts the cryptogram and determines whether it is authentic or not. If it is deemed authentic, the network will pass it along to the issuer (i.e. the bank), which then decrypts the token. In other words, every party to the transaction decrypts something.
Once the issuer decrypts the token and determines that it is authentic, the issuer/bank authorizes the transaction. Money is then credited to the merchant and marked as an amount owed by the cardholder.
This all happens in a split second.
CARD-PRESENT RATE
During in-store transactions, Apple will be passing the cryptogram and token to merchants via NFC, and Apple will be paying a “card present” rate in NFC purchases, Lambert confirmed to Bank Innovation. However, when using Bluetooth Low Energy (BLE), presumably how the iPhone 5 and 5S will do payments, or when making an in-app purchase using Apple Pay, the transaction fee will be the equivalent to a “card-not-present” rate.
We asked Lambert to discuss how the iWatch would be authenticated for payments, but he declined to give specifics since that information is not yet public.
There are a number of interesting implications here. First, while it may seem that Apple isn’t using any new technology, Lambert maintains that the combined use of tokens and biometric security features distinguishes Apple Pay from others. Second, Apple will not be handling the tokenization — the credit networks like Visa and MasterCard will be doing so. This essentially takes Apple out of the payment process — Lambert said that Apple will be acting “more as a channel and not a party,” and Apple already said in its major product announcement this week that it will not retain any transaction data. With Apple acting as a payment conduit and not a processor, it would already see little data, but Lambert said Apple has put up “some Chinese walls” to further prevent it from gaining access to payment data.
Lambert said that MasterCard was “extremely confident” in tokenization technology and said that each network is offering their clients different tools and kits to help banks and merchants work with tokens. With token technology poised to take off thanks to Apple Pay, look for the credit networks to use their tokenization technology as another potential revenue stream. Say it with me: “Thank you, Apple.”
[quote name="Dick Applebaum" url="/t/182243/apple-pay-nets-favorable-transaction-fees-from-banks-denied-support-from-walmart-and-best-buy/120#post_2597209"]Mavericks and Yosemite can use HandOff to do the job without tethering.[/QUOTE]
I believe that teeters with an ad-hoc BT connection to an iDevice.
[QUOTE]I suspect that all new Apple hardware (Macs, MacBooks, AppleTV, iPhones, iPads, etc.) will have NFC and TouchID.[/QUOTE]
Again, in what scenario would use Near Field Communication to make a payment from your iMac or AppleTV to a merchant. The link is only a few inches.
Note that in no way does it state the iPhone need to be connected to WiFi or cellular in order to get a one-time use token at the time of the purchase.
If Apple Pay takes off, Walmart and Best Buy will be scrambling to support this. Surprised that a dying Best Buy would give a thumbs down to a new, easier way for people to spend money at their stores.
Comments
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.
Admitting I pay with my CC in a restaurant, the waiter comes with a mobile device in which I insert my card, (s)he enters the amount due, I type my four-digit PIN and it's over. The tip is (exclusively) given in cash, since the ‘gratuity’ is included in the price charged by the restaurant.
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.
It wouldn't be possible here. To avoid any fraud, nor the waiter nor anybody else is entitled to carry your card away. That’s why all restaurants have mobile terminals (which, I surmise are WiFi-connected to their base).
It wouldn't be possible here. To avoid any fraud, nor the waiter nor anybody else is entitled to carry your card away. That’s why all restaurants have mobile terminals.
That is probably better, however, not as elegant. When dining at a fine restaurant the payment is traditionally handled very discreetly and almost unnoticed by the other guests. Bringing a mobile device to the table might appear a bit tacky to some people.
That is probably better, however, not as elegant. When dining at a fine restaurant the payment is traditionally handled very discreetly and almost unnoticed by the other guests. Bringing a mobile device to the table might appear a bit tacky to some people.
In fine restaurants, the tradition is that the guest that treats pays directly at the desk – no check is given.
IDK the length ... I'm an Apple Developer and I can't find any information ... yet.
But, even when the SDK becomes available, I suspect the token package contents and algorithms will be privy only to Apple and the Banks providing the ccs and accepting the tokens -- neither you, the customer, the app developer nor the merchant need to know.
But I suspect that the token doesn't to be as long as the 23 characters included in a cc swipe (or key entered) transaction:
Consider that to be valid the ApplePay token includes 2 algorithmically generated codess -- the DAN and the Security Code. Since these need to be paired/synched to be valid, they need not be long.
The timestamp could be included in the above algorithms, or not -- just generated by the POST.
The Feds identify individual Americans with a 9-digit Social Security
Without going into elaborate base system conversions -- each [displayed] character (byte) could contain 2 numeric digits ...
So, the SS number would be 5 characters long, maybe 3 characters representing the Bank ID (1,000,000 BankIDs) plus some algorithmically generated security code -- say 2 characters ...
So, with 10 [weird-looking] characters you could securely tie 1,000,000,000 Americans to 1,000,000 banks with 10,000 security codes.
Now, I don't think that there are 1 million banks, each providing cc services to 1 billion americans ...
More like 100 Banks, each with 100,000 customers ...
So, for practical purposes the token could be:
Without breaking a sweat, your AppleWatch or iPhone could generate and display a 6-character secure token that could displayed and sent (or keyed into the merchant's POST.
I THINK for restaurants its a little different. Opentable seems to be the method discussed for payment. Thus, you use the opentable app, at participating restaurants and pay with your bill and tip via the app. Fast food would be different since no tipping is involved. Also, unless it was a diner or other restaurant, where you walk up and pay, there wouldn't be an NFC terminal anyway. The waiter/Waitress isn't going to walk around with an NFC Terminal strapped to their arm for payment tableside. I think the Opentable method was a way to deal with using a card in these situations. No idea if there is a way to split a check, etc. Both sides would benefit, since this would drive up adoption of Opentable at more restaurants.
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.
When you shop online, you do it via the stores App. Is that store enables Apple Pay, in their App, you are presented with Apple pay as an option and you use touch id to authorize the transaction and your unique code for that specific purchase is transmitted to the seller. This would all be done via encryption.
The people using ?Pay with an iPhone 6 probably aren't shopping at Walmart.
They're probably shopping at Target (another MCX member).
Also of note: the CurrentC.com site has no link to download their vaporware mobile app (and what looks like a placeholder fake screenshot). Instead, it has a form which requires both email address and zip code.
"We're not in the business of collecting your data."
- MCX i mean Apple
I'm not saying MCX won't take off, or that it could even provide some good competition to Apple Pay (which I'm in favor of, since competition drives improvement). I do think Apple will win in the end, though. And I am saying that the creepy warning light goes off when I look at MCX.
When you shop online, you do it via the stores App. Is that store enables Apple Pay, in their App, you are presented with Apple pay as an option and you use touch id to authorize the transaction and your unique code for that specific purchase is transmitted to the seller. This would all be done via encryption.
If you use an iOS App on your iPhone, yes. But if you buy something on your Mac or whatever, it has to be different. Or maybe you'll have to tether your iPhone to your Mac and they will use a special handshake built in OS X 10.10 / iOS 8?
Ha!
There are some things that that just won't work with ApplePay ... and maybe not even a credit card.
I'm reminded about a semi-fashion mail-order apparel house we were trying to automate (while I worked at IBM).
The least obvious (but most interesting) part of the process -- was opening the mail ... Opening the mail??
Yes, Opening the mail! The two partners would arrive each day (even if they had to get off their death beds) to open the mail
Each envelope contained an order form (magazine, prior order, mailing, etc.) and payment in the form of check, cc info, money order or cash ...
The order forms were sent (handed to) Order Processing (family), the checks, cc forms and were sent (handed to) accounting (owners' wives) for immediate deposit approval -- to be reconciled with Order Processing prior to shipment ...
The cash ... the cash just disappeared into the pockets of the owners ...
There was just no way that some guy form IBM was going to automate this process!
Then there was the time that a bartender friend let me assist him tending bar on a busy Halloween night.
He 'Splained as follows:
Normal customers get and pay (and tip) for what they ask ...
A lady comes in and orders a vodka tonic or somesuch -- charge her, but don't put any alcohol in her drink -- that's not why she's there ...
A guy comes in and orders, say, Wild Turkey on the rocks ... pays for it in cash, then lays a big wad of bills on the bar ... he drinks for free all night ... the wad of bills is a signal and a tip for the bartender ...
The owner is happy (the liquor/proceeds work out even), the bartender is happy -- good tips (some especially good), the customers are happy -- they socialized and are in [just the amount they desired of] good spirits.
ApplePay -- No Way!
If you use an iOS App on your iPhone, yes. But if you buy something on your Mac or whatever, it has to be different. Or maybe you'll have to tether your iPhone to your Mac and they will use a special handshake built in OS X 10.10 / iOS 8?
So far Apple pay is only available via iPhone 6 models or iPhone 5/5s via the watch, which is months away. Maybe there are things in the pipeline to address the mac, but my guess is that it will use a method of handoff and require the use of the phone. Don't forget iPad's haven't been discussed with Apple Pay either. This is why I am so sure there are going to be allot of refreshes coming and keynotes to tie this whole ecosystem together.
But, you need to remember a key aspect. The credit card is tied to your device and the secure enclave. Thus, that info would not be sync'd to any of your other devices. Institutions would have to then be able to store multiple device identfiers per card number, in order for you to process transations with a combo of an Pad, iPhone, Mac, etc. The watch uses a link between the phone so only the phone device identifier would be needed. I would see it as a PITA to have to handoff a transaction from my iPad to my iPhone to make a purchase, which would probably be the case if only a single device identifier could be associated with the card. At this point, Apple doesn't have to say anything since the rollout is strictly based on the iPhone6 at this point. But... there is another interesting thought. One new feature is the ability to make calls from your Mac via your iPhone clear across the room or house. What if you could process transactions the same way. Phone could be across the room. But in this case you use TouchID on your iPad to authenticate and then have access to process transactions via "your" phone clear across the room. Maybe a new TouchiID embeded magic trackpad for you Mac. Hmmmmm.
Mavericks and Yosemite can use HandOff to do the job without tethering.
I suspect that all new Apple hardware (Macs, MacBooks, AppleTV, iPhones, iPads, etc.) will have NFC and TouchID.
Any or all of these device can be used as an ApplePay paying device -- or as an ApplePay/General NFC/Credit card merchant POST.
Ha!
There are some things that that just won't work with ApplePay ... and maybe not even a credit card.
[…]
ApplePay -- No Way!
So quaint. The world was a funny place full of anecdotes like these before the big companies forced standardization on us. Now it is becoming increasingly bland.
Not so much if you include lobbyists/politicians in the mix ... They've just institutionalized the processes!
Not so much if you include lobbyists/politicians in the mix ... They've just institutionalized the processes!
How true! We precisely had one ludicrous story just a couple of days ago over here in France.
Quitting for tonight. US maybe leading technologically, but Europe has always been ahead when it comes to time! Bye!
Mavericks and Yosemite can use HandOff to do the job without tethering.
I suspect that all new Apple hardware (Macs, MacBooks, AppleTV, iPhones, iPads, etc.) will have NFC and TouchID.
Any or all of these device can be used as an ApplePay paying device -- or as an ApplePay/General NFC/Credit card merchant POST.
See my previous post of my thoughts regarding handoff and multiple devices. Curious as to your input.
As far as online transactions, I am not sure if one would be able to buy off a web page. Via iOS, you use the merchants APP and Applepay built into the OS for a secure direct link transaction. Maybe there will be Apple pay built into web pages and work only via Safari, to ensure that the link is secure but not sure. This is a whole other area Apple has not touched on and really doesn't have to, since they limited the scope to just iOS at the moment. Goal now is to drive adoption of the iPhone6. I believe there will be tons of announcements later that will help drive adoption further and enrich the entire ecosystem further.
Enjoyed talking ...
Back in 1973, my parents took my wife, 7-year-old daughter and me on a grand tour of Europe ... after a few days in London, we went to Paris -- Stayed in the Intercontinental (now the Westin) on the Rue de Rivoli ... could see the Eiffel tower from our balcony. After a $10 each ham and egg breakfast in the hotel my wife and I convinced my parents to try some recommendations from Europe on $5 a day ...
They were game and we tried a recommendation of a little cafe frequented by Employees of the Bourse. The food was fantastic, †he prices were great -- but the congeniality was the most attractive. We sat at a large table, family style, surrounded French who [mostly] didn't speak English (or wouldn't admit it
We had a ball and somehow managed to communicate and enjoy each others' company on a more primitive level. We had 5 days in Paris/Versailles with a private guide and driver (Mercedes limo). We asked both for their recommendations of non-anglicized places and they all turned out to be excellent choices ... we'd go from a private tour of the Louvre to some fantastic hole in the wall.
It was a totally memorable highlight of our trip!
Sadly, the next phase was a Rhine Cruise -- with little opportunity to socialize with the locals.
Here's some more info on how it works!
[QUOTE]Bank Innovation turned to one of Apple Pay’s partners, MasterCard, for the lowdown. In an interview with Bank Innovation, Jorn Lambert, group executive of digital channels at MasterCard, shared the technical details for how Apple Pay will work when it is launched next month.
When a consumer wants to make a transaction with EMV debit or credit cards today, the card’s chip and the point-of-sale terminal generate a cryptogram — the transaction’s security key — and attach it to the consumer’s personal account number (PAN). The cryptogram is generated, in part, by the chip on the card, which was previously given to the consumer by the issuer. The cryptogram is then sent back to the issuing bank, which processes the transaction.
Because the issuer — in other words, the banks that work with the card networks — gave the consumer his card, the issuer is responsible for the quality and security of the cryptogram.
In transactions, Apple Pay will not only use a cryptogram, but a token as well. Lambert explained that the networks — Visa, MasterCard, and American Express — will generate the tokens which, in the case of Apple Pay, will be a 16-digit number that looks exactly like a credit card number, but it generated dynamically.
The process starts when a consumer inputs his credit card into his iPhone. When the card is inputted — the iPhone 6 allows for the card to be inputted via scanning — the networks send a token and a cryptogram to the iOS device, which stores them on a special chip (more about that in a moment). The iOS device, in this state with the cryptogram and token installed, is known as the “token requester.” (Some fintech folks had wondered whether Apple would be the “token provider,” but in actuality it — or its devices, really — are “token requesters.”) Again, Apple stores the token and cryptogram data on the phone in a “secure element” — which is a separate, secure chip within the iPhone especially dedicated to its security. This secure chip is also the only element within the device that can produce a token and cryptogram.
Getting back to our transaction, the consumer walks up to a checkout counter holding his iPhone stocked with a token and cryptogram. Apple Pay asks the consumer whether he wants to pay using his device and the NFC terminal sitting there on the checkout counter. He “says” yes in only one way: by using his fingerprint scan. This is the only authentication of the transaction.
This authentication prompts the “secure element” to send the token and cryptogram to the merchant. The network decrypts the cryptogram and determines whether it is authentic or not. If it is deemed authentic, the network will pass it along to the issuer (i.e. the bank), which then decrypts the token. In other words, every party to the transaction decrypts something.
Once the issuer decrypts the token and determines that it is authentic, the issuer/bank authorizes the transaction. Money is then credited to the merchant and marked as an amount owed by the cardholder.
This all happens in a split second.
CARD-PRESENT RATE
During in-store transactions, Apple will be passing the cryptogram and token to merchants via NFC, and Apple will be paying a “card present” rate in NFC purchases, Lambert confirmed to Bank Innovation. However, when using Bluetooth Low Energy (BLE), presumably how the iPhone 5 and 5S will do payments, or when making an in-app purchase using Apple Pay, the transaction fee will be the equivalent to a “card-not-present” rate.
We asked Lambert to discuss how the iWatch would be authenticated for payments, but he declined to give specifics since that information is not yet public.
There are a number of interesting implications here. First, while it may seem that Apple isn’t using any new technology, Lambert maintains that the combined use of tokens and biometric security features distinguishes Apple Pay from others. Second, Apple will not be handling the tokenization — the credit networks like Visa and MasterCard will be doing so. This essentially takes Apple out of the payment process — Lambert said that Apple will be acting “more as a channel and not a party,” and Apple already said in its major product announcement this week that it will not retain any transaction data. With Apple acting as a payment conduit and not a processor, it would already see little data, but Lambert said Apple has put up “some Chinese walls” to further prevent it from gaining access to payment data.
Lambert said that MasterCard was “extremely confident” in tokenization technology and said that each network is offering their clients different tools and kits to help banks and merchants work with tokens. With token technology poised to take off thanks to Apple Pay, look for the credit networks to use their tokenization technology as another potential revenue stream. Say it with me: “Thank you, Apple.”
[/QUOTE]
http://bankinnovation.net/2014/09/heres-how-the-security-behind-apple-pay-will-really-work/
I believe that teeters with an ad-hoc BT connection to an iDevice.
[QUOTE]I suspect that all new Apple hardware (Macs, MacBooks, AppleTV, iPhones, iPads, etc.) will have NFC and TouchID.[/QUOTE]
Again, in what scenario would use Near Field Communication to make a payment from your iMac or AppleTV to a merchant. The link is only a few inches.
Note that in no way does it state the iPhone need to be connected to WiFi or cellular in order to get a one-time use token at the time of the purchase.