Call for Single Media Type Design for Payments

This is coming a bit from left field. While I've been lurking here a while,
this is my first post.

TL;DNR
I think the best long-term approach for creating payment standards for the
Web is to define a single Payment Media Type; not create a set of
function-based APIs. It worked for the Call Control vertical (VoiceXML) and
it can work for payments, too. Hypermedia implementations are already
appearing including the Balanced company's use of JSON-API in their new
efforts.

IMO, this can enhance the groups principles of empowerment, portability,
etc. and I would be happy to start a strawman or join a group doing similar
work if this seems interesting.

Here's the longer version:

SINGLE HYPERMEDIA MODEL
A single, dedicated media type would allow all parties to "talk" to each
other without having to agree to specific function names and arguments
ahead of time. If the media type design relied on hypermedia controls
(links and forms) defined in a general way, vendors would be free to
introduce unique features over time w/o breaking or deprecating other
implementations.

CALL CONTROL INDUSTRY SUCCESS
This single hypermedia approach was what the Call Control Industry did with
CCXML and VoiceControlXML and it allowed switching, handset, and software
vendors in that space to get up and running quickly and keep the sector
vital w/o a great deal of over-specification and constraint. It's a format
that is still working well today, too.

HYPERMEDIA DESIGNS ARE INCREASING
In the last year several new hypermedia-style media types have been
registered w/ the IANA including HAL, Collection+JSON, Siren, JSON-API and
others. More developers are talking about and using hypermedia-style
messages in their API implementations. Payments can take advantage of this
early interest going forward. Balanced is already dedicated to using
hypermedia in their implementation (JSON API).

STAND ALONG MESSAGE MODEL CAN PROMOTE PRINCIPLES
The existing work on the payment ontologies need not change. Just like the
work on RDFa, work to design a format that supports the same vocabulary and
*also* includes actions (links and forms, not just data names) can go a
long way to meeting many of the design principles of empowerment,
portability, and promoting maximum competition.

STARTING WITH A STRAWMAN
If this kind of work sounds promising, I'd be happy to create a strawman
document as a point of focus in and discussion. If this kind of work is
already on-going, I'd be happy to join in.

Thanks for the chance to speak up and I look forward to future discussions.

Mike Amundsen

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund