Re: Discussion - Payment APIs: others are thinking about this problem space, too

Hello Anders,

Besides the fact that T-Labs belong to a rather large multi-national corporation themselves, I can confirm your observations in general. In this particular case, things might have already developed into a more 'standards-friendly' situation, however.

A few observations and corollaries:

- Despite the fact everybody we met over the last seven years expects a digital wallet to become commonplace in some near future, it hasn't turned into reality yet.

- Neither the countless endeavors carried out by mobile carriers, nor Internet giant Google have been able to achieve a significant success in the market

- Even Apple faces a hard time introducing their version of a wallet and payment service, despite its most modern architecture and significantly lower entry barriers for partners and customers

- in the MNO scene we are seeing a dramatically increased willingness to collaborate with their competitors and partners. T-Labs have started with a very web-oriented and open approach towards wallets early on. Over time more and more companies and influential individuals have approved of this view on wallets - in reality the urge to exert some level of control over this promising 'new' ecosystem was too strong to change ways quickly. Globally, sunk costs in this field amount to Billions easily.

- Only since early 2014 we were asked (finally) to help driving standardization and openness in this field, allowed to share our experiences.

- W3C has the unique chance to build the bridges between all those 'failed kingdoms' to form one ecosystem for all those - and many new - contenders on a level playing field. My team has been able to show that technology needed to create systems for this vision is already there. Integration is painful today as standards are missing, it is unclear who will take over which of the new roles in that ecosystem. As in every ecosystem there will be winners and losers over time.

- I as a person, I have never waited for any monopoly to bring us the sacred solution. Through our work I have certainty that a real ecosystem solution is possible, with various players in different roles per industry, per region, culture and legislation. This heterogeneity has to be heeded.

-> So any attempt to bring >the Internet payment solution which replaces our wallets< is futile IMHO. A web-based technology basis for the creation of interoperable wallets, open for hundreds of existing and innovative payment, identity and entitlement services on the other hand is technically feasible.

In my eyes It is possible to fulfill the vision laid down in the charter of this IG; not with an individual payment solution or protocol, but with the foundation for a plethora of solutions which are interoperable, user-friendly and economically sustainable.

Cheers,

Jörg Heuer

DEUTSCHE TELEKOM AG
T-Labs (Research & Innovation)
Dipl.-Inform. Jörg Heuer
Research&Innovation Director Payment&Transactions, Innovation Policy
Winterfeldtstr. <x-apple-data-detectors://0/0> 21, 10781 Berlin<x-apple-data-detectors://0/0>
+49 (30) 8353-58422<tel:+49%20(30)%208353-58422> (Tel)
+49 (170) 576 26 12<tel:+49%20(170)%20576%2026%2012> (Mob)
+49 (3915) 80243910<tel:+49%20(3915)%2080243910> (Fax)
E-Mail: joerg.heuer@telekom.de<mailto:joerg.heuer@telekom.de>
www.telekom.com<http://www.telekom.com/>

LIFE IS FOR SHARING.

DEUTSCHE TELEKOM AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: Timotheus Höttges (Chairman),
Reinhard Clemens, Niek Jan van Damme, Thomas Dannenfeldt,
Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn

BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.


Am 15.11.2014 um 08:20 schrieb Anders Rundgren <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>>:

Manu,
I think this discussion highlightes what I have tried to say which
is that standardization of payments probably is the most difficult
target you can possible find!

Anyway, standardization has never been a level playing field, nor a
democratic process or even a quest for the best possible solution.

With SuperProviders like Apple and Google (and Alibaba on the horizon)
it just got worse.

The limited information available around the Google Wallet and Apple Pay,
also shows that the W3C members aren't mentally ready for standardization,
i.e. whatever we do it will be a "rebel" effort or even more likely a no-go.
Gemalto is participating in the IG because they have a wallet but they
haven't submitted the specs...very useful indeed.

I would personally consider schemes that *compete* with established
payment industry but that is something W3C can't do so therefore it
seems that the whole W3C payment standardization thing is toast.

Regarding polyfilling as a solution, I think this is a hard sell when
the SuperProviders can add whatever feature they need using an army of
developers and then get it distributed as an automatic update.
You can't replace security elements with polyfilling and for payments
that's a show-stopper.

Apple Pay is the new yardstick for the payment industry.

Anders

On 2014-11-14 20:35, Manu Sporny wrote:
On 11/13/2014 02:54 PM, David Ezell wrote:
As I see it, there are two levels of API with which we are
concerned:
1) Interfaces for the "payment agent"[2] - probably WebIDL defined
interfaces.

I'm always concerned when this comes up because it has fantastic
potential for vendor lock-in. For example, if we create the WebIDL
interfaces in such a way that only the browser manufacturers can
implement them, then we will fail for at least two reasons:

1. We will fail because the browser vendors may drag their feet to
   implement it, and more importantly
2. We will fail because it won't create a level playing field, it'll
   make it so that the browser vendors determine the payment landscape
   on the Web.

WebIDL is a great way to hand an enormous amount of power over to the
browser vendors.

So, when we talk about WebIDL interfaces, we should build them in such a
way as to avoid vendor lock-in. That is, any WebIDL we provide must be
implementable in pure JavaScript w/o waiting on the browsers to implement.

Just pointing out what should be a show-stopper for every payment
company that isn't a browser vendor.

2) RESTful web services for other as yet TBD goals.

I think this is a better approach. RESTful web services coupled with
WebIDL APIs that can be implemented in pure JavaScript. That removes
many technical barriers to adoption and doesn't put this group in the
position of waiting for any particular organization or industry to get
off their keister and open themselves up to competition.

We need to generate some concrete ideas and get the ball rolling.

Some concrete ideas:

https://web-payments.org/specs/source/roadmap/


-- manu