RE: Web payments messaging and APIs

Another question that popped up:
Given all scenarios/api’s are defined in that document, what is the remit of the WPWG?

tx

From: KETELS Kris
Sent: 01 October 2015 08:13
To: 'Manu Sporny'; Web Payments IG
Subject: RE: Web payments messaging and APIs


Dear Manu, dear WPIG,



I had a quick look at the links mentioned below.

My upfront apologies if my reading these documents have led to the wrong conclusions if there are other documents posted somewhere that contain the answers to my question.

The payments API 1.0 document contains the scenarios/transactions to govern web payments.

These calls / scenarios have no relationship with ISO 20022. Why is that?



Tx

Kris



-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com]
Sent: 01 October 2015 05:11
To: Web Payments IG
Subject: Web payments messaging and APIs



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/