So we want to make payments via our phones. My first thought would be to create a protocol for this. Instead we get ApplePay and GoogleWallet and whatnot.
If the internet was invented today, we would have AppleMail instead of email and GoogleTrans instead of http.
The payments protocol is called EMV. The wireless transport protocol is ISO14443. Then we have different branding of the combination of EMV+ISO14443 for different card issuing networks (Mastercard PayPass, Visa payWave, etc.) Apple Pay and Google Wallet are further branding of the pair of standards.
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.
Google doesn't cause bloatware, Carriers and Handset makers do. One of the many consequences of OSS, people can fork and bloat to their heart's content.
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?
Google doesn't write the bloatware, but its actions allow bloatware to exist on android in a few ways, as far as I understand.
- 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.
Silent Circle released the Blackphone it developed off a fork of Android. This policy has allowed for bloatware, yes, but it also allows for innovators to innovate unimpeded.
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.
Well, I agree with most of your statement, however, in your scenario you only have a choice in what experience you want if you have the money to buy the unsubsidized phone- anyone else has the choice to buy the subsidized bloatware phone or do without (which is more choice than they would have if the subsidized phone did not exist...)
There's another option, root and load a custom Rom. Not only will the phone run leaner (and in theory faster) but it won't have the bloat. The only investment is your time. =]
There are no "two versions of Android". That's an unnecessary confusion of the situation.
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.
If I recall correctly, wasn't the iOS7 update a shit show?
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.
Huh. The IO7 update bricked my iPad. I had to get it replaced in store.
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.
So one needs a computer with iTunes installed to update an iOS device? It doesn't do it over the air?
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.
Fair enough. I didn't have any of these problems. I would say that every Mac OS update ever has generated a bunch of traffic on user forums as well, though it's always difficult to say what percentage of the user base were affected.
Google exercise control over the software shipped on all mainstream Android phones through Google Mobile Services licensing (GMS includes the Play Store, gmail, maps, GCM, etc.) These restrictions could include ones which prevent MNOs and OEMs from adding bloatware, but they don't.
These restrictions would stymie innovation as well as take the devices out of the hands of the less-affluent, no bueno.
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
You might not remember this, but that's exactly what originally happened.
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.
That's not how it "originally happened." Perhaps you're too young to remember the days before AOL and CompuServe, but email was being used more than a decade before those services. When those services started bringing messagint to consumers, yes, they had some proprietary set-ups but that was not how it "originally happened" -- that was a short-term glitch in the much longer and more open history of email.
I am old enough to remember. Actually, because my mother worked at a university in engineering while I was in another city going to university, I could email her. It was crazy!!! My bestie and I then tried to figure out how it worked, and spammed the entire college with a "Happy Holidays Laidies" email. (It was a simpler time).
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.
There's a reason that sendmail exists, and that the sendmail book was so gigantic. Because it was terrible software, yes, but also because it was routing mail across a variety of different systems with different addressing rules and what have you.
Interesting. In fact, I do not remember that. I started using the internet some time in the 90s. I never used Compuserve nor AOL. I never heard about Prodigy.
Email has been around for a long, long time. Besides the major players, there were any number of mail and public post networks that ran on hobbyist bulletin board systems (FIDONet and WWIVNet are two that come to mind on the BBS end, and BITNET was a popular academic network before TCP/IP took over the world).
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.
Yep. They had long lists of phone numbers you could dial into; when you set up the software, it would set itself up to use one near you, so you wouldn't get charged long-distance fees.
At first I was inclined to have the same reaction to this news, especially concerning early rumours about this. Having read some more on it however, I now realize that it is somewhat of a knee-jerk reaction.
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.
The cynic in me winces when thinking of the mess all the banks and interested companies would make trying to get together and build a payment standard. Just look at the terrible mess of stuff like OFX.
Ah, a standard protocol where nobody implements the standard in the same way. As someone who has been working with FIX for few months, I could totally feel the pain.
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).
Well, the point of those payment systems is to make money out of fees and basically control the whole system. You cannot do that with decentralized payment methods.
Which is pretty irrelevant: what matters is whether banks/payment processors will accept it, and whether it interops with the payWave/payPass readers at merchants, which in turn depends on them installing them.
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.
I was just thinking about this the other day: contactless payments is the norm in Australia, having the highest adoption rate in the world[1] I would guess that between 75-90% of retailers accept it? It's always very frustrating when a retailer doesn't accept it.
100,000 contactless terminals across the country[1], the numbers for Pay usage in Australia would be very impressive.
The security is a little more complicated than that. There are dozens of in-application checks and controls which try to guarantee that you're who you say you are, that you're authorized to make the payment, that you have funds and that the amount to pay is within certain limits. Naturally, a stolen card could be used once or twice. But never for very high amounts and never very many times: the card will request PIN and then the thief is stuffed.
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).
> We've had high penetration of contactless in Australia for a long while now
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).
I still don't see how replacing a credit card (that can be used for contactless payment with Visa Paywave or Mastercard contactless) by a phone that may have a dead battery brings anything to the table.
#1 only makes sense if you ignored the word battery in the question. A phone makes a dreadful credit card. It's huge, it runs out of power, and it throws stack traces at the wrong moment.
I can leave home without my wallet. Seriously, cash/card and maybe my drivers license is the only necessary thing I need on the go most days. I can free up an entire pocket.
We have NFC like this in Canada, now. It works with our credit cards though, not our phones. Apple will use the same over-the-air protocol and more obfuscation to make the same transaction.
It's not a comprehensive protocol but worth noting the http does have 402 Payment Required which hasn't been used up to now, but could be implemented with BTC.
Japan has a flourishing NFC payment ecosystem, and it's strange it's completely left out on this announcement.
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.
Japan's NFC payment ecosystem is owned by Sony and DoCoMo. I highly doubt that Apple wanted to subject themselves to the license terms and/or the lack of technical control.
That system is also widely deployed but in my experience (9 years of living there, no evidence other than anecdotal) not widely used.
Docomo is pretty willing to open up their technology to expand the ecosystem (that's what they did with Softbank and au, and JR also has a part in it), because they know it would die if they kept it for themselves. And that's openly one of the role of BitWallet, the joint venture they made for the solution. Actually I really hoped they could do something with that outside of Japan.
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.
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.
> That system is also widely deployed but in my experience (9 years of living there, no evidence other than anecdotal) not widely used.
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.
Might be because of their redirection shenanigans, starting yesterday apple.com was a 301 (permanent redirect) to apple.com/live, might sudden changes back and fro be interpreted as phishing attacks?
I really hope this doesn't end up fragmenting the NFC payments space. Only Apple Pay is accepted in one place, and only Google Wallet is accepted in another. Both of these technologies work with contactless card readers, let's just stick with that.
It sounds like they both definitely work with your standard contactless card reader. My worry is that Apple will have an Apple only reader as well. I'm not saying that I think they will, but I wouldn't be surprised, either.
IDK, as long as it's NFC and the terminals have firmware that can get upgraded to support additional standards, they could make it work.
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'm hoping they stick to a standard that everyone else can use (ideally the existing ones we already have like PayPass).
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.
One implication of Apple Pay is it erodes advantages of leaders like Uber. Minimizing payment and account friction means trying a new service becomes much easier.
Exactly the opposite seems to be true. Uber had a presence in the keynote today with a way to ride without ever creating a login, which should enable lot more people to use the service. If you thought that the advantage Uber had was mostly was in minimizing payment friction, that would be pretty wrong.
It would be pretty wrong. Which is why that wasn't the statement. :) Especially for services like transportation, which are commoditizing faster than they're not, removing the need to create accounts and enter credit cards increases consumer willingness to try alternate services. For example, if an aggregator shows a Sidecar 2 min away and an Uber 10 min away, Apple Pay now makes it vastly easier for an Uber customer to try Sidecar for the first time.
It erodes, but also enables you to focus on your companies core competency rather than payments.
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.
Yes, though unlike the App Store, this will take much longer to unfold since there is so much infrastructure out of Apple's control. But Apple Pay should galvanize the payments and commerce industries, eventually leading to much greater competition among retailers and service providers -- and more benefits to consumers.
I think I'm missing something on this, but how is it possible Apple isn't storing credit card information on the device or their servers? How are they connecting the payments you make with Apple pay back to the credit card you choose to use.
This is done via credit card tokenization. Tokenization is a major boom to the payment industry. However, there is a lot of complexity and moving pieces for all of this to work. But once it works, it'll unlock a lot of potential for startups to innovate in the payment industry.
Curious to hear what innovations you see coming down the pipeline? The spec also discusses loyalty programs via tokenization, but no one has yet to implement them to my knowledge.
PCI compliance is a high bar that has limited a lot of innovation in real world transactions. Merchants are still using POS and payment terminals that are a decade old. Merchants have been quite reluctant to change this as it has been expensive and does not add value to them to upgrade.
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.
Given the target audience of that blog, those seem to be perfectly reasonable things to leave out. I mean, do you expect programming blogs to define 'API'?
I assume once they register your credit card number with the card provider, they have no longer any use for it. The connection between your card number and your apple id can be stored on the card provider side.
I'm guessing they have established relationships with the card issuer and will use your card number only once to establish the link, after which the card info isn't needed.
Google Wallet was terrible because you had to unlock your phone and enter a PIN, making it instantly way more cumbersome than swiping a card.
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.)
Agreed on Square, but they even went a step further for a time and allowed geofencing at your favorite places...back when Square Wallet was still around, I used to frequently go to a Houston-area coffee shop with Square Register and never had to pull my phone out to pay. It was downright magical...wish they hadn't cancelled Wallet, it really had so much potential.
That's not the real issue. The real issue is that it doesn't fulfill the promise of you not having to hold your cards anymore (unless you only shop at Walgreens).
In the short term, sure, but if there's sufficient uptake things might look different in a few years.
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.
Clipper uses a technology called "MiFare DESFire". I'm under the impression that mobile phones can read these, but can't emulate them for some reason. (But apparently they can emulate its predecessor, MiFare Classic, which is unencrypted?)
No idea if it'll be a bigger success, but some thoughts:
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).
A bit more on the timing: USA is finally switching to EMV based credit card payments (chip and pin) during this year and the next, meaning that most terminals will likely be able to accept NFC payments as well (Google Wallet, Apple Pay, whatever else that follows the spec)
Apple has three advantages. First, it's on iPhone, which is a ton of devices. Second, they already have your credit card because you've used it to buy apps or music, etc. Third, people will know this exists because of the media.
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.
Does Google Wallet have similar security features, such as not storing or transmitting your actual credit card number or your name, or use of a secure enclave in the phone hardware?
Yes and who cares? It still is not secure. Anyone who gains the virtual card number can use it and the merchant system can charge arbitrary amounts of money to it.
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.
I wasn't commenting on the security, just on the "blurts the magstripe information" comment. Apologies if you meant that metaphorically.
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?
That doesn't make any sense, no. Instead, they skip the secure element and transmit something non-standard (...by buying a bank and routing those through that, essentially acting as a proxy to the card networks?):
I can only guess: but I believe that this will fly if the iPhone 6 is a hit, but it could really soar if the Apple Watch sells very well. Paying with something on my wrist seems more natural (slightly better UX?). If the products end up 'failing' (which for apple means sell like iPhone 5C) then this will just drag on like any product from an extremely large company like Google or Apple that just lives because they can push it on users.
If it means that someone here in the UK can finally pay for something somewhere with an NFC-capable phone, then good! Google Wallet has been US-only for years (and I think the UK promises about its arrival never materialised, unless I am wrong?)
In any case, hopefully this will force the industry to move forward, particularly on Android.
One interesting unrelated development: the US is moving to chip-and-PIN cards next year. Merchants that don't move over to the new system (in other words, those that still take signatures instead of having you do the chip-and-PIN thing) will be responsible for fraud that occurs in their stores... so merchants will switch.
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...
Generally yes, although the cashier might be momentarily confused when the machine prompts her to get a signature since everyone else just uses their pin.
The only place it won't work at all is self-service kiosk.
It ought to, since some European customers have chip-and-signature cards for various reasons. There's no guarantee that shop employees will be properly trained on how to handle it though.
My Bank of America Visa recently expired, and the new one they sent me has what appears to be chip and pin. Weirdly, there is no information in the included pamphlet about the technology. I assume they're just preemptively putting the cards out there.
I have a Bank of America MasterCard that expired recently and they sent me a new card, but when you go to their information page about chip cards ( http://bankofamerica.com/chipcardfacts ) it seems pretty clear that it's actually chip and signature. They emphasize that if you get asked for a PIN, you should tell the merchant it only requires a signature.
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.
Stores are already installing them to conform to the upcoming chip and signature standard rolling out across the US. You can tap most of your credit cards instead of swiping at the small number of merchants that have rolled it out (McDonalds, Staples, etc).
Google Wallet required Carrier SIM support which forced consumers to actually go and get a SIM that supported it, as well as a handset that supported said SIM. Apple's solution does not require this and cuts MNO's out entirely
What is Apple's Cut going to be to use Apple Pay ?
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 ?
Saying that, I would love to have been a fly on the wall after last weeks iCloud celebrity photos hack.
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.
"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...
What I want to know, having a contactless card, is what do you do when the machine isn't working. You can't swipe it or use the chip in this case.
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.
I don't like taking out my wallet and dicking with cards mixed with insurance cards and IDs and other stupid things I need to keep on me in case I'm stopped by the gestapo.
My phone is already out anywhere I'm buying things. Makes sense to pay with that instead of fishing for something else.
Though I take your point about the backup options of swipe and chip, I'm guessing some Stratford mugger is just as happy mugging you for your wallet full of credit cards and cash as they are to bash you over the head for your iphone.
Can someone local find out where exactly the Antenna is? Nokia devices have been great at this with the touchpoint at the edges, which feels natural, while most Android devices have an awkward spot somewhere in the lower middle. Is it on the Apple logo? This may still make it feel awkward to use.
The Verge (among others) is reporting that the antenna is located along the top edge of the phone [1]. Photos of the Apple Pay gesture in action on the slides seems to corroborate 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).
Thanks! That sounds indeed as if they tried to optimize the experience. Watching people try finding the NFC sweetspot by swiping the bottom of their device around on a reader deviceis painful.
ApplePay is only on iPhone 6. This means that the availability rate for this technology will get into (tens of) millions in a couple of years, based on the update cycle with the phone carriers. Realistically we're talking 2-4 yrs. Plenty of time for providers to get acquainted with the technology and to integrate it into their retail systems.
For developers it would be interesting to see how the API looks like and if it will be available at all in any shape or form (which I doubt actually).
> For developers it would be interesting to see how the API looks like and if it will be available at all in any shape or form (which I doubt actually).
"the availability rate for this technology will get into (hundreds of) millions in a couple of years"
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.
Couldn't help smiling at this marketing messages from Apple about Apple Pay - “We have security integrated throughout both hardware and software in a way only Apple can." “Apple Pay is easy, secure, and private.”
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.
Apple pay is an interesting and natural move from Apple. They probably have the largest number of credit cards info on earth.
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.
I'm REALLY curious about this. Will they charge a transaction fee and have it as another revenue stream for them (like iTunes/App store)? Or is it going to be another commoditization of their competitor's/partners products in order to move more hardware (like iMessage). If it's the latter that would be a HUGE deal. I just can't imagine they would be able to resist taking a slice of that $12 billion/day transaction pie, though.
The implication from Tim was that Apple was not trying to make money off of this. He said that ApplePay would be successful because competitors tried to turn it into a profitable system for them, instead of focusing on making it work.
Looks like Apple's commission is ~15-25 BPS for participating banks (from those banks):
"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)."
In finance, 1 BPS is 1/100th of a percent. So Apple could be pocketing ~0.2% on all transactions.
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.
Slightly Off Topic, Does anyone know if there are any plans to speed up the NFC process? The current one being used by MasterCard and Visa are all very slow. It takes like 3 seconds, compared to Sony's Felica which happens under 0.3 seconds.
How will they actually accept the payment though? Apple Pay requires Touch ID (or Apple Watch), which is the consumer's device.
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 believe apple pay is just using same nfc infrastructure already in place for a while. The same infrastructure google wallet and others are targeting.
I imagine they would have to have a new device for chip/pin chip/signature anyway. My guess is they are just adding NFC to the new device while they are at it.
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).
Looks like Apple's commission is ~15-25 BPS for participating banks
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 am confused by this as well. I thought apple did not allow people to make credit card purchases within an app, am I wrong or will these rules change? Where is the line drawn for using an IAP vs Apple Pay (where I presume Apple takes no cut)
I think traditionally Apple has disallowed IAP for real-world goods. I'm assuming Apple Pay will be for those real-world goods while IAP is still used for digital goods.
Does anyone know why exactly payments in apps also require the iPhone 6? I thought that iPhone 5S also had a secure element for storing data (Touch ID).
You are wrong. Apple says there was no "security breach" except their lack of security for the FindMyIphone website caused the breach.
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.
Except the FMI flaw is only tenuously linked to the breach - with more evidence pointing away from it (i.e. timeline of how long the photos have been offered for sale, disclosures by other photo-hackers, etc) than toward it.
There was early speculation that the flaw was at fault, but no confirmation from anyone.
If the internet was invented today, we would have AppleMail instead of email and GoogleTrans instead of http.