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

> [1]
http://payxintl.com/payments-apis-the-last-mile-to-realising-the-holy-grail-in-payments/

It's good to see big players are thinking in terms of APIs, although I got
the impression that they are not so focused on standardizing an API but on
integrating one or more vendor-specific APIs into their ecosystems. I think
the actual Holy Grail would be, as Stephane mentioned, a standardized
RESTful web service that creates a level playing field for all actors that
decide to implement it.

I don't really know how such an API should look like, so it would be
interesting to hear opinions on that. My particular approach can be found
at: https://github.com/playbanq/WebWalletAPI#the-webwallet-api.

Cheers,


Jorge Zaccaro
Founder, Playbanq SAS
Bogotá D.C., Colombia

+57 300 673 0039
+1 650 614 1707
www.playbanq.com

On Fri, Nov 14, 2014 at 5:14 AM, <Joerg.Heuer@telekom.de> wrote:

> Hello all,
>
> Indeed, I see the developments in this space largely complementary to the
> 'UPA' TF. There are a few points I think we can learn from that already:
> - individual protocols for carrying out payments will come up anyway, and
> they will come from sources much deeper involved into payment/ merchant
> interactions than the W3C usually is
> - Any approach from individual company or group of companies should be
> scrutinized as to whether they will open up another silo or whether they
> can be integrated in a UPA
>
> Examples: VISA and MasterCard individually introduced ways to integrate
> loyalty functions with their respective credit cards. This created new -
> although 'beefed-up' - silos, restricting the use of certain loyalty
> programs with certain payment instrument. IMO these need to be supported by
> a legacy-proof UPA design, but inherently should open up a way to let the
> user and the merchant decide freely what combinations of payment and
> loyalty the want to use/ support in a given transaction.
>
> The solution from our side must, thus, be to aggregate payments and
> loyalty in the UPA design, leaving it to payment services and loyalty
> services respectively to integrate themselves into the agent. This should
> give the user more transparency and give everyone in the ecosystem more
> control. While not forcing anyone into the approach, these arguments should
> favor the more open (often de-composed) options over time.
>
> Compare the T-Labs 'architecture slide #15 here:
> https://www.w3.org/Payments/IG/wiki/images/a/a5/141027_T-Labs_Wallet_TPAC_1_1.pdf.
> Discrete Items for payment and loyalty would be represented by individual
> meta-data sets, making the whole process clear to all involved parties. If
> a combined payment/ loyalty function was implemented in a functional
> module, things may well be handled in the respective backends - delivering
> a nice and 'tangible' experience for the user would, however, be much
> harder to do.
>
> Does that make sense to everybody?
>
> Cheers,
>         Jörg
>
> -----Original Message-----
> From: Stephane Boyera [mailto:boyera@w3.org]
> Sent: Freitag, 14. November 2014 08:13
> To: David Ezell; public-webpayments-ig@w3.org;
> public-webpayments-comments@w3.org
> Subject: Re: Discussion - Payment APIs: others are thinking about this
> problem space, too
>
> The article of payxintl is very interesting.
> As we can all see, the domain is moving quickly. This is a great momentum
> for the group. At the same time, it is also more pressure on us to move at
> the pace of the industry.
>
> It is important to highlight not only the importance of API, but the
> importance of open standardized API that can create a level playing field
> for all actors.
>
> In all cases, I think we have to move further down and look into which API
> for what purpose, carrying which data etc.
> The first diagram we put on the payment agent task force is a very very
> first step in that direction. I believe we need to see if we can build a
> consensus on such a high-level view, and then start to look into each
> individual module that will help identify the needs in terms on API.
>
> steph
>
> Le 13/11/2014 20:54, David Ezell a écrit :
> > Dear IG:
> >
> > Here is a recent article on APIs in payment[1].  The point is that
> others are thinking about this problem, too.
> >
> > 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.
> > 2) RESTful web services for other as yet TBD goals.
> >
> > Examples of this second group would include discovery of payment
> services, potentially with dynamically changing API components.  Just one
> idea.
> > For discussion specific to area #1 be sure to use the [payment_agent]
> tag at the beginning of your subject line.
> >
> > We need to generate some concrete ideas and get the ball rolling.
> >
> > Best regards,
> > David Ezell
> >
> > [1]
> > http://payxintl.com/payments-apis-the-last-mile-to-realising-the-holy-
> > grail-in-payments/ [2]
> > https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force
> >
> > "Energy is more efficient than efficiency." - attributed to FDR
> >
> >
> > ________________________________
> > 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.
> >
>
> --
> Stephane Boyera        stephane@w3.org
> W3C                +33 (0) 6 73 84 87 27
> BP 93
> F-06902 Sophia Antipolis Cedex,
> France
>
>
>