comments on web payment HTTP API and core message components

Dear all,

Please find below some comments. Of course, glad to discuss!

Core Message Components
The relation between the different core message components is missing. A UML alike data model would contain more and clearer information?
I would suggest for this document specify the entire resource(s) and the applicable methods on the resource(s)?


Core component

ISO20022

Note

FinancialAmount

CurrencyAndAmount or
ActiveCurrencyAndAmount


No negative amounts exist in ISO 20022. Whether the amount is to be debited or credited, depends on the context, not on the sign.
Fractional part is 5 digits max.
TotalDigits is 18.
In ISO 20022, there is the possibility to use a active currency code list(i.e. the currency has not been revoked/replaced...)


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...?
PaymentRequest
This could be the PaymentInstruction resource?

Web Payment HTTP API
Payment Flow Overview

1)      The roles mentioned do not correspond with the names in the swimlanes. Can we use consistent (ISO 20022?) terminology?


2)      "The payee provides a URL where a payment request for the resource can be fetched"
In a RESTful design, I would imagine the resource is the payment instruction (with at this stage contains only the information owned by the merchant, and lacking the info that the client still has to add. The client would then use a PUT to complete the payment instruction).


3)      See also my comment in the Core Components: would it not be better to specify all resources there (e.g.. The payment instruction with all its properties such as the payment method) as this structure (or part of it) will be the basis for any exchange between any of the participants defined in the swim lanes). This payment instruction is in a first stage partially completed by the merchant, and in the second step the customer completes the payment instruction and posts the payment to the PSP?

4)      Putting my ISO hat on ;) : The resource (ie. The payment instruction) can then be defined using ISO 20022 components. If they do not exist in ISO, we will submit them.


Glad to discuss of course!

Kris Ketels
SWIFT | Cloud Standards
Tel: +32.2.655.4485
Mob: +32.475.370.998
www.swift.com<http://www.swift.com/>

This e-mail and any attachments thereto may contain information which is confidential and/or proprietary and intended for the sole use of the recipient(s) named above. If you have received this e-mail in error, please immediately notify the sender and delete the mail.  Thank you for your co-operation.  SWIFT reserves the right to retain e-mail messages on its systems and, under circumstances permitted by applicable law, to monitor and intercept e-mail messages to and from its systems.