Page Comparison

...

• The POST action indicates to the ASPSP that a file payment consent has been staged. At this point, the Useruser/Customer customer may not have been identified by the ASPSP and the request payload may not contain any information of the account(s) that should be debited.

• The endpoint allows the PISP to send metadata of the consent (between Useruser/Customer customer and PISP) to the ASPSP .

• The metadata of the consent must include the FileContextFormat of the request.

• The metadata of the consent must include the FileHash, which is a base64 encoding of a SHA256 hash of the file to be uploaded.

• The ASPSP creates the file-payment-consent resource and responds with a unique ConsentId to refer to the resource.

...

• The endpoint allows the PISP to send a copy of the consent (between Useruser/Customer customer and PISP) to the ASPSP for the Useruser/Customer customer to authorise. The PISP must upload the file against the ConsentId before redirecting the Useruser/Customer customer to authorise the consent.

• The file structure must match the FileContextFormat in the file-payment-consent request.

• An ASPSP must confirm the hash of the file matches with the FileHash provided in the file-payment-consent Metadata.

• The metadata for the file-payment-consent must match the contents of the uploaded file:

  • If the content of the metadata does not match the content of the file, the ASPSP must reject the file-payment-consent.

• The file is sent in the HTTP request body.

• HTTP headers (e.g. Content-Type) are used to describe the file.

...

 A PISP can optionally retrieve a payment consent resource that they have created to check its status.

2.3.1 Status

Once the Useruser/Customer customer authorises the payment-consent resource, the Status of the payment-consent resource will be updated with "Authorised".

If the Useruser/Customer customer rejects the consent or the file-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".

...

...

• All elements in the Initiation payload that are specified by the PISP must not be changed via the ASPSP , as this is part of formal consent from the Useruser/Customercustomer.

• If the ASPSP is able to establish a problem with payload or any contextual error during the API call, the ASPSP must reject the file-payment-consent request immediately.

• If the ASPSP establishes a problem with the file-payment-consent after the API call, the ASPSP must set the Status of the file-payment-consent resource to Rejected.

• The DebtorAccount is optional, as the PISP may not know the account identification details for the Useruser/Customercustomer.

• If the DebtorAccount is specified by the PISP and is invalid for the Useruser/CUstomercustomer- then the file-payment-consent will be set to Rejected after Useruser/Customer customer authentication.

• An ASPSP may choose which fields must be populated to process a specified FileContextFormat, and may reject the request if the fields are not populated. These ASPSP specific requirements must be documented.

• An ASPSP may choose which fields must not be populated to process a specified FileContextFormat, and may reject the request if the fields are populated. These ASPSP specific requirements must be documented

...

• ConsentId.

• CreationDateTime the file-payment-consent resource was created.

• Status and StatusUpdateDateTime of the file-payment-consent resource.

• CutOffDateTime Behaviour is explained in Payment Initiation API Profile, Section -Payment Restrictions -> CutOffDateTime Behaviour.

• Charges array - for the breakdown of applicable ASPSP charges

• Post successful Useruser/Customer customer Authentication, an ASPSP may provide Debtor/Name in the Payment Order Consent Response, even when the Payer did not provide the Debtor Account via PISP

...