Re: Updated Web Payments Architecture Summary

Perhaps a better model is?

PaymentRequest
  - RecurringPaymentRequest which extends Payment Request with extra rules
about recurrence etc
  - RefundRequest which extends Payment Request with reference to original
payment
  - PaymentAuthorizationRequest (not sure of the use case here)
  - HoldRequest which extends the payment request by adding a data about
when to release the hold (conditions, timeouts etc)

Ito mapping to ISO 20022 I think we need to map out a real scenario where
ISO 20022 messages are part of the flow outside the Web (PaymentRequest)
interactions such as a SEPA credit transfer. If we do this we'll identify
where mapping from a PaymentRequest with SEPA CT as a payment method to the
actual ISO 20022 may encounter problems. Right now I don't think we have an
issue because the Payment Request is actually an envelope of sorts for the
subset of ISO20022 data required to initiate a payment so the ISO20022
stuff is actualy going to be in the payment method specs.

On 29 June 2016 at 01:49, Manu Sporny <msporny@digitalbazaar.com> wrote:

> 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
>
>
>