Testing and Go-live

Integration test and verification

Before going live with your Brite integration it is important to test it thoroughly. In this section we will cover what to test, how to test, and what to look for when performing the tests.

Sandbox testing

When integrating the Brite client, we would recommend testing the following OS and browser combinations to cover the majority of user cases:

OS	Browser
Windows	Chrome
Windows	Firefox
Windows	Edge
Mac	Safari
iOS	Safari
iOS	Chrome
Android	Chrome

Sandbox testing

The following scenarios are recommended to test before moving from the Sandbox environment to the Production environment.

Users

New users 
Make sure new users are registered correctly when using Brite Play.
Returning users 
Logic in place for handle returning user. Make sure that a returning users is logged into the correct account.
Get KYC (Brite Play) 
Fetch users KYC in the Brite Play flow by first calling kyc.create and then kyc.get.

Deposits

Successful deposit 
Verify that a transaction is successful by receiving callback for STATE_CREDIT or fetch latest state directly from the API. Credit the users account.
Failed/Aborted deposit 
Verify that an aborted/failed session and transaction is handled properly. Also make sure to have logic in place to handle a transactions which have failed or been aborted but then transitions to C——-´++redited.
Merchant approval/rejection of a deposit session 
Make sure logic for calling session.approve and session.reject is resulting in the expected behaviour. Also make sure to have logic in place for tracking rejection reason.
Ensure callbacks are successful 
Subscribing to desired callbacks and responding correctly with 200.
Refunds 
Test to refund a deposit and verify expected outcome.

Withdrawals

Create bank account 
Use an existing Brite bank account ID or create a new Brite bank account. Using any of the methods
Successful withdrawal 
Verify that a transaction is successful by receiving callback for STATE_CREDIT or fetch latest state directly from the API.
Failed/aborted withdrawal 
Verify that an aborted/failed session and transaction is handled properly.
Merchant approval/rejection of withdrawal 
Make sure internal logic for Approval/rejection is working as intended. Also make sure to have logic in place for tracking rejection reason.
Ensure callbacks are successful 
Subscribing to desired callbacks and responding correctly with 200.

Brite Client

Verify size of Client 
Verify that there are not scrollbars visible when client is rendered.
Client boarder 
If the Client is rendered in modal make sure borders are not duplicated.
Client Close and Exit buttons. 
Make sure the user is redirected accordingly if the Client is closed or the user presses the exit button.

Error simulation

It is possible to do negative tests in the Sandbox environment. In the Bank selection step, you can select the Test Bank and have some test scenarios to select and is enabled for all markets.

Fail after login
Login fail and and the user is presented with: “The bank is experiencing technical issues. Please try again later.” Error_code: “generic_bank_error”
No funds
Login fail and User is presented with: “None of your bank accounts have enough funds for this transaction. Please top up your accounts or select a different bank.” Error_code: “psu_insufficient_funds_all_accounts”
Incomplete KYC
Login is aborted due to incomplete KYC. user is presented with error message saying: “Incomplete information from identity service. Please contact your bank.” Error_code: “incomplete_kyc_information_from_kyc_provider”
Risk engine abort
Transaction is rejected due to risk engine decision. User is prompted with “Oops, something went wrong! The transaction was rejected”. Error_code: “risk_engine_rejection”. Session is aborted and callback session STATE_ABORTED = 10 and transaction STATE_ABORTED = 2 is sent.
Fail transaction
Transaction is failed. User is promted with: “Oops, something went wrong! The transaction was rejected by the bank”. Error_code: “bank_rejected_transaction”. Session is aborted and callback session STATE_ABORTED = 10 and transaction STATE_ABORTED = 2 is sent.
Underage customer
Transaction is rejected due to risk engine decision because of the customer being a minor. User is prompted with “Oops, something went wrong! Unfortunately, your transaction cannot be processed at this time”. Error_code: “risk_engine_rejection”. Session is aborted and callback session STATE_ABORTED = 10 and transaction STATE_ABORTED = 2 is sent.

Aborted and failed withdrawals can be triggered by including the following “amounts” in the “/transaction.create_withdrawal” request:

“amount”: 11.01 – The withdrawal will be aborted. An HTTP POST request including the transaction aborted state is triggered to the URL added in the “Callbacks” parameter. When calling /transaction.get endpoint the “error_code”: “bank_rejected_transaction” is returned.
“amount”: 11.02 – The withdrawal will be aborted. An HTTP POST request including the transaction aborted state is triggered to the URL added in the “Callbacks” parameter. When calling /transaction.get endpoint the “error_code”: “invalid_recipient_account” is returned.
“amount”: 12.01 – The withdrawal will be failed. An HTTP POST request including the transaction failed state is triggered to the URL added in the “Callbacks” parameter. No error_code is returned in the /transaction.get response.
“amount”: 13.01 – The transaction is delayed. The transaction remains in the state Completed for 5 minutes before it transitions to state Settled. Calling /transaction.get endpoint will before it is Settled return the state Completed and “error_code”: “transaction_is_delayed_in_bank”.
“amount”: 14.01 – Returned Funds Transaction notification; When a payout is settled but later bounces back to Brite due to a rejection at the receiving bank, Brite creates a Returned Funds transaction. The test creates a payout that settles. After one minute, a Returned Funds transaction is created triggering a notification message to the webhook URL added in the Returned Transactions tab in Brite’s back office and linked to the original transaction.

				
					// Example Request
POST /transaction.create_withdrawal
{
    "amount": 11.01,
    "bank_account_id": "ag9ofmFib25lYS0xNzYyMTNyGAsSC0J...",
    "callbacks": [
        {"transaction_state": 2, "url": "https://webhook..."},
        {"transaction_state": 3, "url": "https://webhook..."},
        {"transaction_state": 5, "url": "https://webhook..."}
    ]
}

// Example Response
{
    "eta": 1728572262.0,
    "id": "ag9ofmFib25lYS0xNzYyMTNyFQsSC1RyYW5zYWN0aW9uG..."
}

				
					// Callback
POST "https://webhook..."
{
  "transaction_id": "ag9ofmFib25lYS0xNzYyMTNyFQsSC1RyYW5...",
  "transaction_state": 2,
  "merchant_id": "ag9ofmFib25lYS0xNzYyMTNyFQsSCE1lcmNoYW..."
}

// Example Request
POST /transaction.get
{
    "id": "ag9ofmFib25lYS0xNzYyMTNyFQsSC1RyYW5zYWN0aW9uG..."
}

// Example Response
{
    "amount": 11.01,
    "approved": 1728571962.0,
    "currency_id": "eur",
    "state": 2,
    "eta": 1728572262.0,
    "message": "RF47300000003...",
    "to_bank_account": {
        "bank_name": "Test_Bank",
        "country_id": "nl",
        "iban": "NL************971785"
    },
    "error_code": "bank_rejected_transaction",
    "id": "ag9ofmFib25lYS0xNzYyMTNyFQsSC1RyYW5zYWN0aW9uG..."
}

Production testing

Before going live to all users, Brite will require that a couple of production test transactions, both deposits and withdrawals, are done and verified OK. Please ensure the end user balance is credited correctly. Please provide a screen recording of the testing, both deposit and withdrawal, with Brite. With that we can verify that the sizing of the client, etc, and that it is optimised.

If applicable, we will be checking Brite’s positioning on the cashiers between the competitors as per contractual agreement.