Testing and Go-live

Integration test

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.

General requirements

To perform a test transaction, Brite requires access to your test environment. Please send all necessary credentials (test site URL, username, password, etc.) to your contact at Brite. If providing direct access isn't possible, please supply a screen recording or screenshots instead, ensuring they clearly show the end-user experience and how Brite is presented on your website.

Technical

For each API method, please be sure to send all the parameters and attributes as described in the documentation.
Make sure you listen to the right callback notifications for the product you integrated with and you react on the statuses accordingly
In the event of an API error, please ensure your system logs the corresponding error code and that your team investigates the matter internally

UX / UI

The Brite Client must be presented in the correct way as described in our Checkout Guidelines.
Ensure that the whole end-to-end customer journey is implemented in a seamless way accross all platforms (mobile website, desktop and mobile app)

Test use cases

To ensure a robust integration, Brite provides a comprehensive suite of test cases that cover both successful (‘happy path’) and error (‘unhappy path’) scenarios, preparing your system for virtually any event.

The Brite Client allows you to select certain test scenarios to trigger specific behaviours such as a successful one or aborted attempts (due to a failed login, risk engine rejection, underaged customer, etc). You can find those test cases by selecting the “Test Bank” in the Brite Client in the Sandbox environment.

Brite Client

In this section you can find the most important things to verify if you integrated the Brite Client correctly. These tests apply for all products which use the Brite Client.

Brite is shown to all customers in order to not discriminate anyone
The Brite Client is rendered on all platforms in the correct size
It occupies the full screen on a mobile device
No scrollbars are visible in the Brite Client
There are no additional ways to close or exit the Brite Client other than the [x] in the Brite Client
In case the Brite Client is closed, the customer ends up on a page where he can proceed his journey

Brite Instant Payments

In this section you can find the most important test cases to verify your Brite Instant Payments (incl. refunds) integration.

PI-01: Successful payment (*)

Scenario	Initiate a payment and complete it successfully using the Brite Client.
Expected Outcome	Brite Client fully visible and accessible to the customer Callbacks being handled by the merchant on the correct statuses Payment in the merchant system marked as successful Customer ends up on success screen / confirmation page
How to trigger	Select the “Test Bank” or any other working bank
Considerations & Verifications	Nothing additionally to the integration guidelines

PI-02: Unsuccessful payment with aborted status (*)

Scenario	Initiate a payment and abort it using the Brite Client.
Expected Outcome	Brite Client fully visible and accessible to the customer Callback `STATUS_ABORTED` from Brite being handled by the merchant Payment in the merchant system marked as unsuccessful Customer returns to payment selection step
How to trigger	Select the “Test Bank” and pick an “aborted” test case or simply close the Brite Client by using the [x]
Considerations & Verifications	Allow customers to retry based on the error messages or offer them a different payment method Today it’s not possible to trigger a `STATUS_FAILED` status on Sandbox environment

PI-03: Returning user payment (*)

Scenario	Initiate a payment from an returning user using the Brite Client which will lead to a faster checkout and better conversion
Expected Outcome	Brite Client rendered with the `customer_id` and fully visible Callbacks being handled by the merchant on the correct statuses Payment in the merchant system marked as successful Customer ends up on success screen / confirmation page
How to trigger	Send in a customer_id from a previous payment
Considerations & Verifications	A `customer_id` is bound to a MID (Merchant ID) – you can’t share them across multiple MIDs

PI-04: Status change from unsuccessful to successful payment (*)

Scenario	Initiate an unsuccessful payment which later on changes to successful
Expected Outcome	Brite Client fully visible and accessible to the customer Callback `STATUS_ABORTED` from Brite being handled by the merchant Payment in the merchant system marked as unsuccessful Customer returns to payment selection step Success Callback from Brite being handled by the merchant
How to trigger	Unfortunately this test can’t be triggered on Sandbox yet.
Considerations & Verifications	`STATUS_ABORTED` and `STATUS_FAILED` are not final states; they can change to a successful payment after some time As this can happen on Production, please make sure to build a logic to cater for these very rare situations.

PI-05: Successful refund via API (* if applicable)

Scenario	Initiate a (partial) refund via API successfully.
Expected Outcome	Initiate the refund request via API Callbacks being handled by the merchant on the correct statuses Refund in the merchant system marked as successful
How to trigger	No specific things to consider here
Considerations & Verifications	The refund amount can not exceed the original payment amount

PI-06: Pending payment

Scenario	Initiate a payment and complete it successfully using the Brite Client.
Expected Outcome	Brite Client fully visible and accessible to the customer Callbacks being handled by the merchant on the correct statuses Payment in the merchant system marked as initiated but not successful Final Callback being handled by the merchant on the correct statuses
How to trigger	Every successful payment goes through the complete status before it becomes a successful transaction.
Considerations & Verifications	Nothing additionally to the integration guidelines

Brite Instant Payouts

In this section you can find the most important test cases to verify your Brite Instant Payout integration.

PO-01: Successful payout via Brite Client (* if applicable)

Scenario	Select a bank account via the Brite Client and initiate a payout via API successfully.
Expected Outcome	Brite Client fully visible and accessible to the customer Callbacks being handled by the merchant on the correct statuses Payout in the merchant system marked as successful Customer ends up on success screen / confirmation page
How to trigger	Select the “Test Bank” and the “complete” test or any other working bank
Considerations & Verifications	Retrieve `bank_account_id` and send it in the payout request Send all relevant customer details to improve conversion and be compliant

PO-02: Successful payout via API (* if applicable)

Scenario	Initiate a payout via API successfully.
Expected Outcome	Mention Brite as payout option to the customers Initiate the payout request via API Callbacks being handled by the merchant on the correct statuses Payout in the merchant system marked as successful Customer ends up on success screen / confirmation page
How to trigger	No specific things to consider here
Considerations & Verifications	Generate or reuse a `bank_account_id` and send it in the payout request Send all relevant customer details

PO-03: Unsuccessful payout with aborted status (*)

Scenario	Initiate a payout which gets aborted.
Expected Outcome	Initiate the payout request via API Callback `STATUS_ABORTED` from Brite being handled by the merchant Payout in the merchant system marked as failed Customer returns to payment selection step
How to trigger	Send an amount of `11.01` or `11.02` in the `transaction.create_withdrawal` API call
Considerations & Verifications	Handle the returned `error_code` properly and allow the customer to try again if possible

PO-04: Unsuccessful payout with failed status (*)

Scenario	Initiate a payout which fails.
Expected Outcome	Initiate the payout request via API Callback `STATUS_FAILED` from Brite being handled by the merchant Payout in the merchant system marked as failed Customer returns to payment selection step
How to trigger	Send an amount of `12.01` in the `transaction.create_withdrawal` API call
Considerations & Verifications	No error_code available; Let the customer chose a different option

PO-05: Delayed payout before it settles successfully

Scenario	Initiate a payout which gets delayed 5minutes before it settles successfully
Expected Outcome	Initiate the payout request via API Callbacks being handled by the merchant on the correct statuses Payout in the merchant system marked as “pending” & later on updated to “successful”
How to trigger	Send an amount of `13.01` in the `transaction.create_withdrawal` API call. The transaction remains in the state `COMPLETED` for 5 minutes before it transitions to state `SETTLED`.
Considerations & Verifications	This can happen in some markets with some banks but we recommend to build a logic independent on markets and banks

PO-06: Successful bank account creation (* if applicable)

Scenario	Initiate a creation of a `bank_account_id` via API successfully.
Expected Outcome	Initiate the bank account create request via API `bank_account_id` stored and used for subsequent payouts
How to trigger	No specific things to consider here
Considerations & Verifications	Generate or reuse a `bank_account_id` and send it in the payout request Send all relevant customer details

PO-07: Returned funds notification

Scenario	Initiate a payout which get sent back by the bank as undeliverable.
Expected Outcome	Initiate the payout request via API Callbacks being handled by the merchant on the correct statuses Payout in the merchant system marked as successful Customer ends up on success screen / confirmation page Returned funds callback is triggered Customer communication / Operational process being initiated by the merchant
How to trigger	Send an amount of `14.01` in the `transaction.create_withdrawal` API call. The transaction remains in the state `SETTLED` for 1 minutes before the callback to the “returned funds notification” is triggered.
Considerations & Verifications	Nothing specifically

Brite Play

In this section you can find the most important test cases to verify your Brite Play integration.

PL-01: Successful payment & registration (*)

Scenario	Initiate a payment, complete it successfully using the Brite Client and register the user.
Expected Outcome	Brite Client fully visible and accessible to the customer Callbacks being handled by the merchant on the correct statuses Payment in the merchant system market as successful Customer ends up on success screen / confirmation page Customer created on the merchant side
How to trigger	Select the “Test Bank” or any other working bank
Considerations & Verifications	Include approval_required parameter in the request and handle it correctly

PL-02: Aborted payment & registration (*)

Scenario	Initiate a payment and abort it using the Brite Client.
Expected Outcome	Brite Client fully visible and accessible to the customer Callback `STATUS_ABORTED` from Brite being handled by the merchant Payment in the merchant system marked as unsuccessful and no customer account has been created Customer returns to payment selection step
How to trigger	Select the “Test Bank” and pick an “aborted” test case or simply close the Brite Client by using the [x]
Considerations & Verifications	Handle the returned `error_code` properly and allow the customer to try again if possible

PL-03: Handle third-party payments (*)

Scenario	A payment is initiated by a customer who does not match the customer registered with the merchant.
Expected Outcome	Brite Client fully visible and accessible to the customer Callbacks being handled by the merchant on the correct statuses The Brite Client displays a message to the customer explaining that the customer must match the registered customer The payment status in the merchant system is marked as failed or rejected
How to trigger	Initiate the payment for the registered customer, ensuring their `customer_id` is included in the API request In the Brite Client, select the “Test Bank” and authenticate using credentials that belong to a different person
Considerations & Verifications	Correctly log the reason for the failed payment as a third-party payment attempt

Data Solutions

In this section you can find the most important test cases to verify your Brite Data Solutions integration.

DS-01: Successfully retrieve bank account information via Brite Client (*)

Scenario	Select a bank account via the Brite Client
Expected Outcome	Brite Client fully visible and accessible to the customer Callbacks being handled by the merchant on the correct statuses Bank Account information stored in the merchant system Customer ends up on success screen
How to trigger	Select the “Test Bank” and the “complete” test or any other working bank
Considerations & Verifications	The bank details we provide to the merchants are masked by default Store the `bank_account_id` and connect it to the user on your side

More test cases

In this section we list even more test cases which makes your integration even more stable and provide better experience to your customers.

MO-01: Closed Loop (for payment & payout) (*)

Scenario	Initiate a payment followed by a closed loop payout to the same customer
Expected Outcome	Payment via Brite Client made successfully as described in one of the “Successful payment” cases above Initiate a payout with the`bank_account_id` which was fetched from the initial payment
How to trigger	Use the bank_account_id from a previous payment
Considerations & Verifications	Nothing specifically

Production testing

When going live, Brite requires a production test to ensure that the integration you built on Sandbox also works fine on production from a UI/UX perspective but also technically. Please provide a screen recording of the testing of an end-to-end flow (both payment and payouts) to our Merchant Solutions team.

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

On this page