- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 28 Jun 2016 20:49:22 -0400
- To: public-payments-wg@w3.org
On 06/27/2016 09:28 AM, Adrian Hope-Bailie wrote: > ISO20022 defines the term payment instruction and I don't believe > what we have defined as a Payment Request is the same thing. Here's the ISO 20022 definition for PaymentInstruction: https://www.iso20022.org/standardsrepository/public/wqt/Content/mx/dico/bc/_FDFRYsTGEeChad0JzLk7QA_-398781926 After reviewing it in more detail, I agree with AdrianHB. That said, I don't think this addresses the issue at hand. We need to spend some time as a group understanding what the ISO20022 RA needs from us and how the work we're doing is going to fit into the work the ISO20022 RA folks are doing. They've mentioned that they will register new types that we create in ISO20022, but I'm not sure we're designing something that's fit for inclusion into ISO20022 (yet). Some further thoughts below... > I like the terminology we have used because it is accurate in > describing what the purpose of that message/data is. It is a request > for a payment. Importantly it is not a request to MAKE a payment or a > request to AUTHORIZE a payment. The request is simply that a payment > happens and the payment method chosen by the payer defines the action > that must be taken both by the payer and the payee. The model that was chosen (PaymentRequest) is okay for a certain subset of use cases. I'm not certain it's okay for subscription requests (recurring payment requests), refunds (reverse payments), pre-authorizations, holds, and other sorts of payment actions. Another way of asking this question is - what is the base type? PaymentSomething <-- What are we calling this? - One Time Payment <-- PaymentRequest today - Recurring Payment - Refund - Pre-authorization - Hold -- manu
Received on Wednesday, 29 June 2016 00:49:50 UTC