Apple Pay(apple.com) |
Apple Pay(apple.com) |
Mainly they exploited the fact that the FindMyIphone website did not throttle the number of login attempts. So you can do it as many times as possible. Apple deflected this by "denying" that any usernames or passwords were leaked, but in reality it is their fault that the accounts were compromised.
Pay Apple.
There was early speculation that the flaw was at fault, but no confirmation from anyone.
Go ahead though - blame that bug, because Apple.
If the internet was invented today, we would have AppleMail instead of email and GoogleTrans instead of http.
A possible reason Apple might succeed where Google Wallet failed: Apple have a better track record of telling MNOs to fuck off. It's the reason the software update process is better on iPhone, it's the reason your iPhone doesn't come with carrier bloatware, and it's the reason they can put a secure element in their phone without the MNO being the root of trust.
Also, I haven't had one issue with software updates on my Nexus 5 (which indeed comes bloatware free). If I recall correctly, wasn't the iOS7 update a shit show?
You had CompuServe mail, and Prodigy mail, and AOL mail, and any number of internal mail systems at different companies. There was not a single mail format or agreed upon address space. Getting mail from one system to another was a huge pain.
RFC 822 didn't just come into existence one day.
From what I read, Apple Pay is the following things:
- A management interface to manage payment methods on your device.
- A user interface to interact with these payment methods.
- A set of APIs to interact with these payment methods from software.
- A term for hardware and software components in the iPhone that allow interaction of these payment methods with point of sale hardware.
What Apple Pay is not:
- A payment protocol.
So Apple Pay is a payment method management application. It is not a payment protocol. The payment protocol Apple Pay uses to interface with point of sale terminals is the same EMV protocol that is used for other solutions.
Any other payment method application can also use this same EMV protocol. Many do already in fact, such as Google Wallet. I would not be surprised if Wallet was able to interface with the shown POS hardware with barely any modification to the app.
I hope anyone with more knowledge of this project could confirm this interpretation is correct.
Also it might not be necessary for the involved parties to get together. They could release different protocols. And then the lesser used will be forgotten (like gopher is forgotten today) and the more frequent used will survive (like http has survived).
Update: Why the downvotes?
Really, what's the point?
Adoption. Apple brings it's users... who just seem to adopt Apple features better than competitors' similar features.
If contactless pay is a gordian knot of user vs. merchant adoption, Apple will play the part of Alexander and untie/sever the knot.
2) The credit card gives away data that can be used for fraud. Your phone does not have to do that.
Would they have given early access and bundled the Suica app for instance, they could have boasted millions of users from the get go. I wonder if the upcoming API is even compatible with the Felica standard, but that would be a weird thing to do.
That system is also widely deployed but in my experience (9 years of living there, no evidence other than anecdotal) not widely used.
I think regarding to NFC, it really depends on where you live. I was commuting on a JR line, and having Mobile Suica combine with Edy was such a boon that I could forget my wallet I wouldn't care. Just having your phone means you can ride the train, buy anything at the convince store, pay the restaurant (you may have less choice, but there's a lot of them accepting Edy or another service), buy music or electronics, and buy drinks from vending machines. It's almost surreal how much you can do.
I later moved to the Keikyuu line and it was still great, but less magical.
In terms of technical control, Apple already choose "standard NFC" (at least that's the quote I have on the liveblog), and I would guess they are bound by Visa and Amex for the implementation. A priori Felica is part of the NFC standard, IF it supports the encrypted protocol it should be OK to have everything as third party apps.
Chrome is complaining that Google Safe browsing detected an ongoing phishing attack.
I have a feeling on the terminal side, it looks just like like a plastic card with PayPass.
I live in a country where banks tend to come up with similar payment technologies at the same time; one example is the Chipknip vs Chipper, both bank card technologies for putting pre-paid amounts of cash on the card to be used to pay without having to enter a PIN or the longish time it took for a regular card payment to process. Didn't take long for the payment terminals to support both platforms.
ATM we've got a similar fight going on; a few banks have contactless payments now, but one bank is going for NFC payments via (very specific models of) smartphones (Samsung Galaxy models; I gathered they're using an already deprecated API/technology for that). But the same argument applies; both technologies use NFC, so all it needs to work is a firmware upgrade.
I've had NFC on Android phones for almost 2 years now, but I've still never been able to use it in the UK. We have some contactless payment terminals now, but the only services that allow you to use NFC payments on your phone here are tied to specific banks/carriers, or only work on specific phones.
I'm hoping that Apple Pay will push more merchants and services to start accepting NFC payments in general.
Also viewing this through the lens that e-commerce view shopping cart conversion rates, this might up initial conversion for new services, which in Uber cases is a win. Just forces everyone to focus more on product.
Does this use the same technology?
PAN = primary account number.
EMV = Europay, MasterCard, Visa. http://en.m.wikipedia.org/wiki/EMV
1. Say, I have an app that will Apple Pay. So in addition to 30% cut made by Apple for my app will using Apple Pay cost more ?
2. I understand this will require NFC terminal to recognize the payment through Apple Pay but that's in physical store. If I already have some payment method setup for my app why should I choose to use Apple Pay ? or I guess my question is Apple already stores credit cards. While purchasing apps you can already do with one click. How Apple Pay is different ?
Apple Pay won't change anything about purchasing apps / in-app purchases.
Apple Pay won't take a 30% cut of every transaction.
From their website: "Apple Pay lets you use iPhone 6 to pay in stores and within apps in an easy, secure, and private way."
Apple's partners in this, including Visa, Mastercard and Amercian Express, as well as all those prominent banks must have been looking for reassurances that payment and card data was going to be safe.
It must have been an embarassing week.
Considering that Apple/iCloud doesn't store any payment or card data with Apple pay, and that the hack in question wasn't due to any specific weakness in Apple/iCloud infrastructure, I very much doubt there were any reassurances required...
Then you're screwed.
If you have to carry the card anyway to get around this, what's the point other than showing everyone you have an iPhone, which at least in London is a quick way to get cracked over the head.
My phone is already out anywhere I'm buying things. Makes sense to pay with that instead of fishing for something else.
The U.S. is one of the last places to get this.
And my gut tells me that this is a secondary reason for why they moved the power button over to the right side of the phone (primary reason being to accommodate smaller hands with the larger screen sizes).
[1] http://www.theverge.com/2014/9/9/6107091/apple-watch-iphone-...
Well it's already available through Stripe: https://news.ycombinator.com/item?id=8292026 - so I'm pretty sure there's good news ahead :)
more info: https://developer.apple.com/apple-pay/
There - fixed that for you... Apple sells "(tens of) millions" of iPhones per quarter - and that tends to grow. A couple of years of sales add up to a lot of phones.
I would have loved if they would have gone beyond the marketing messages, and explained in some more detail about how they have made this secure, what improvements they have made (to TouchID etc) over previous versions and how a user can use it without worry.
I think we are seeing a move to Apple <Product Name>, partly because of this and partly because the Apple brand is so strong.
I think this business can eventually become larger than the iTunes if they execute it well.
I couldnt find any information on whether Apple pay users can use this for online purchases or not. If they do this may be their next move will be to naturally be the Paypal competitor.
"The biggest “surprise” over last 2 months is that Apple has squeezed 15-25bps from the 5-6 participating banks at launch (C, BAC, COF, JPM, Amex and perhaps WFC)."
Is it safe to assume that in the future, an iPhone itself can be a device that ACCEPTS payments too?
They're just using existing NFC POS that currently take Google Wallet, there's nothing special about the fact that it takes Apple Pay.
Does that mean there will be an API for 3rd party developers to ACCEPT Apple Pay over the air? Or do they have to build a special Card Reader? Or would they have to bring back an Apple Pay supported Square Wallet app?
i know that nfc can support two-way communication so was wondering if anyone knows offhand if apple's api exposes this option. if so, it should be possible to also accept payment using apple pay (hopefully new ipads get nfc in the next revision to support this).
The biggest “surprise” over last 2 months is that Apple has squeezed 15-25bps from the 5-6 participating banks at launch (C, BAC, COF, JPM, Amex and perhaps WFC).
I hardly ever carry cash with me anymore when I'm in Japan. Suica and Edy are accepted almost everywhere and it's super convenient. I'm sure it's even better for people who live there because they can get it integrated into their phone, which is not available to tourists like me.
Since the iPhones that have NFC also have TouchID, they can authenticate you instantly without resorting to a PIN. If it works as advertised, it will be a huge improvement over Google Wallet.
(I still think Square got closest to an ideal payment scheme with Pay with Square, where the cashier verifies your face to charge you without requiring you to pull anything out. Too bad they broke it by requiring you to pull out your phone to check-in before it would work.)
1. Timing - 2011 (Wallet release) seems early for consumer NFC, not to mention smartphone penetration ([1] ~30% 2011 to ~70% 2014) and mass market comfort with mobile transactions (Uber, etc.) Wallet may just have been launched too early, they may have educated the market rather than capitalized on it.
2. Existing credit card info - many consumers already give Apple their CC info and payments (iTunes). I can only think of a few examples where you pay Google (Adwords, Google Play) and they are less commonly used.
3. Hype factor - Apple has some magic when it comes to hyping consumer products and services. Google has some of this, but I don't think it's nearly as much, especially with the general population (i.e. non-developers).
[1] http://www.gsmarena.com/asymco_pricing_doesnt_affect_smartph...
So if you get a new iPhone, you're ready to start using it almost immediately. I'm sure I'll use it.
With Android, Google has to get you to sign up for wallet and get you to know that you should want to. Plus you had to have a phone that supports it (I don't know how common that is among high end Android phones).
This is one of those situations where "just being Apple" is a huge advantage.
In any case, hopefully this will force the industry to move forward, particularly on Android.
If merchants are getting new credit card terminals anyhow, it seems likely they'd get NFC compatible ones.
I noticed that the Whole Foods near me just changed their credit card terminals a couple of weeks ago...
Can you explain how they are the same?
That said, no one else was using it back then unless you worked military or university. Once it started to commercialize, then you had all the walled gardens. So although you're technically correct, BBS's were still the majority of the way we were connecting back then.
Due to EMV liability shift, tokenization, windows xp deprecation (as well as a number of other changes in the payment industry), merchants now have the catalyst to look at other solutions. This has opened the door for everything from POS to payment terminals to hand held registers. By lowering the bar of PCI compliance and risk, it opens up the sector to other devices and applications that do not need to meet the bars of payment compliance.
Not with chip and pin or contactless it doesn't
1. upload your Credit/Debit card info to an app(passport/wallet)
2. your phone must have NFC.
3. pay with your phone at a NFC capable terminal.
Not to mention the Suica + Pasmo combination a year or so ago that meant you didn't have to carry around two cards anymore. It was pretty amazing. It's at a point now where I'm really reluctant to buy phones that don't have mobile Suica/osaifu keitai support.
http://www.bloomberg.com/news/2014-09-03/isis-mobile-wallet-...
Toward the end, there were gateways between (almost) all of these systems that worked more or less reliably. You had to keep a text file handy to figure out how to mung an address on network #1 so that it would delivered to network #2.
For instance, a WWIVNet user could send email to foo@bar.com by sending it to foo#bar.com@5XX, where 5xx was a WWIVNet node number in the 500 range (these were reserved for gatewaying purposes). An Internet user could send email to 23@9073 on WWIVNet by sending it to 23-9073@(some site that was running the gateway software).
Similar address rewriting hacks were used for the other networks. Some were pretty straightforward -- I remember CompuServe used addresses roughly like 888,923423. To send mail from the Internet to CompuServe, you just had to change the comma to a period and tack @compuserve.com on the end. Others were pretty arcane.
Probably more than you wanted to know. :-)
The US does about $12B in card transactions per day. This means that for every 1% of US transactions it captures, Apple could add ~$80M to the annual revenue which is a very small amount against its $140B revenue. Yes there are international markets, but still this is not done for profits by itself.
A unit that is equal to 1/100th of 1%
For me, it might not take much - just Walgreens, some supermarkets, and a decent number of local restaurants supporting this might be enough to allow me to leave my wallet at home on a typical workday. Ironically the one card I'd probably still need, my transit card (Clipper), I assume also uses NFC of some sort. It'd be nice if the new iPhone's NFC feature could support that as well.
A payment system that wasn't cooked up by weirdos would include actual security features such as your phone's display shows the amount of the transaction and you enter pin or password or other knowledge and your phone signs the transaction. That would be nonrepudiable and you could clear such transactions at negligible cost because there's little risk.
Square, which isn't exactly winning out there, at least does include a modest security feature of displaying the picture of the authorized card user on the terminal.
http://secureidnews.com/news-item/host-card-emulation-enable...
We've had high penetration of contactless in Australia for a long while now, security being "happen to physically hold the card". The bar to accept contactless payments is very low - what matters is that a merchant actually accepts them.
100,000 contactless terminals across the country[1], the numbers for Pay usage in Australia would be very impressive.
[1]: http://www.smartcompany.com.au/finance/42250-australia-leads...
[2]: http://www.news.com.au/finance/money/australia-hooked-on-tap...
And yeah, like Australia, contactless has been growing in Europe for the last few years. It's just starting in the US and these devices will help to trigger uptake (IMO).
The problem with credit card payments in Australia is that many merchants charge an additional fee for using it, so I often end up paying cash anyway. This is stupid -- the payment processing fee is a cost of doing business, and should not be passed on to customers (or should be built into the pricing of the products).
As for the rest of your comment, I don't think you're doing any risk modeling.
I have $0 fraud liability on all my cards. When fraud occurs, it takes a couple minutes to dispute a transaction. Even when it was a debit card, my credit union immediately gave me a provisional credit for the disputed amount while they investigated. The total cost to me for fraud is no more than a few minutes of my time. I have little reason to care about security.
Banks care about profit. What makes you think they haven't considered tighter security measures, and found that the cost of implementing them (including the inconvenience to consumers and resulting lost revenue) outweigh the savings from reduced fraud?
Yep, Whole Foods near me has as well. Also Walgreens near me has new terminals too.
The only place it won't work at all is self-service kiosk.
I don't know enough about chip and PIN to say if it's possible, but I'm hoping that means they'll eventually move to adding a PIN too.
All that said -- my iPhone 5 is coming off contract in a few weeks now and I definitely plan on picking up an iPhone 6; I'm looking forward to seeing how well Pay works.
- Android has an open source version (that is, a version that is completely open source). Like you mentioned, this gives carriers and OEMs the freedom to do what they want, even fork and bloat.
- Android has a mixed license version, where you get the full experience of the Google Play store, Gmail, and so forth. Google has a lot more control over who it allows to use this version, since many of the components are not free software.
I have the choice to buy a phone without bloatware and I did. I don't know why others don't do the same and then blame the OS maker for allowing their open software to be open.
These policies also allow for cheaper phones to get into the hands of the less affluent. Not everyone can afford the new iPhone, and they would rather have a phone with a bit more bloatware if it cuts the cost of the phone down to something they can reasonably afford. I would consider that a noble endeavor on the part of Google. Instead of saying, "FUCK YOU CARRIERS/OEMS, YOU DO AS WE SAY!", it offered them a means of providing cheaper phones without decimating their bottom line. They can choose to strip out all the bloat and price it high or they can bloat it up and price it low, making up the cost from the recurring fees/ad rev those apps can generate.
The thing is, I have a choice as to what experience I want.
There is Android, which is a complete open source operating system tailored for touchscreen devices. It is completely open source and in principle has no dependencies on any piece of propietary software to function. Android is not usually distributed with just its open source components, however.
There is Google Play Services. This a propietary set of applications and system services that interact with Google's cloud services. Since Google's cloud services are popular - most significantly the Google Play Store for Android apps - these services almost always come bundled with devices on the market. Android and Google Play Services together are also often called "Android" (even by Google itself) which is the cause of the confusion. There is a clear difference between the two, however.
Then there are further customizations in themeing, user interface components and applications made by vendors and carriers.
The problem of bloatware is that Google has only felt responsibility for Google Play Services; the other software on the system, including Android, was the responsibility of the carriers and the vendors. Android is developed by Google as an open source and popular foundation from which to provide its services - either from Android's web capabilities or from its bundled applications.
No, you don't recall correctly. iOS has had the ability to update via iTunes since it's very first release in 2007. iOS users have been able to update their devices regularly to the latest and the greatest without problems for many years, while on Android it's the exception rather than the rule.
This includes iOS 7, which like previous and later releases works across a variety of new and older devices.
The only thing controversial about iOS 7 was the UI was "flatter" and more colorful which some people didm't like.
I would say that an update can't get worse but at least I liked IOS7 when I got to use it so I wasn't too phased. What actually makes me much more miserable is when software updates introduce new bugs, remove features and slow the device down and I can't do anything about it.
Also, the "update shit show" reference was toward the software that was updated, not the update process itself, regardless of the hardware/software needed to pull it off.
Source for the downvoters: http://www.usatoday.com/story/tech/2013/10/17/apple-ios-7-pr...
Not sure what you're referring to. I'm happily using iOS7 on a iPhone 4 (a 4 year old phone) to this day.
Bloatware has some good it brings, this good just doesn't have an affect on me.
Similar to taxes, I pay a ton of them and don't really get anything back aside from so-so roads. Where someone who is in a bit worse spot sees a lot of benefits from those taxes. It's something I accept as necessary, but I still do everything I can to keep them as low as possible.
But I don't go around blaming the Federal gov't because California taxes me higher than Washington would. Instead of proposing the feds restrict what can and can't be taxed, I could just move to Washington. The choice is mine! FREEDOM FTW! ;P