8 ms·
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 t
by itry 12y ago
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.
- polynomial 12y agoIt'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.
- tdicola 12y agoThe 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.
- dclusin 12y agoFIX
- itry 12y agoBitcoin might be a way around this. 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?
- shitlord 12y agoMost people either haven't heard of Bitcoin or regard Bitcoins as "internet fun bux". It's not happening (at least, not in 2014).
- netrikare 12y agoWell, 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.
- serve_yay 12y agoYou say this like just nobody tried till now. Well, they did try. What happened after they tried?
- pkulak 12y agoGoogle Wallet uses exactly whatever standard let's you tap a credit card to a contactless payment terminal. I assume Apple Pay is the same thing?
- k-mcgrady 12y agoThey use the same tech to communicate (NFC) but Apple's security features seem unique.
- XorNot 12y agoWhich 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.
- madeofpalk 12y agoI 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. [1]: http://www.smartcompany.com.au/finance/42250-australia-leads-the-world-for-contactless-payment-but-cash-still-king-for-small-transactions.html http://www.smartcompany.com.au/finance/42250-australia-leads... [2]: http://www.news.com.au/finance/money/australia-hooked-on-tap-and-go-payments-visa-paywave/story-e6frfmci-1226821426268 http://www.news.com.au/finance/money/australia-hooked-on-tap...
- cynix 12y ago> 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).
- ctz 12y agoThe 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.
- BlakePetersen 12y agoGoogle 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?
- tfinniga 12y agoGoogle 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.
- BlakePetersen 12y agoSilent 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.
- seanflyon 12y agohttp://xkcd.com/927/ http://xkcd.com/927/
- tfinniga 12y agoYou 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.
- itry 12y agoInteresting. 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.
- tfinniga 12y agoI guess technically those were separate online services. They only connected up to the internet near the end of their lifetime.
- itry 12y agoYou had to dial into AOL and Compuserve?
- smacktoward 12y agoYep. 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.
- Turing_Machine 12y agoEmail 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. Probably more than you wanted to know. :-)
- eloisant 12y agoI 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. Really, what's the point?
- itry 12y ago1) One thing less to carry around 2) The credit card gives away data that can be used for fraud. Your phone does not have to do that.
- jarek 12y ago> The credit card gives away data that can be used for fraud. Not with chip and pin or contactless it doesn't
- thrownaway2424 12y ago#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.
- jsmeaton 12y agoI 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.
- r00fus 12y ago> 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.
- DCKing 12y agoAt 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.
- nathanvanfleet 12y agoWe 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.