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 username and password field will trigger a variety of error cases or success cases with a variety of user account data and conditions present in subsequent event notifications and API calls.

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. To manipulate the result of the bank authorization or the data associated with the connected account, see the sections below.

User Behavior & Errors

These keywords or phrases act as triggers, generating specific error scenarios and enable developers to proactively identify and address potential issues in their integrations. Some useful examples are found below:

Note: Keyphrases are cased for readability, input values are not case sensitive.

KeyphraseUse Case
NoEligibleAccountsNo eligible accounts found
LoginErrorWrong username or password
UnavailableBank Site cannot be reached.
AccountLockedUser’s account is locked.
BankActionThe bank requires the user to login and perform some action on their site.
ConnectErrorThere was a connection problem when accessing bank site
ConnectionErrorThere was a connection problem when accessing bank site
BlockedIpErrorThe bank indicates the caller IP was blocked
2FASimulates 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.
ChallengeErrorSimulates retry scenario, where the user provide wrong challenge (or anything that isn't userid or password) and is allowed to retry
InvalidAccountNumberSizeConnector returns a single account, but with account number shorter than the required. This is to test how the screen filters invalid accounts
InvalidAccountNumberSizeExtraConnector returns two accounts. One with account number shorter (3 characters) than the required, the other with valid account number.
PartialAccountNumbersConnector 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.
NoRouteCodeRegular 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)
InvalidRouteCodeRegular flow but simulates an invalid routing code (will simulate if ProfitStars returns invalid routing code)
WrongCredentialsSimulates retry scenario, where the user provide wrong challenge (or anything that isn't userid or password) and is allowed to retry
SiteRequestErrorSimulates as if the bank couldn't process a particular request, allowing user to retry it
SessionTimeoutSimulates as if the user took too long to provide the requested information, since the bank session is already expired
PreLoginErrorSimulates an error before the user gets authenticated
NotSupportedSimulates an user with no supported accounts
CreditCardsOnlyReturns an account only with credit card
AccountsWithNameAndAddressSimulates an User with 2 accounts and each one with different names and addresses.
ManyInformationSimulates a User with up to 10 accounts
AccountNotSupportedSimulates a User with an account not supported by our service (Chase Liquid, etc)
EmailMFASimulates as the bank requested the user to select an email address to send him a MFA token.
MixedMFASimulates as the bank requested the user to select an email address or a phone number to send him a MFA token.
AccountProfileReturns 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.

PasswordUse 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.
ValidRouteCodeExtraConnector 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
InvalidRouteCodeExtraConnector 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
TimeoutErrorIn order to simulate a timeout, connector sleeps for at least a minute before actually doing anything.
NotEnoughFundsConnector returns a single account with zero balance. This is similar to having no eligible accounts, but with different reason.
NotEnoughFundsExtraConnector returns two accounts. One with zero balance, the other with a valid balance.
InvalidAccountNumberSizeConnector returns a single account, but with account number shorter than the required. This is to test how the screen filters invalid accounts
InvalidAccountNumberSizeExtraConnector returns two accounts. One with account number shorter (3 characters) than the required, the other with valid account number.
PartialAccountNumbersConnector 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.
OnlyPartialsPartialAccountNumbers + NoRouteCode
NoCustomerSimulates as if FIC was not able to retrieve customer information
NoRouteCodeRegular 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)
InvalidRouteCodeRegular flow but simulates an invalid routing code (will simulate if ProfitStars returns invalid routing code)
AccountsWithNameAndAddressSimulates an User with 2 accounts and each one with different names and addresses.
AmountNullSimulates the Demo Checking Account returning an amount with null value.
AccNumberNullSimulates the Demo Checking Account returning null value in the account number and routing number
AccFromUsernameReturns 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.
RandomBalanceReturns account with random balance
RandomAccountsReturns an account with random account number
LargeCustomerInfoReturns account where customer information contains a large number of characters
FICWarningIt simply add to log engine fic-warning one example message to simulate the FIC Warning flow
RandomAccWithSleepReturns random accounts with random account numbers and sleeps (in seconds) during the number passed in the password field
ExpiredSplitTokenAllows the transaction to be authorized but every refresh API call fails because of an expired split token.
NotEnoughFundsOnRefreshAllows the transaction to be authorized but every refresh API call returns 0.00 as balance for all accounts.
VirtualReturn 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.

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.

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.