Payment messages, browser APIs, and REST APIs

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/

Received on Thursday, 1 October 2015 03:04:33 UTC