Re: Android Pay Is Real, And Will Give Developers The Reins As An API

This is interesting and expected as well.

Now the W3C should look into how you can interact with the "App World" from the "Open Web" because that's a universal problem.
Making specific payment APIs for the Web (if that's the plan...) would be a waste of time regardless if the actual payment resource is local or server-based since each payment resource still would have a local representation in the wallet / Pay system.

Here is another example of what I'm talking about: A browser-based credential management system:
https://w3c.github.io/webappsec/specs/credentialmanagement/
A "Login App" would do this in a nicer way, be extensible and not require any browser standardization work (assuming there is a universal interaction system).
Not even Google gets it right all the time :-)

Note: You can do all of this today but the methods for calling "Apps" are quirky, unreliable and non-standard.

Anders

On 2015-03-03 01:10, Melvin Carvalho wrote:
> Google’s Sundar Pichai essentially used today’s Mobile World Congress keynote to let the cat out of the bag for a whole host of interesting Google projects, including Android Pay, a new mobile payments framework that will look to succeed where Google Wallet failed. This time, they’ll be mostly leaving the apps themselves to developers, and Android Pay is intended primarily as a developer tool made available via API, rather than a centralized app like Apple Pay, for instance.
>
> Android Pay sounds like it’ll offer one half of what Apple Pay is on the iPhone, providing users with a way to store their payment information locally, and make it available securely to third-party developer apps via API. Those apps will then determine when and where you can use the payment cards, via store (and perhaps payment provider) specific apps that can be branded however third parties like.
>
> Google’s system will tokenize card numbers, in the same way that Apple Pay and Samsung Pay do, meaning it generates a one-time payment token for transmission to the receiving terminal for each transaction, rather than just offering the user’s static credit card information. This decreases the risk if the transmission is intercepted, since a one-time token with finite expiry is of no use once it’s already been consumed.
>
> Like Apple Pay, Google’s Android Pay will use NFC for transmission, and will also support biometric authentication via hardware like the Samsung Galaxy S6’s fingerprint scanner. And while Samsung is clearly hoping to offer its own hardware-specific solution, Google’s offering is looking to convince businesses to adopt it by giving them a lot of freedom in how it’s presented and integrated into their brand. Pichai told the MWC crowd today that it’s not meant to compete with Samsung’s offering, however, and is intended primarily to offer up more consumer choice.
>
> There’s no timeline on a release as of yet, but expect to hear more about the particulars of Android Pay when Google hosts its annual I/O developer conference in May.
>
> http://techcrunch.com/2015/03/02/android-pay-is-real-and-will-give-developers-the-reins-as-an-api/

Received on Tuesday, 3 March 2015 07:13:18 UTC