Testing
Testing and developing apps with Trustly's Open Banking Data API is made seamless and flexible through the availability of "Demo Banks" in the sandbox environment. These demo banks serve as tools for simulating diverse scenarios, including user errors and specific responses and data from banks. This overview provides insights into testing various aspects of the Open Banking Data API using the demo banks provided in the sandbox environment.
Overview
To access a Demo Bank, integrate the Trustly UI into your application and utilize the search bar to select the desired Demo Bank. Launching the Trustly UI within your app provides a user-friendly interface for interacting with the Demo Banks, allowing you to simulate real-world scenarios.
Usage
After selecting a demo bank from the Trustly UI, enter a username and password into the login form and follow the prompts to choose an account for the transaction. Entering keywords in the password field can be used to trigger a variety of simulated error cases or success cases with a variety of user account data and conditions present in subsequent event notifications and API calls.
Best Practices
When testing, avoid using the same generic username (e.g., test, user, demo) repeatedly across multiple transactions. Doing so repeatedly can cause delays in the authorization process.
Use unique, identifiable usernames for each test scenario (e.g., happy_path_test, johns_app_tuesday, or ineligible_user) to ensure smoother and faster test results.
Default Behavior
By default, any string will be accepted in the username and password fields and will simulate a basic success case and allow the selection of a checking or savings account attributed to an account holder named John Smith.
For routine “success” or “happy path” tests, use a unique but descriptive username such as {yourname}_test01 and three or more alphanumeric characters as the password. This ensures the fastest, most reliable response from the sandbox environment.
To manipulate the result of the bank authorization or the data associated with the connected account, see the sections below.
User Behavior & Errors
This section outlines keywords or phrases that act as simulation triggers when provided in the password field. Generating specific error scenarios will enable developers to proactively identify and address potential issues in their integrations.
Tips
- Password Keyphrases are not case sensitive. They are shown below using camel-case for readability purposes only.
- Usernames do not need to match the password. Unique usernames may result in faster authorization times in the Sandbox environment.
| Password Keyphrase | Simulated Use Case |
|---|---|
| NoEligibleAccounts | No eligible accounts found |
| LoginError | Wrong username or password |
| Unavailable | Bank Site cannot be reached. |
| AccountLocked | User’s account is locked. |
| BankAction | The bank requires the user to login and perform some action on their site. |
| ConnectError | There was a connection problem when accessing bank site |
| ConnectionError | There was a connection problem when accessing bank site |
| BlockedIpError | The bank indicates the caller IP was blocked |
| 2FA | Simulates as the bank requested a challenge question to the user. The question should be answered with the word 'error' if it's necessary to simulate a wrong credential. Otherwise, it should be anything to have a successful access. |
| ChallengeError | Simulates retry scenario, where the user provide wrong challenge (or anything that isn't userid or password) and is allowed to retry |
| InvalidAccountNumberSize | Connector returns a single account, but with account number shorter than the required. This is to test how the screen filters invalid accounts |
| InvalidAccountNumberSizeExtra | Connector returns two accounts. One with account number shorter (3 characters) than the required, the other with valid account number. |
| PartialAccountNumbers | Connector returns two accounts, however only with partial numbers. Simulating when for example the account is new and we still don't have statements to get full account number. |
| NoRouteCode | Regular flow with 2 accounts, but none with route code. This prompts a question for account location, where user must select where the account was open (from the given options) |
| InvalidRouteCode | Regular flow but simulates an invalid routing code (will simulate if ProfitStars returns invalid routing code) |
| WrongCredentials | Simulates retry scenario, where the user provide wrong challenge (or anything that isn't userid or password) and is allowed to retry |
| SiteRequestError | Simulates as if the bank couldn't process a particular request, allowing user to retry it |
| SessionTimeout | Simulates as if the user took too long to provide the requested information, since the bank session is already expired |
| PreLoginError | Simulates an error before the user gets authenticated |
| NotSupported | Simulates an user with no supported accounts |
| CreditCardsOnly | Returns an account only with credit card |
| AccountsWithNameAndAddress | Simulates an User with 2 accounts and each one with different names and addresses. |
| ManyInformation | Simulates a User with up to 10 accounts |
| AccountNotSupported | Simulates a User with an account not supported by our service (Chase Liquid, etc) |
| EmailMFA | Simulates as the bank requested the user to select an email address to send him a MFA token. |
| MixedMFA | Simulates as the bank requested the user to select an email address or a phone number to send him a MFA token. |
| AccountProfile | Returns accounts with Business, Personal, Other, Unknown and Null profiles. |
Conditional API Responses
By using specific usernames and passwords with the demo banks, the behavior and responses of the Open Banking Data API can be manipulated. By leveraging these credentials, you can also simulate the event notifications and data provided in responses to subsequent API calls.
| Password | Use Case |
|---|---|
| Balance{xxx} | Configures the account to have a balance of {xxx}. For example, Balance1000 will set the account balance to $1000. This is useful when testing transactions of larger dollar amounts. |
| ValidRouteCodeExtra | Connector returns 2 accounts whose route codes are larger than 9 digits: one of them has a valid route code as substring, so both accounts use the same valid code |
| InvalidRouteCodeExtra | Connector returns a single account whose route code is larger than 9 digits, but no valid route code is found as substring. Hence, the account is ignored |
| TimeoutError | In order to simulate a timeout, connector sleeps for at least a minute before actually doing anything. |
| NotEnoughFunds | Connector returns a single account with zero balance. This is similar to having no eligible accounts, but with different reason. |
| NotEnoughFundsExtra | Connector returns two accounts. One with zero balance, the other with a valid balance. |
| InvalidAccountNumberSize | Connector returns a single account, but with account number shorter than the required. This is to test how the screen filters invalid accounts |
| InvalidAccountNumberSizeExtra | Connector returns two accounts. One with account number shorter (3 characters) than the required, the other with valid account number. |
| PartialAccountNumbers | Connector returns two accounts, however only with partial numbers. Simulating when for example the account is new and we still don't have statements to get full account number. |
| OnlyPartials | PartialAccountNumbers + NoRouteCode |
| NoCustomer | Simulates as if FIC was not able to retrieve customer information |
| NoRouteCode | Regular flow with 2 accounts, but none with route code. This prompts a question for account location, where user must select where the account was open (from the given options) |
| InvalidRouteCode | Regular flow but simulates an invalid routing code (will simulate if ProfitStars returns invalid routing code) |
| AccountsWithNameAndAddress | Simulates an User with 2 accounts and each one with different names and addresses. |
| AmountNull | Simulates the Demo Checking Account returning an amount with null value. |
| AccNumberNull | Simulates the Demo Checking Account returning null value in the account number and routing number |
| AccFromUsername | Returns the account number from the pattern {prefix}_{accountnumber} on the username. Ex: To return an account with number 1234445 you can enter the username user1_1234445 or anotheruser_1234445. |
| RandomBalance | Returns account with random balance |
| RandomAccounts | Returns an account with random account number |
| LargeCustomerInfo | Returns account where customer information contains a large number of characters |
| FICWarning | It simply add to log engine fic-warning one example message to simulate the FIC Warning flow |
| RandomAccWithSleep | Returns random accounts with random account numbers and sleeps (in seconds) during the number passed in the password field |
| ExpiredSplitToken | Allows the transaction to be authorized but every refresh API call fails because of an expired split token. |
| NotEnoughFundsOnRefresh | Allows the transaction to be authorized but every refresh API call returns 0.00 as balance for all accounts. |
| Virtual | Return a valid Virtual Account Number (VAN) |
To simulate a delay, just enter Sleep as username and the number of seconds as the password, The connector will wait for at least the given number of seconds before presenting any results.
OAuth Demo Bank
Particularly useful for testing mobile app integrations, the OAuth Demo Bank simulates redirecting the user to an OAuth login page and the callback to your application. To handle OAuth login flows in your app see the OAuth Guide. Not all keywords listed in the sections above are supported by the OAuth Demo Bank, therefore it may be necessary to use both demo banks to ensure all scenarios are covered by your application.
Demo Bank App
Some banks that require OAuth login also support login via their official mobile application. Users often find logging in via their mobile application more convenient and secure as they can utilize any preconfigured biometric or other authentication systems. In order to ensure this user flow is also supported by your application, Trustly recommends using the accompanying OAuth Demo Bank mobile app for iOS and Android.
Device Simulator Testing
To use the app, simply download the latest versions here. Then drag and drop the appropriate .app or .apk file into the mobile device simulator in your development environment. Once the app has been installed, selecting the OAuth Demo Bank from the Trustly UI in your application should direct the user to login via the OAuth Demo Bank app.
Physical Device Testing
Download the latest version of the OAuth Demo Bank app to your test device and then proceed with your application testing. After launching the Trustly UI, select the "OAuth Demo Bank" and follow the button labeled "Go to Bank". This will open the newly installed OAuth Demo Bank app on your device.
Android app is available by invitation only. To request access please email us at [email protected] with the subject "Android Demo Bank App" and include all email addresses to be invited.
Product & Scenario Testing
Some Trustly products require specific use case testing and simulations, in most of those cases, additional details are provided in the appropriate tutorial.
Trustly ID
In order to simulate various identity verification outcomes and user profile examples, see the section for Testing in the Trustly ID tutorial.
Updated 6 months ago