Developer

Test plan

Less than 5 minutes to read

This plan details the minimum set of tests that which should be run for each Banking Service flow. These tests need to be passed for an integation to be successful and be moved into our production environment.

Note: It’s the provider’s responsibility to ensure comprehensive testing is completed.

You can use the checkboxes to keep track of your progress.

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

Onboarding

A customer needs to be able to onboard a single account. When onboarded the bank account status field should be set to 'pending' which can be returned when calling to the GET /bankaccounts endpoint.

A customer's account should be set to active once you have posted their first set of statements. The bank account status field should change from 'pending' to 'active' once you have posted their first set of statements.

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

When reauthorisation of an account is required, you need to be able to set the customer's bank account to auth required when posting a statment. 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

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

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

A customer needs to be able to offboard their account through the Sage product. After you recieve a bank account cancelled notification, you should perform any actions to cancell this account on your side and stop posting data.

What’s next?

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 and support.