W3C home > Mailing lists > Public > public-webpayments@w3.org > October 2015

Re: Payment messages, browser APIs, and REST APIs

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Thu, 1 Oct 2015 23:45:32 +0200
Message-ID: <CAKaEYhJzp1yU8-5OD6JY0V2ecR9iY=P51Bwh-oZ-1oktbwp9Gw@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Web Payments <public-webpayments@w3.org>
On 1 October 2015 at 05:04, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hi all,
>
> We've been doing a bit of implementation work on the Credentials and Web
> Payments work and have found a data message and API pattern that seems
> like it might work for both implementation streams.
>
> To date, we've tried to specify how a browser could execute a payment or
> credential flow using a polyfill via the use of HTTP POST/GETs, which
> results in very strange form-encoding hacks to attempt to get around
> deficiencies in the way you move JSON/JSON-LD data around the web via a
> browser.
>
> This led us to design browser APIs that also relied on REST APIs to get
> the job done. As Adrian pointed out in the previous post in the Web
> Payments API thread, this is problematic for a variety of reasons. Among
> them being that it feels awkward to Web developers because it requires
> one to mix Promise-based calls with REST API calls in an unnatural way.
>
> So, our thinking has evolved on this topic and that has led to splitting
> the messages from the Web Payments API into a separate spec called:
>
> Web Payments Messaging
> https://web-payments.org/specs/source/web-payments-messaging/
>
> The Web Payments Messaging spec defines the basic messages that
> constitute the Web Payments ecosystem. They include messages for
> registering payment instruments, initiating a payment (payment request),
> and acknowledging the initiation of a payment (payment request
> acknowledgment).
>
> The messages themselves are then routed to where they need to go using
> protocols that are tuned to their environment.
>
> For example, modern browser code typically uses things like Promises to
> abstract how information flows. Browser polyfills typically use
> postMessage() instead of HTTP POST/GET.
>
> Server to server, or client-server communication that is non-browser use
> REST APIs.
>
> Proximity and offline use cases depend on technologies like Bluetooth
> Low Energy and NFC to route payment messages.
>
> Payments flow over all three example protocol types above and it's
> important for us to take that into account and architect the solution
> that the Web Payments WG is calling for with that knowledge in mind.
>
> So, it feels as if we're going to have at least these specs:
>
> Web Payments Messaging
> https://web-payments.org/specs/source/web-payments-messaging/
>
> Web Payments (Browser) API
> https://web-payments.org/specs/source/web-payments-api/
>
> and may eventually have specs for:
>
> Web Payments (NFC) API
> Web Payments (BTLE) API
> Web Payments (REST) API
>
> While that may seem like a lot of APIs, the APIs themselves are very
> simple and lightweight. Most or all of the declarative stuff is carried
> in the messages themselves. This is somewhat how ISO20022 is
> architected, except that those specs don't really get into
> implementation details like we'll have to for an open Web standard.
>
> This approach seems to be working out pretty well in practice so far.
> What are the thoughts from the community? Has anyone found this approach
> to be a good way of doing things? Any concerns about this approach?
>

+1

I've been working on this assumption already.


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
>
>
>
Received on Thursday, 1 October 2015 21:46:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:43 UTC