Skip to content

Latest commit

 

History

History
149 lines (106 loc) · 10.4 KB

Release_notes_2.7.adoc

File metadata and controls

149 lines (106 loc) · 10.4 KB
Raw

Release notes v.2.7

Table of Contents

  • Bugfix: Consent-related endpoints return incorrect HTTP status code on providing unknown consent ID

  • Bugfix: Validate entryReferenceFrom and deltaList parameters in Read Transaction List request

  • Bugfix: Сreate consent request and update PSU authorisation request returns empty list of scaMethods in response

  • Bugfix: Accept AuthenticationType from ASPSP even if it is not described in Specification

  • Bugfix: Validate bookingStatus query parameter in Read Transaction List request

  • Bugfix: creditorAddress property is provided to the SPI in payment object even if it was not present in the request

  • Added validation of accept header for getting transaction list (GET /v1/accounts/{account-id}/transactions)

  • Bugfix: Get Consent request doesn’t return mandated lastActionDate attribute in response body

  • Bugfix: Payment Cancellation Request update

  • Bugfix: Periodic payment can be created with invalid dayOfExecution tag

  • Bugfix: Links startAuthorisationWithPsuIdentification and updatePsuIdentification should be never used in responses

  • Delete accounts field in PiisConsentEntity, deprecated methods and piis_consent_acc_reference table

  • Delete createAuthorization method in AisConsentAuthorisationServiceBase

  • Bugfix: Get Cancellation Authorisation Sub-Resources request (GET /v1/{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations) returns wrong JSON format

  • Bugfix: authorisationId field is not provided in the responses

  • Bugfix: Fixed count usage of frequencyPerDay for one-off consents for every account endpoint

  • Bugfix: Read Transaction List request returns empty lists with transactions

Bugfix: Consent-related endpoints return incorrect HTTP status code on providing unknown consent ID

From now on, AIS endpoints that take consent ID as a path parameter will return CONSENT_UNKNOWN error with HTTP status code 403 instead of 400 if the consent couldn’t be located by the provided ID.

The following endpoints were affected by this change:

  • Get Status Request (GET /v1/consents/{consentId}/status)

  • Delete an Account Information Consent Object (DELETE /v1/consents/{consentId})

  • Start the authorisation process in context of an Account Information Consent Request (POST /v1/consents/{consentId}/authorisations)

  • Update PSU Data in context of an Account Information Consent Request (PUT /v1/consents/{consentId}/authorisations/{authorisationId})

  • Get Authorisation Sub-Resources Request in context of an Account Information Consent Request (GET /v1/consents/{consentId}/authorisations)

  • Get SCA Status Request in context of an Account Information Consent Request (GET /v1/consents/{consentId}/authorisations/{authorisationId})

Bugfix: Validate entryReferenceFrom and deltaList parameters in Read Transaction List request

Parameter deltaReportSupported was removed from ASPSP Profile. From now on, ASPSP Profile has two parameters: deltaListSupported and entryReferenceFromSupported that indicate the support of corresponding parameters in Read Transaction List request GET /v1/accounts/{account-id}/transactions. When TPP sends request and it has either entryReferenceFrom or deltaList parameter, and ASPSP doesn’t support them, then TPP will receive 400 Bad Request error with PARAMETER_NOT_SUPPORTED code. If ASPSP supports both parameters and TPP sends request with these two parameters, it will also receive 400 Bad Request error with FORMAT_ERROR code.

Bugfix: Сreate consent request and update PSU authorisation request returns empty list of scaMethods in response

From now on, the responses for these requests don’t include empty list of scaMethods in case when no SCA methods are returned from SPI level:

  • POST /v1/consents;

  • PUT /v1/consents/{consent_id}/authorisations/{authorisation_id}.

Bugfix: Accept Authentication Type from ASPSP even if it is not described in Specification

From now on, ASPSP can provide Authentication Types (SMS_OTP, OTHER_OTP) of SCA methods, which are not described in Specification. There is possibility to accept Authentication Types from ASPSP and process them to XS2A response on following requests: Update PSU Data for Payment initiation Update PSU Data for Payment cancellation Update PSU Data for Consent

Bugfix: Validate bookingStatus query parameter in Read Transaction List request

From now on, mandatory bookingStatus query parameter is being validated in Read Transaction List request (GET /v1/accounts/{account-id}/transactions {query-parameters}). To be considered valid, this parameter should be present in request, have a valid value (booked, pending or both) and be supported by the ASPSP. ASPSP can indicate supported values by adding them to the availableBookingStatuses property in the ASPSP profile. If bookingStatus parameter has invalid value, 400 FORMAT_ERROR error will be returned in the response. If value is correct, but is not supported by the ASPSP, 400 PARAMETER_NOT_SUPPORTED error will be returned instead.

Bugfix: creditorAddress property is provided to the SPI in payment object even if it was not present in the request

Parameter creditorAddress in de.adorsys.psd2.xs2a.spi.domain.payment.SpiSinglePayment and de.adorsys.psd2.xs2a.spi.domain.payment.SpiPeriodicPayment will be set to null if it is absent in the initiatePayment request (POST /v1/{payment-service}/{payment-product})

Added validation of accept header for getting transaction list (GET /v1/accounts/{account-id}/transactions)

Configuration property supportedTransactionApplicationTypes was added to bank profile with list of supported headers (JSON, XML, TEXT).

  • Accept header (if it is presented in request) should be one of application/json, application/xml or text/plain and configured in bank profile.

  • If property supportedTransactionApplicationTypes is not configured validation will not be applied and header can be one of JSON, XML, TEXT as in specification.

  • If header Accept is not provided in request - respond with JSON format.

Bugfix: Get Consent request doesn’t return mandated lastActionDate attribute in response body

Until now, when TPP made first Get Consent request, lastActionDate field was absent in the response. From now on, the value of the lastActionDate field is set to the current date when AIS Consent is created and will always be present in the Get Consent response. will be set to null if it is absent in the initiatePayment request (POST /v1/{payment-service}/{payment-product})

Bugfix: Links startAuthorisationWithPsuIdentification and updatePsuIdentification should be never used in responses

From now on, XS2A would not return links startAuthorisationWithPsuIdentification and updatePsuIdentification during starting or updating the AIS consent or PIS payment authorisation. Links startAuthorisationWithPsuAuthentication and updatePsuAuthentication will be returned instead. The reason for that: our implementation already supports password receiving on startAuthorisation, therefore no need to separate Identification (PSU-ID) and Authentication (Password).

Bugfix: Payment Cancellation Request update

From now on, the endpoint for payment cancellation (DELETE /v1/{payment_service}/{payment_product}/{payment_id}) returns : - response code 405 and message CANCELLATION_INVALID in case when payment has finalized status - response code 204 and no response body in response in case when SCA is not required - response code 202 and links in response body according current SCA approach in case when SCA is required

Added new TPP-Explicit-Authorisation-Preferred header to the endpoint for payment cancellation.

Bugfix: Periodic payment can be created with invalid dayOfExecution tag

From now on, while creating the periodic payment (POST /v1/periodic-payments/{payment-product}) the dayOfExecution field is validated: it has to be a string representation of a day of the month (1-31), violating this returns 400 FORMAT_ERROR.

Delete "accounts" field in PiisConsentEntity, deprecated methods and "piis_consent_acc_reference" table

Table piis_consent_acc_reference and field in PiisConsentEntity were removed as deprecated.

Delete createAuthorization method in AisConsentAuthorisationServiceBase

Method createAuthorization in AisConsentAuthorisationServiceBase was removed. From now on, createAuthorizationWithResponse(String consentId, AisConsentAuthorizationRequest request) method will be used instead.

Bugfix: Get Cancellation Authorisation Sub-Resources request (GET /v1/{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations) returns wrong JSON format

From now on, Get Cancellation Authorisation Sub-Resources request returns correct response with cancellationIds field, that contains list of cancellation authorisations

Bugfix: authorisationId field is not provided in the responses

From now on, while getting the response for these requests: - AIS consent starting authorisation, - PIS payment starting authorisation, - PIS payment cancellation authorisation

the response has authorisationId field.

Bugfix: Fixed count usage of frequencyPerDay for one-off consents for every account endpoint

frequencyPerDay is counted per unique resource for each endpoint when recurringIndicator of the consent is set to false. Every access on the following endpoints is counted by one-off consent, where pagination on transactions are resulting in counting all accesses to this transaction report as one access:

  • GET /v1/accounts;

  • GET /v1/accounts/account-id per account-id;

  • GET /v1/accounts/account-id/transactions per account-id;

  • GET /v1/accounts/account-id/balances per account-id;

  • GET /v1/accounts/account-id/transactions/transaction-id per account-id and transaction-id, if applicable.

Also, a new scheduled task was added in CMS to be executed by Spring Scheduler. To set up the periodicity of this task execution, the new property used-non-recurring-consent-expiration.cron.expression was added to the application.properties file(current value is set to run at the top of every hour of every day).

Bugfix: Read Transaction List request returns empty lists with transactions

From now on, response to the Read Transaction List request (GET /v1/accounts/{account-id}/transactions) will no longer return empty lists with transactions, if they weren’t provided by the ASPSP.