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

Hello all,

The use of 'terminal' is making me nervous (again). MNOs call the phone their 'terminal'. Payment people have a 'payment terminal'.

The payment agent running on a terminal would refer to the 'user payment agent' on the client device (aka phone)...right?

This would demonstrate the need to qualify the 'payment agent' with the word 'user' if we mean the payer, while a 'payment agent'  might just as well be implemented in the 'payment terminal' (on the merchant side).

... or is there any confusion on my side?

Cheers,
	Jörg

-----Original Message-----
From: David Ezell [mailto:David_E3@VERIFONE.com] 
Sent: Montag, 17. November 2014 18:22
To: SULLIVAN, BRYAN L; Manu Sporny
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: RE: Discussion - Payment APIs: others are thinking about this problem space, too

Hi Bryan:
Many payment applications (like the payment agent) may run on the terminal, but many components may run someplace else (off-platform).  An existing example is how some people do EMV processing on an external server using the ISO7816 messaging[1].

So all I meant was we could create a JSON or XML RESTful API to do payment agent functions, but it's a little convoluted to try to make those calls locally on the terminal.  Not impossible (I've done it myself in the past) but I'm not sure it's the most direct solution.

Best regards,
David

[1] I'm not necessarily suggesting we do this, BTW.

-----Original Message-----
From: SULLIVAN, BRYAN L [mailto:bs3131@att.com]
Sent: Monday, November 17, 2014 11:52 AM
To: David Ezell; Manu Sporny
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: RE: Discussion - Payment APIs: others are thinking about this problem space, too

inline

-----Original Message-----
From: David Ezell [mailto:David_E3@VERIFONE.com]
Sent: Monday, November 17, 2014 8:15 AM
To: Manu Sporny
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: RE: Discussion - Payment APIs: others are thinking about this problem space, too

Hi Manu:
1) WebIDL
     I understand the "handover" issue, but it is an essential work product, and not one that we can or should
     ignore.  I understand the point, but consider the following possibility:
     Based on WPAY work (some WG) that produces a WebIDL interface, Android developers create a Dalvik VM
     Interface (Java Classes) that are >isomorphic< to the WebIDL interface.  Then, any browser port becomes
     trivial, but the semantics of the interface are available for people working in native, hybrid, or pure HTML5
     environments.  I could conjecture similarly about iOS or Tizen or any other platform, but who knows.

2) RESTful WS
     I agree this one is important, but it tends to address only the "off-platform" use cases.

[bryan] David, what do you mean by "off-platform" use cases?

Best regards,
David

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com]
Sent: Friday, November 14, 2014 2:35 PM
To: David Ezell
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: Re: Discussion - Payment APIs: others are thinking about this problem space, too

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

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login http://manu.sporny.org/2014/identity-credentials/
________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Tuesday, 18 November 2014 14:39:10 UTC