Description

To meet the CDR spec we must implement the listPayees.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-payees

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L305

Acceptance criteria

• listPayees implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description

To meet the CDR spec we must implement the listBalancesSpecificAccounts.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-balances-for-specific-accounts

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L261

Acceptance criteria

• listBalancesSpecificAccounts implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description

To meet the CDR spec we must implement the listScheduledPayments.

The documentation https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L327

The code here https://consumerdatastandardsaustralia.github.io/standards/#get-scheduled-payments-bulk

Acceptance criteria

• listScheduledPayments implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description

To meet the CDR spec we must implement the listProducts.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-products

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L316

Acceptance criteria

• listProducts implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description
Improvements to ensure that Event Notification API works properly:

• Validation of requested versions
• Expand unit test
• Expand integration Tests

Specifications

• v3.0, v3.1, v3.1.1, v3.1.2, v3.1.3, v3.1.4, v3.1.5, v3.1.6

Check APIs List

• Callback URL API - all versions (create, amend, get, delete)
• Event Notification Subscription API - all versions
• Aggregated polling API - all versions

Story

As an OB sandbox PSU user
I want the Data API to support the versions implemented of the OBIE spec
so that I can import / export and test against each version

Acceptance criteria

• v3.1.1 Data API version mapping supported.
• v3.1.2 Data API version mapping supported.
• v3.1.3 Data API version mapping supported.
• v3.1.4 Data API version mapping supported.
• v3.1.5 Data API version mapping supported.
• v3.1.6 Data API version mapping supported.

Tasks list

• Update the Data APIs to use the version mapping
  • forgerock-openbanking-aspsp :: uk-aspsp-rs/rs-mock-store/rs-mock-store-server/com.forgerock.openbanking.aspsp.rs.store.api.openbanking.data
• Check the postman test to use the new context request mapping implementation version reference
• Update postman test

Release Notes

• Affected API: Data-API
• Description: The Data API endpoints now support the above versions.

We have had a few customer issues where it has been impossible to determine why TPPs were having trouble with these endpoints. Logging needs to be sufficient to allow us to determine why a specific call resulted in an OBErrorReponseException is called.

We aslo need to make sure that there is sufficient granularity and information in the OBErrorResponseExceptions to make sure that TPPs can easily diagnose why a call failed. This will reduce support effort for our customers, and also the support load on our team from our customers.

Description

To meet the CDR spec we must implement the listScheduledPaymentsSpecificAccounts.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-scheduled-payments-for-specific-accounts

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L349

Acceptance criteria

• listScheduledPaymentsSpecificAccounts implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Issues related

• Parent Issue

Description

The payments endpoints FundsConfirmation have a wrong grant_type set
When TPP request an access token with "grant_type": "authorization_code" the implementation expect an access_token with "grant_type": "client_credential" .

The documentation api spec 3.1.6 define "grant_type": "authorization_code" for the below endpoints:

• /domestic-payment-consents/{ConsentId}/funds-confirmation
• /international-payment-consents/{ConsentId}/funds-confirmation
• /international-scheduled-payment-consents/{ConsentId}/funds-confirmation

Tasks

• Check all funds-confirmation payment endpoints to identify a wrong grant_type.
• Fix the grant_type for funds-confirmation payment endpoints identified with a wrong grant_type.
• Improve integration test to cover the cases.
• Fix / Create functional tests to cover the cases.

Description

We should generate and not check into git the models from the swagger for CDR. This means that they'll always be up to date and less maintenance.

Acceptance criteria

• Auto-generated models

Description

To meet the CDR spec we must implement the listDirectDebitsSpecificAccounts.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-direct-debits-for-specific-accounts

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L294

Acceptance criteria

• listDirectDebitsSpecificAccounts implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description

We should not validate SSA software ID against the CN of the transport certificates as the eIDAS standard does not enforce this

discussion: https://open-banking-global.slack.com/archives/CBB3PBYDC/p1579682353044700

code: https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-uk-aspsp-as/forgerock-openbanking-uk-aspsp-as-gateway/forgerock-openbanking-uk-aspsp-as-gateway-server/src/main/java/com/forgerock/openbanking/aspsp/as/service/TppRegistrationService.java#L106

Acceptance criteria

Can register with non-forgerock eIDAS certificate

Description

To meet the CDR spec we must implement the listBalancesBulk.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-bulk-balances

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L250

Acceptance criteria

• listBalancesBulk implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description

The interface implemented on rs-store for fundsConfirmations doesn't work properly.

Tasks

• Fix rs-store fundsConfirmations

Description

To meet the CDR spec we must implement the listDirectDebitsBulk.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-bulk-direct-debits

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L283

Acceptance criteria

• listDirectDebitsBulk implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Need to fix the following text overflow that breaks the consent on mobile.

Release Notes

Affected App: Bank app

Description: Fix the text overflow on mobile when the TPP's name was long.

Dependabot couldn't authenticate with https://jcenter.bintray.com.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Description

The payment read/write APIs version 3.1 to 3.1.2 response with wrong version of links.self because the controller implementation it's an extension of minor version and then the link.self version it's the version of the extended controller.
Example:

// version 3.1
"Links": {
        "Self": "https://api.alphabank.com/open-banking/v3.1/pisp/domestic-payment-consents/58923/funds-confirmation"
    },
    "Meta": {}

// version 3.1.2
"Links": {
        "Self": "https://api.alphabank.com/open-banking/v3.1/pisp/domestic-payment-consents/58923/funds-confirmation"
    },
    "Meta": {}

It's expected "Self": "....../.../v3.1.2/....." instead of "Self": "....../.../v3.1/....."

• Versions affected from 3.1 to 3.1.2.

Tasks

• Check other APIs if they have the same issue.
• Fix link.self through all APIs.
• Test fix.

When modifying the UI code, the PR pipeline is also checking the java code, which is quite slow.

An improvement could be to only do some java code check if the java code has been updated.

Running the Postman End 2 End (Generated) tests against master there is an exception thrown when running the Test account flow/Account API v3.1.1/account/Get accounts (v1.1) test.

stack_trace: "java.lang.IllegalArgumentException: No enum constant uk.org.openbanking.datamodel.payment.OBExternalAccountIdentification2Code.UK.OBIE.SortCodeAccountNumber
	at java.base/java.lang.Enum.valueOf(Unknown Source)
	at uk.org.openbanking.datamodel.payment.OBExternalAccountIdentification2Code.valueOf(OBExternalAccountIdentification2Code.java:23)
	at com.forgerock.openbanking.common.services.openbanking.converter.account.OBCashAccountConverter.toOBCashAccount1(OBCashAccountConverter.java:159)
	at com.forgerock.openbanking.common.services.openbanking.converter.account.FRAccountConverter.toOBAccount1(FRAccountConverter.java:126)
	at com.forgerock.openbanking.common.services.openbanking.converter.account.FRAccountConverter.toAccount1(FRAccountConverter.java:75)
	at com.forgerock.openbanking.aspsp.rs.store.api.openbanking.account.v1_1.account.AccountsApiController.lambda$getAccounts$0(AccountsApiController.java:116)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
	at java.base/java.util.stream.ReferencePipeline.collect(Unknown Source)
	at com.forgerock.openbanking.aspsp.rs.store.api.openbanking.account.v1_1.account.AccountsApiController.getAccounts(AccountsApiController.java:116)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Hello Ben,

Thank you for the update.

It's not clear what is the path prefix you wish to link to JCenter.
For example, in the screenshot below, you can see that com/forgerock/openbanking/aspsp/forgerock-openbanking-aspsp does not contain the needed content as explained earlier this week

Moreover, it appears that there other path prefixes does not contain files at all. For example:
com/forgerock/openbanking/aspsp/forgerock-openbanking-cdr-aspsp-rs
com/forgerock/openbanking/aspsp/forgerock-openbanking-cdr-aspsp-as-gateway
/com/forgerock/openbanking/aspsp/forgerock-openbanking-cdr-aspsp-rs
etc..

To be able to submit the request successfully, you have to add the needed files (for all submodules) and only then, you will be able to link your package.

Furthermore, if it's a POM project, you should mark the checkbox of "is pom project" after you click Add to JCenter and make sure all submodules are updated accordingly.
As you may know, a POM project should contain the tag inside the pom set to “pom” (pom).

Here is a link with information about Including Your Package in JCenter.

I hope this clarifies but if not, please let me know and I'll share more details.

Best regards,
Guy Cohen
JFrog Support

https://bintray.com/openbanking-toolkit/OpenBankingToolKit/openbanking-aspsp/1.0.30#files/com%2Fforgerock%2Fopenbanking%2Faspsp%2Fforgerock-openbanking-cdr-aspsp-as

The version field in the response of the OIDC well-known endpoint is currently the hightest version of the OB Read/Write APIs that is supported. This doesn't make much sense because a better place to see which versions of the OB APIs are implemented is by looking at the rs discovery endpoint, which contains all the versions for all of the APIs.

What makes more sense is if the OIDC well-known endpoint refers to the version of the Dynamic Client Registration that is implemented.

The OB Dynamic Client Registration specs are here;
https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html

Check the end to end postman file to introduce the change related with the support the test using the CLIENT_CREDENTIALS gran type for few payment methods (GET) that was protected with the wrong grant type AUTHORIZATION_CODE

Description

In order for the toolkit to enable banks to implement open banking standards, the RS API will need to be integrated with the banks RS store.

The banks RS APIs will not conform to the APIs the Toolkits RS API is expected to call, therefore the banks will need to implement a gateway which will be responsible for taking a validated request from the Toolkits RS API and calling the banks RS APIs to fetch or update resources.

We should adopt industry standards for defining said interfaces.

Acceptance criteria

• Define an OpenAPI spec for the RS store
• Regenerate RS store APIs from spec
• Ensure existing functionality not broken

Description

To meet the CDR spec we must implement the getPayeeDetail.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-payee-detail

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L140

Acceptance criteria

• getPayeeDetail implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Description

To meet the CDR spec we must implement the getTransactionDetail.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-transaction-detail

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L162

Acceptance criteria

• getTransactionDetail implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Spec is here;
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1077806765/Aggregated+Polling+-+v3.1.2#AggregatedPolling-v3.1.2-Basics

How to Reproduce

From the command line run curl -k --location --request GET 'https://rs.aspsp.master.forgerock.financial/open-banking/discovery' | jq '.' | grep 'EventAggregatedPolling'

output will be;

"EventAggregatedPolling": "https://matls.rs.aspsp.master.forgerock.financial/open-banking/v3.1.2/event",

Output should be;

"EventAggregatedPolling": "https://matls.rs.aspsp.master.forgerock.financial/open-banking/v3.1.2/events",

Description

To meet the CDR spec we must implement the getProductDetail.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-product-detail

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L151

Acceptance criteria

• getProductDetail implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

The /dto classes are the generated DCR classes generated from the swagger found here;
https://github.com/OpenBankingUK/client-registration-api-specs/tree/v3.2

I have a concern that we don't totally support DCR registration specs. For example the OB DCR spec says

the ASPSP MUST return a client registration error response to the TPP conforming to Section 3.2.2 of [RFC7591]
https://openbankinguk.github.io/dcr-docs-pub/v3.2/dynamic-client-registration.html#error-structure

Find that spec here;
https://tools.ietf.org/html/rfc7591#section-3.2.2

The code didn't do that. I have made changes to fix that for the register journey, but I think the whole of our DCR implementation needs checking to compliance against this spec. I'll create a new issue for that.

Originally posted by @BohoCode in #318 (comment)

Tasks;

• Change mocks in TppRegistrationServiceTest to use @mock and @InjectMock (see #318 (comment))

Version of API being called is controlled by a section of the URL path containing major version and the x-min-v and x-v headers as described in the following spec;
https://consumerdatastandardsaustralia.github.io/standards/#http-headers

This could be addressed using spring's request mapping with headers;
https://www.baeldung.com/spring-requestmapping#1-requestmapping-with-the-headers-attribute

Description

In order for the rs-api to be a useful resource, ASPSP's should be able to easily integrate with their back end. Having an OpenAPI spec will allow ASPSP's to generate a microservice, this services will call their own APIs in order to satisfy the open banking API requests.

As a ASPSP developer, I want to be able to integrate the toolkit with my bank, so that I can fulfil open banking requests

Acceptance criteria

• OpenAPI spec (swagger) to generate models and APIs necessary to fulfil rs-api requests

Description

To access Aggregated Polling API the access token must have a specific scopes.
The defined scopes to access Aggregated Polling API are different between versions.

Scopes by version table

Tasks

• Check the authorisation scopes defined in the implemented controllers
• Fix the scopes by version
• Create integration tests
• Check the functional tests and apply fixes if necessary
• Check Postman End To End Tests (Generated) collection and apply fixes if necessary

Description
The object returned by each Event Notifications API version are wrong or null in some cases:

• Version v3.0 spec not define the Links and Meta sections (in that case it's ok)
• Versions v3.1 and v3.1.1 the Links and Meta section returned null values
• Versions v3.1.3 to v3.1.6 returned the Links.self version v3.1.2

Specifications

• v3.0, v3.1, v3.1.1, v3.1.2, v3.1.3, v3.1.4, v3.1.5, v3.1.6

Example

{
    .....
    },
    "Links": {
        "Self": "https://api.alphabank.com/open-banking/v3.1/callback-urls/"
    },
    "Meta": {}
}

Check APIs List

• Callback URL API - all versions (create, amend, get, delete)
• Event Notification Subscription API - all versions
• Aggregated polling API - all versions

Expected:

• Each api version with Links and Meta section defined by the Spec must be return the proper api version in Links.self section

When the UI is built it should update the ob-deploy repo's `client_releases/master-dev/releases.json' file to deploy the new version.

Description

To meet the CDR spec we must implement the listDirectDebits.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-direct-debits-for-account

The code here https://github.com/OpenBankingToolkit/openbanking-aspsp/blob/master/forgerock-openbanking-cdr-aspsp-rs/forgerock-openbanking-cdr-aspsp-rs-mock-store/forgerock-openbanking-cdr-aspsp-rs-mock-store-server/src/main/java/com/forgerock/openbanking/aspsp/rs/store/api/openbanking/account/cdr/v1_0/BankingApiController.java#L272

Acceptance criteria

• listDirectDebits implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Customer Issue: 48067

The response from the /open-banking/v3.1/aisp/accounts endpoint returns the following sample data;

"Data": {
           "Account": [
             {
               "AccountId": "0cdaa0d0-0875-492d-be47-df617a1d42fe",
               "Currency": "GBP",
               "AccountType": "Personal",
               "AccountSubType": "CreditCard",
               "Account": [
                 {
                   "SchemeName": "PAN",
                   "Identification": "525302******7553",
                   "Name": "Mr Zak Matusak"
                 }
               ]
             },
             {
               "AccountId": "1957ee43-faae-4601-bb73-140259039e38",
               "Currency": "GBP",
               "AccountType": "Personal",
               "AccountSubType": "CurrentAccount",
               "Nickname": "NickZero",
               "Account": [
                 {
                   "SchemeName": "SortCodeAccountNumber",
                   "Identification": "80064711123468",
                   "Name": "Mr Zak Matusak"
                 }
               ]
             } ...

As you will notice, "SchemeName” is appearing as SortCodeAccountNumber. This should appear as UK.OBIE.SortCodeAccountNumber.

The specification relating to jwt signing for the Event Read/Write APIs may be found here;
https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/event-notification-api-profile.html#event-notification-message-signing

Specifically this section is of interest;

Event Notification Message Signing
Event Notifications are signed for non-repudiation using the approach defined in the R/W API specification, with the following difference:

The JWT's signature (JWS) is sent in the HTTP body of the request, as opposed to a detached JWS sent in the HTTP header.

Currently the event APIs use the same jwt verification methods as the payment APIs which expect the jwt to be in the header of the request rather than the body.

We have had a few customer issues where it has been impossible to determine why TPPs where having trouble with these endpoints. Logging needs to be sufficient to allow us to determine why a specific call resulted in an OBErrorReponseException is called.

We also need to make sure that there is sufficient granularity and information in the OBErrorResponseExceptions to make sure that TPPs can easily diagnose why a call failed. This will reduce support effort for our customers, and also the support load on our team from our customers.

Description

When user (PSU) declines the consent using cancel button the UI doesn't show a notice page to confirm it and the current implementation raise and 500 error.

Components

• UI Bank
• Backend Endpoint: /api/rcs/consent/decision/
• Backend Controller: RCSConsentDecisionApiController

Documentation

Sections Consent Dashboard & Revocation

• https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines-V1.3.0.pdf
• https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines-V3.1.3-web.pdf

ASPSPs should advise PSUs that they should contact the associated AISP to
inform them of the cancellation of access and/or understand the consequences of
doing so.

Issues related

• https://github.com/ForgeCloud/ob-deploy/issues/764
• #423

Task

• Implementation of notice page when user cancel/decline the consent.

Description

To meet the CDR spec we must implement the listScheduledPaymentsBulk.

The documentation https://consumerdatastandardsaustralia.github.io/standards/#get-scheduled-payments-bulk

The code here listScheduledPaymentsBulk

Acceptance criteria

• listScheduledPaymentsBulk implemented
• Unit tests
• Integration tests
• Functional test (if necessary)

Change Description

1. A Tpp can get the callback url accessing by newer api.
   An ASPSP must allow a callback-url resource to be accessed in a newer version.
   Example: Access to callback resource created in v3.0 from v3.1 or newer

2. Change the response when doesn't exist callback url resources.
   A TPP must not access a callback-url on an older version, via the CallbackUrlId for a callback-url created in a newer version

   When the tpp request the callback URL resources:

   • When the resources has been created on a newer version the response will be empty with http code 200.
   • When doesn't exist tpp callback URL resources the response will be empty with http code 200.

Tasks

List of tasks required to implement this story:

• Callback URL API checks
  • Check Integration Tests and create more if necessary
  • Check functional test and create more if necessary
  • Check Postman test and create more if necessary

We have a customer issue where isn't clear to determine why TPPs were having trouble with /api/rcs/consent/decision/ endpoint.

Logging needs to be sufficient to allow us to determine why a specific call resulted in an OBErrorReponseException is called.

We also need to make sure that there is sufficient granularity and information in the OBErrorResponseExceptions to make sure that TPPs can easily diagnose why a call failed. This will reduce support effort for our customers, and also the support load on our team from our customers.

The Payment Context Code is a field that exists in the Risk object that is supplied with the payment-order consent and payment-order resources. The Risk object is currently implemented by the OBRisk1 class. See https://openbankinguk.github.io/read-write-api-site3/v3.1.5/profiles/payment-initiation-api-profile.html#obrisk1.

The specifications state that this field has a 0..1 association with the OBRisk1 class, and is therefore optional. There is a requirement from some implementations that it should be possible to configure this field to be a required field. i.e. a 1..1 field.

Acceptance criteria

• It is possible to use a spring configuration setting to change the behaviour of the payment API such that they reject a request if this field is not provided.
• When enabled in configuration and the PaymentContextCode is not provided then requests will be rejected with and OBRIErrorResponseCategory.REQUEST_FILTER category and a BAD_REQUEST (400) status code.