W3C home > Mailing lists > Public > public-payments-wg@w3.org > June 2016

Re: comments on web payment HTTP API and core message components

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 17 Jun 2016 22:52:52 -0400
To: public-payments-wg@w3.org
Message-ID: <5764B784.1010403@digitalbazaar.com>
Hi Kris,

Apologies for the long delay in responding, we were waiting for the
Browser API to settle before working on the core messages and HTTP API
again. Responses to your request for changes below:

On 05/03/2016 01:25 PM, KETELS Kris wrote:
> *Core Message Components*
> The relation between the different core message components is 
> missing. A UML alike data model would contain more and clearer 
> information?

Yes, that's true. I've tried to mock up what this would look like for a
Payment Instruction. Let me know what you think:


Commit is here:


> I would suggest for this document specify the entire resource(s) and 
> the applicable methods on the resource(s)?

Doing that would duplicate a lot of information. For example, we'd end
up repeating the same text for paymentAmount in the PaymentInstruction
and the PaymentResponse sections. Repetitive text in W3C specifications
is typically frowned upon. Since these are technical specs, duplicated
text means that if there is a bug you have to fix it in more than one
place and, as a result, specifications are prone to building up more
errors over time.

What I've done instead is put the core messages at the top of the
document with the components below. The hope is that this will lead to a
more complete understanding faster.


> Core component FinancialAmount No negative amounts exist in ISO 
> 20022. Whether the amount is to be debited or credited, depends on 
> the context, not on the sign.

Fixed. Removed support for negative amounts.


> Fractional part is 5 digits max. TotalDigits is 18.

Since this specification is about data model, we shouldn't put arbitrary
restrictions on values unless it makes sense to do it at the data model

The restriction that you are talking about sounds like implementation
details leaking into the data model. The right place to put that
restriction would be in the application layer (for example, when
converting one of these messages into an ISO20022 message.

What was the rationale for limiting this value in ISO20022?

> In ISO 20022, there is the possibility to use a active currency code
>  list(i.e. the currency has not been revoked/replaced...)

We don't currently have a use case for active vs. inactive currency
codes for Web Payments, so I hesitate to add it until we do.

> *Core Messages*
> How about specifying these calls using the http calls get, post etc…
> /AcceptablePaymentMethod/
> Why not call this PaymentTerms or PaymentMethodTerms? i.e. remove 
> Acceptable (no bearing) and add Terms (as this is what it seems to 
> cover).
> Then we can have e.g. get PaymentMethod; post PaymentMethod etc...?

Changed to "PaymentTerms":


I think HTTP GET'ing and POST'ing PaymentInstructions makes sense. I'm
not so sure doing that with PaymentTerms makes sense. Am I missing what
you were asking for?

> /PaymentRequest///
> This could be the PaymentInstruction resource?



-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern
Received on Saturday, 18 June 2016 02:53:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:17 UTC