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

As far as I know the only methods for calling apps that are pretty
universally supported (iOS, Android, Win Phone) are custom URL protocols
right?
Is anyone aware of other's?

I am aware of a number of apps that register themselves as custom URI
protocol handlers as a means of exposing an "API" instead of having an SDK.
iZettle was a good example (https://github.com/iZettle/URL-Scheme) although
I see now that they do offer SDKs.

There are some advantages to such an approach (most obvious being that they
work today on even very old phones) but I know that they make some people
very uncomfortable.
I think this warrants deeper discussion as an approach to bridging the web
and native worlds.

On 3 March 2015 at 09:12, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> 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/
>>
>
>
>