Skip to content
Developerhome

Testing

  Less than to read


Test plan

The following plan details the required tests to be ran for each of the Banking Service flows. These tests need to be passed for an intergation to be successful and be moved into our production environment.

You can download the Banking Service flows test plan.

:

Note: This plan details the basic testing which should be completed to ensure your intergration is working as intended. We also recommend that you run your own quality assurances and testing to certify your solution.

Onboarding

Test description Expected outcome
A customer needs to be able to onboard a single account. The bank account status field should be set to ‘pending’ which is returned when calling to the GET /bankaccounts endpoint.
A customer needs to be able to onboard a single account and then go through the onboarding flow again to onboard a second account. Both bank accounts status field should be set to ‘pending’ which is returned when calling to the GET /bankaccounts endpoint.
A customer needs to be able to disconnect an account, reconnect the same real-world account and receive all transactions from the requested start date. After the bank account has been reconnected, the transactions returned from the consumer API GET /transactions endpoint should start from the date specified.
A customer needs to be able to view multiple accounts in which they have access. Performing a PATCH call to the provider API /authorisations endpoint passing multiple bank accounts. These multiple accounts should be displayed for the user selection within the banking service UI.
A customer needs to be able to view a single account in which they have access. Performing a PATCH call to the provider API /authorisations endpoint passing a single bank account. This account should be displayed for the user selection within the banking service UI.

Reauthorisation

Test description Expected outcome
When reauthorisation of an account is required, you need to be able to set the customer’s bank account to authentication required. The bank account status field should be set to ‘authRequired’ which is returned when calling to the GET /bankaccounts endpoint.
A customer needs to be able to reauthorise a single linked account when set to auth required. The bank account status field should change from ‘authRequired’ to ‘verifyingAuth’ which is returned when calling to the GET /bankaccounts endpoint.

Multi-account linking

Test description Expected outcome
A customer needs to be able to onboard a single account and then call to see other available accounts. After onboarding a single account, the consuming product should be able to call the GET /availablebankaccounts endpoint to retrieve their other available accounts.

Posting statements

Test description Expected outcome
A customer needs to be able to retrieve transactions. After your service posts statements through the provider API POST /statements endpoint, they should be available to the consuming product through the consumer API GET /transactions call.
You should not be able to post the same set of transactions twice. When a transaction status returns as ‘failed’ with details code ‘DuplicateTransaction’, you should handle this and only send transactions which have not previously been provided.

Offboarding

Test description Expected outcome
A customer needs to be able to offboard their account through the consuming product. The bank account status field should be set to ‘cancelled’ which is returned when calling to the GET /bankaccounts endpoint.

Next steps

After you have completed your sandbox testing, you are ready to move into production. Find out how to upgrade to Beta with stage 4. Go live & support.


Was this helpful?