payments/QA_PLAYBOOK.MD

QA Playbook

Test Cases

Test Case	Description	Checks	Expected Results
Install Connector {name}	POST request to {{baseUrl}}/v3/connectors/install/{name}	1. Verify that the response status code is 200 OK. 2. Check the response body to confirm the connector is installed successfully 3. Ensure the connector appears in the list of installed connectors. 4. Verify that the webhook we created successfully and the database is updated with the connectors webhook data.	The connector should be installed successfully.
Uninstall Connector	DELETE request to {{baseUrl}}/v3/connectors/:connectorID	1. Verify that the response status code is 202 Accepted. 2. Verify that the real data has been removed from the database. 3. Verify that the connnectors webhook subscriptions have been removed. 4. Verify that data is no longer being polled.	The connector should be removed successfully from the database. There’s no more polling for data for that connector.
Create a Bank Account	POST request to {{baseUrl}}/v3/bank-accounts	1. Verify that the response status code is 200 OK. 2. Check that the response body contains the bank account ID, e.g. { "data": "f4779706-3df0-4468-9515-174a7562df28" }. 3. Validate that the bank account is stored correctly in the Database. 4. Verify that sensitive information like IBAN, swift bic code, account number are encrypted in the Database.	A new bank account should be created and saved to the database. The response body should return the created bank account ID.
Forward a Bank Account		1. Verify that a new bank account was created in the accounts table. 2. Validate the incoming bank account and return a models.ErrInvalidRequest if needed. 3. Verify that bank account is also created on the PSP.

Transfers and Payouts

Transfers and Payouts	Checks	Notes
Creating a Transfer The objective here is to move money between internal accounts. POST {url}/v3/payment-initiations?noValidation=true	1. Verify that the balance in the source and destination accounts are updated correctly if the transaction succeeds. 2. Verify that the balance in the source account remains unchanged if the transaction fails. 3. Verify that sending from an account with zero balance fails. 4. Verify that sending fails if any of the required fields are omitted. 5. Verify that sending more than is available in an account fails. 6. Verify that sending to/from an external account fails. 7. Verify that the relevant webhook events are called. 8. Verify that the transfer has been recorded in the payment_initiation table. 9. Ensure that the related transfer object is created correctly on the PSP side.	Tranfers typically complete immediately, but some connectors might have a hold feature that allows a transfer to not complete immediately. Please check the docs carefully for things like this.
Creating a Payout The objective is to move money from an internal account to an external account or a check. POST {url}/v3/payment-initiations?noValidation=true (General)	1. Verify that only one record is added to the payment table. 2. Ensure the payment_adjustments table is updated with records representing the changes in status of the transaction. The payment ids on the records in the payment_adjustment table should be the same as the payment that was added to the payment table. 3. Validate incoming payout object before sending it to the PSP and return a models.ErrInvalidRequest in case of validation fails. 4. Ensure that the balance of the source account is updated at the next polling. 5. Verify that sending from an account with zero (0) balance or more than the current balance is failing correctly. 6. Ensure transactions triggers relevant webhooks events if available. 7. Ensure PAYIN transaction types are recorded properly - inbound transactions should be recorded as PAYIN 7. Ensure inbound transactions increases the balance while outbound transactions decreases the balance. Repeat for all Payout/Payin types.
Reverse a Payout	1. Verify that the ACH transfer has been reversed. 2. Validate the incoming reversal data before sending it to the PSP
Reverse a Transfer	1. Validate the incoming reversal data before sending it to the PSP. 2. Note PSP's method of reversing transfers e.g. holding transfer first before cancelling or reversing.

Polling Testcases

Polling Test Cases	Checks
Polling Accounts The objective is to confirm that the Internal & External accounts of the connector are fetched by the worker within the specified interval and in the correct pageSizes. This should happen when the connector is installed and at the specified interval after that.	1. Verify that the accounts are fetched when the connectors are installed. 2. Verify that the accounts are fetched in the specified interval. 3. Verify that installing the connector with a different page size than the default should not change polling behavior (and must eventually fetch all the data) 4. Verify that the accounts are fetched in the correct pageSizes. 5. Verify that the External Accounts are fetched after they have been created & forwarded. 6. Verify that the count of the accounts in the Connector dashboard equals that in the database. 7. Verify that polling is stateful so we don't fetch all accounts at every polling
Polling Account Balances The objective is to confirm that the Account Balance of the Internal Accounts are fetched by the worker within the specified interval and in the correct pageSizes.	1. Verify that the correct balance of each of the Internal Accounts is fetched. 2. Verify that the balances are fetched after the Internal Accounts have been fetched. 3. Verify that new balances are fetched after payments have been made to or from Internal accounts.
Polling Payments The objective is to confirm the successful, pending and declined payments fetched by the worker in the correct pageSizes on install of the connector and subsequently within the specified interval.	1. Verify that all the payments in the connector dashboard (or via API call) are fetched after the connector is installed. 2. Verify that the worker attempts to fetch payments after the specified interval. 3. Verify that new payments are fetched when payments are polled in the next interval. 4. Verify that the number of payments fetched matches the pageSize specified on install of the connector. 5. Verify that installing the connector with a different page size than the default should not change polling behavior (and must eventually fetch all the data) 6. Verify that polling is stateful so we don't fetch all payments at every polling. 7. Ensure that payment updates don't create a new payment in the Database but adds to the payment's list of adjusments. i.e ParentReference of the PSPPayment structure should be filled.
Polling External Accounts The objective is to confirm that the External Accounts are fetched by the worker in the correct pageSizes on install of the connector and subsequently with the specified interval.	1. Verify that the correct number of external accounts are fetched when the connector is installed. 2. Verify that the newly added External Accounts are fetched on the next polling interval. 3. Verify that installing the connector with a different page size than the default should not change polling behavior (and must eventually fetch all the data) 4. Verify that polling is stateful so we don't fetch every external accounts at every polling.

Webhook Testcases

Web Hooks Test Cases	Checks
Webhooks The objective is to confirm that the webhooks are triggered when certain states change and that it's removed when the connector is uninstalled.	Verify that the webhook is triggered when the status of a payout changes. Verify that the webhook is removed from the database when the connector is uninstalled.

Cleanup Operations

On restart of the server after the server has been stopped without uninstalling the connector.

• Verify that we don't get a Signature Verification error and that we receive webhook events succesfully, and the workflow completes.