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

Dear  all,

On top of the comments already provided by Kris, please find below a couple of additional comments, related to the harmonisation with ISO 20022:


-          Core components:

o   the level of granularity is not the same as the core components defined is ISO 20022 - core components described in the proposal are the basic data types used in ISO 20022, such as amounts. Core components in payments in ISO 20022 are more at the level of  a party, an organisation, a financial institution, a mandate, an authorisation, or a financial instruments. Those core components are then composed of the elements required in a classical payments chain, e.g. for a party, the name, the address, the identification (which themselves are also core components). Those core components are directly derived from the Business Components, which are defined to described the ISO 20022 business flows.

o   ISO 20022 makes a clear difference between the logical layer, which defines the "what" in the implementation from the technical layer, which is the "how": xml, Jason - I would suggest that in the w3c specifications we keep the same separation. This would actually allow to define the "what" (the core components) in a generic way and leave the actual technical implementation up to the providers.

For the purpose of the ISO 20022 harmonisation, I personally believe that the proposal goes into the right direction, if the document is extended and  comments are taken on-board, and it should be taken up by the working group.



-          Web Payment HTTP API:

o   On top of Kris' comments, I have also some doubts about the consistency of the naming conventions,  but I have one specific question: how does this integrate with the work performed already in the flow task force.

o   One very positive aspect brought up by this document is the fact that the scope is not limited to cards transactions, but allows to the extension of any payment instrument, including credit transfer, but possibly also future payments instruments that could pop-up in the future.


Glad to discuss of course!
Best Regards,
Vincent
Vincent Kuntz
Senior Business Analyst, EMEA, Standards
Tel: + 32 2 655 3353
Fax: + 32 2 655 4552
Email: vincent.kuntz@swift.com<mailto:vincent.kuntz@swift.com>
SWIFTStandards<https://www.swift.com/standards> | Save our trees: think twice before printing. Thanks.
S.W.I.F.T. SCRL | Avenue Adele 1 | B-1310 La Hulpe | Belgium
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. Please visit www.swift.com<http://www.swift.com> for more information about SWIFT.

From: KETELS Kris
Sent: mardi 3 mai 2016 19:25
To: Web Payments Working Group
Cc: KUNTZ Vincent; KETELS Kris
Subject: 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.