Re: GSMA Mobile Payments API

On 15 December 2016 at 08:28, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 12/14/2016 04:52 PM, Adrian Hope-Bailie wrote:
> > Interesting to compare this with the HTTP API and also consider in
> > the work being done at SWIFT re JSON and REST:
> > https://mmapi.gsma.com/
>
> Thanks for the link AdrianHB, and for the offer to have folks working on
> this API to present at a future meeting, Natasha.
>
> I've done a very quick walk through of the spec and here are some
> initial thoughts:
>
> The Mobile Money API has more to do with SWIFT/Open Banking/PSD2 style
> account management than it has to do with work the Web Payments WG is
> doing. That is, the primary purpose seems to be in managing accounts,
> balance, billing, debits, quotations, and other items related to sending
> and receiving money via a mobile phone. At the risk of being overly
> broad, replace "mobile phone" with "bank account" and you have the
> general thrust of some of what the Open Banking APIs and PSD2 are going
> after wrt. JSON and REST.
>
>
Yes and no. Agreed that this is very much in the domain of the PSD2 bank
APIs (in fact it is exactly what I'd expect to see for this but for MFS
providers not banks).

However, if you look at the transaction API it is a payment API:
https://mmapi.gsma.com/transactions/

i.e. You POST a new transaction to create a payment.


> The Web Payments HTTP API and the Mobile Money API overlap in the
> following ways:
>
> * Bills API
> * Bill Payments API
> * Quotations API
>
> The Bill Payment API is far simpler (in a good way) than what we have
> created for the PaymentRequest object. The former being focused just on
> the payment amount (like the Web Payments CG proposal) while the latter
> is focused more on ecommerce scenarios (aka PaymentRequest API). What
> we're doing in the Web Payments WG is a combination of the Bill Payments
> API and bits and pieces of the Quotations API. Where the GSMA approach
> is more modular and encompassing, the Web Payments WG approach is more
> monolithic and focused.
>

I don't really understand your conclusion here.
What about the PaymentRequest API is similar to the Billing API?


>
> We will certainly pull this information in when doing the next revision
> of the Web Payments HTTP API, but seeing the desire and emergence of
> other HTTP-based payment APIs -- Mobile Money HTTP API, Open Banking
> HTTP API, and SWIFT HTTP API -- I hope it's becoming increasingly
> apparent to folks why having an HTTP API is an important part of the

ecosystem.
>

I think the things worth looking at include the data models defined in this
API and how these compare to other data models like ISO20022. For each API
function there is a list of "Supporting Objects" we should consider
carefully.


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Rebalancing How the Web is Built
> http://manu.sporny.org/2016/rebalancing/
>
>