Relationship between requiredResponseFields and PR API flow

[ianbjacobs]

The specification includes a definition of requiredResponseFields. @mattsaxon points out that the following might happen:

• A payment app matches on the payment method and the requiredResponseFields capability.
• The user authorizes the payment
• The payment app may not be able to return all of the requiredResponseFields.

Matt's original text (from a note in the spec) was: "The above field is required, but this can result in failed payments after 'Authorise' clicked. Should we have a better modelling (e.g. using subclasses) to allow for a more fine-grained matching of apps to requests? Does the PMI specification need to support this? "

I would like to better understand the flow Matt has in mind.

Ian

[CYV]

Let me explain what I understood. After being waked up by the browser, the basic-credit-transfer App is supposed to gather the autorization of the user and to initiate the credit-tranfer at the payerBank. To initaite the credit transfer, the App will connect to the API of the payerbank (often named in Europe DSP2-API). As the DSP2-API is not standardised, we possibly have issues to match fields with the requiredResponseFields.

To my perspective, this is not an issue :

• few fields are required in the ResponseField and most of the DSP2-API in construction have more reponse fields
• in other context, the Basic-credit-transfer could easily be duplicated to create a "specific-credit-transfer".

[mattsaxon]

@CYV, I believe you are correct entirely.

@ianbjacobs, @CYV, the use of requiredFields could allow to not need to create a specific-credit-transfer.

[ianbjacobs]

Hi @mattsaxon,

You assigned an action to me but I'm not sure what it is. Could you clarify? Thank you,

Ian