Skip to content

Latest commit

 

History

History
76 lines (51 loc) · 4.51 KB

Release_notes_5.5.adoc

File metadata and controls

76 lines (51 loc) · 4.51 KB
Raw

Release notes v.5.5

Table of Contents

  • Removed deprecated columns TppRedirectUri from TppInfo

  • Removed deprecated PsuIdData from confirmConsent, rejectConsent, revokeConsent in CmsPsuAisService

  • Refactoring: Extracted ASPSP Profile web-endpoints into separate module

  • Bugfix: incorrect response for start authorisation request with password but without PSU-ID in header Explicit AIS/PIS

  • Add supporting standing order report

  • Revoke all consents when account is closed

  • Provided implementation of delta access for transaction list request

  • Bugfix: validation of authorisation sub-resources

  • Refactoring: Removed duplication and complexity for PisAuthorisationProcessorServiceImpl and PisCancellationAuthorisationProcessorServiceImpl

  • Refactored PisCommonPaymentServiceInternal

Removed deprecated columns TppRedirectUri from TppInfo

From now on, deprecated columns redirect_uri, nok_redirect_uri, cancel_redirect_uri, cancel_nok_redirect_uri are removed from tpp_info table in CMS.

Removed deprecated PsuIdData from confirmConsent, rejectConsent, revokeConsent in CmsPsuAisService

From now on, deprecated method authorisePartiallyConsent is removed from CmsPsuAisService and deprecated headers psuId, psuIdType, psuCorporateId, psuCorporateIdType are removed from authorisePartiallyConsent method in CmsPsuAisController.

Refactoring: Extracted ASPSP Profile web-endpoints into separate module

From now on, endpoints for accessing and updating ASPSP Profile are located in aspsp-profile-web module.

Bugfix: incorrect response for start authorisation request with password but without PSU-ID in header Explicit AIS/PIS

From now on, when you try to start authorisation for payment/consent with password and without PSU-ID in header, you’ll receive the same response as it would be with PSU-ID in header.

Add supporting standing order report

From now on, it’s possible to return standing order report on Get Transaction List request(GET /v1/accounts/{{account_id}}/transactions) in JSON format.

This endpoint is offering a list of all standing orders related to a dedicated payment account in case of bookingStatus parameter equals information. The support the information feature is optional for the ASPSP. Error code will be responded if it is not supported. The query parameters dateFrom, dateTo, withBalance, deltaList and entryReferenceFrom will be ignored and have no effect on the result.

Only application/JSON for response content type is supported.

Revoke all consents when account is closed

From now on, created endpoint in cms-aspsp-api for revocation AIS and PIIS consents of account or PSU data. If PSU closes an account in the bank - then ASPSP can use this endpoint. AIS and PIIS consents will change status to RevokedByPsu.

Provided implementation of delta access for transaction list request

Delta access was implemented for transaction list request GET /v1/accounts/{account-id}/transactions. Parameters entryReferenceFrom and deltaList are provided to SPI level in SpiTransactionReportParameters object. Also acceptMediaType, withBalance, dateFrom, dateTo, bookingStatus were moved from method parameters to SpiTransactionReportParameters object. Parameter dateFrom is not mandatory when TPP sends entryReferenceFrom or deltaList parameter and it is supported by ASPSP. When TPP sends transaction list request with period parameters (dateFrom and dateTo) and one of a delta access parameters (entryReferenceFrom or deltaList) and this parameter is not supported by ASPSP, then request will be processed only with period parameters.

Bugfix: validation of authorisation sub-resources

From now on, while creating authorisation for PIS/AIS/PIS cancellation, some business validation occurs due to the specification demands. Main ideas:

  • For one PSU SCA – only one authorisation per one initial request for one PSU-ID may be active.

  • For multilevel PSU SCA – for one initial request there may be active as many authorisations as many PSUs should make SCA, but only one authorisation for one particular PSU-ID.

Refactoring: Removed duplication and complexity for PisAuthorisationProcessorServiceImpl and PisCancellationAuthorisationProcessorServiceImpl

Removed code duplication and allocated common parts of the mentioned services.

Refactored PisCommonPaymentServiceInternal

From now on, PisCommonPaymentServiceInternal is split into two services: PisCommonPaymentServiceInternal and PisAuthorisationServiceInternal.