Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Pay

apple.com

Post reply on HN
Print view View original

131–140 of 225 posts

Re: Apple Pay

#131

Post by Turing_Machine »

itry wrote: post #108
tfinniga wrote: post #101

Earlier quoted context omitted.

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.

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.

Probably more than you wanted to know. :-)

Re: Apple Pay

#132

Post by itry »

tfinniga wrote: post #126
itry wrote: post #108

Earlier quoted context omitted.

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.

I guess technically those were separate online services. They only connected up to the internet near the end of their lifetime.

You had to dial into AOL and Compuserve?

Re: Apple Pay

#133

Post by asadotzler »

tfinniga wrote: post #101
itry wrote: post #41

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.

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.

Re: Apple Pay

#134

Post by dcaunt »

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).

Re: Apple Pay

#135

Post by jarek »

itry wrote: post #117
eloisant wrote: post #113

Earlier quoted context omitted.

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. Really, what's the point?

1) 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.

> The credit card gives away data that can be used for fraud.

Not with chip and pin or contactless it doesn't

Re: Apple Pay

#136

Post by gregoire »

So one should use Apple Pay when paying in apps, but the credit card stored in iCloud Keychain when paying on the web? I find it a bit confusing.

Re: Apple Pay

#137

Post by mnglkhn2 »

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).

Re: Apple Pay

#138

Post by Johnie »

arfrank wrote: post #95
Johnie wrote: post #36

Earlier quoted context omitted.

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. http://www.emvco.com/specifications.aspx?id=263

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.

Re: Apple Pay

#139

Post by madeofpalk »

XorNot wrote: post #109
k-mcgrady wrote: post #96

Earlier quoted context omitted.

They use the same tech to communicate (NFC) but Apple's security features seem unique.

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 mer…

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.

[1]: http://www.smartcompany.com.au/finance/42250-australia-leads...

[2]: http://www.news.com.au/finance/money/australia-hooked-on-tap...

Re: Apple Pay

#140

Post by ctz »

BlakePetersen wrote: post #106
ctz wrote: post #91

Earlier quoted context omitted.

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 f…

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 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.
Post reply on HN