BerlinGroup NextGenPSD2 API - Test Guide

This document provides a summary overview of the steps that need to be executed to send a valid request to the implemented API endpoints.

The following operations (API resources) have been implemented on this API (the remaining resources provide a static mock response and/or may have limited security configuration in place):

• POST /v1/consents
• GET /v1/accounts
• GET /v1/accounts/{account-id}

These resources represent the three endpoints of the Account Information Service offered by the NextGenPSD2-XS2A API. When an AISP requests account information, (s)he will first have to create a consents resource using POST /v1/consents. Note that the Sandbox implementations offered here provide mock responses that demonstrate the expected functionality without actually creating or deleting data.

More and actual details can be found in the NextGenPSD2 XS2A Framework Operational Rules.

Executing a test on POST /v1/consents (happy flow)

This Digital Banking Portal provides a convenient Test Client for effective API testing. Please note that this Test Client allows for configuration settings that are needed to satisfy any security policies that have been implemented on the API endpoint (for example validation of the input request headers and payload body).

Test Client can be accessed through the ‘Test Client’ button in the left navigation bar when viewing the API.

Also note that the API's 'Documentation' button contains another (embedded) test facility with full documentation on API resource, parameters, etc.

Accessing the Test Client will show details of the API about to be tested as shown in the screen capture below:

The section shows the available API Implementations (in this case, Sandbox only), available API operations, Endpoints on which the API is available (in this case, https and mutual-https); the Path field shows the path associated with the selected Operation.

Essentially, Test Client automatically shows all details as they are laid down in the API interface (Swagger/OAS). Selecting an Operation will automatically populate relevant other sections, for example Headers, Parameters and Access URL.

Steps to execute for a successful test are:

1. Select the resource to be tested, in this case POST /v1/consents -createConsent, from the list presented in the Operation field;
2. Provide valid values to any required request header and/or parameter (required elements are marked with a *);
3. Provide a valid request body (JSON object), if applicable.

Request headers:

Required parameters: none.

Request body: the API Documentation presents a valid sample request body that can be copied into Test Client Content field. For convenience, it is also presented below:

{ "access": { "availableAccounts": "allAccounts" }, "recurringIndicator": false, "validUntil": "2021-08-03", "frequencyPerDay": 1, "combinedServiceIndicator": true }

With these steps configured as documented above, the request should be accepted by the API Gateway and return an http 201 with a generated JSON mock response.
Some request and response details can be reviewed in Test Client. In addition, the 'Trace' tab (under Response) shows elements automatically added by Test Client, based on your Setup and Security configuration.
Further details of the transaction, including operational metrics and details on the generated request message and returned response can be reviewed under the 'Logs' menu item (requires Log In).

Alternative test cases

• Not providing a JSON payload will have the API Gateway block the request (http 400);