Re: Web payments messaging and APIs

I haven’t had a lot of time to look over the spec, but I will say that discussion of having a web payments spec include NFC and offline proximity payments seems like something that drastically increases the scope of any work the WG has to do. There are many additional complications and factors involved for physical payments - I am not sure I agree with you when you suggest the messaging formats could remain the same and only the transport change, for example.

> On Sep 30, 2015, at 8:10 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> Hi all,
> 
> We've (Digital Bazaar) been doing a bit of experimental implementation
> work on the Web Payments and Credentials work and have found a data
> message and API pattern that seems like it might work for both
> implementation streams. The issues around previous attempts are
> explained here:
> 
> https://lists.w3.org/Archives/Public/public-webpayments/2015Oct/0001.html
> 
> All this to say that our internal experiments have led us 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.
> This is just a heads up to this group that work is progressing in that
> area and that we'll want to feed this thinking into the Web Payments WG
> TPAC agenda at some point.
> 
> -- 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 16:37:12 UTC