Re: Payment messages, browser APIs, and REST APIs

I'd love to help with the Web Payments (REST) API.

On Wednesday, September 30, 2015, 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?
>
> -- 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/
>
>
>