Testing in the Sandbox Environment

This guide demonstrates how to create Accounts and Users / UserIntents with specific states so that you can test a wide range of scenarios that an end-user may encounter.

Connecting a Bank Account via Plaid

If you are using Astra's direct or managed integration with Plaid, you can guide the end-user to connect a bank account through Plaid Link.

After the authorization step, the OAuth module will provide you with a screen for connecting bank accounts. Select the "Connect New Bank" button and continue to select a bank from list of available options. For this example, we'll use Chase. You'll be prompted to enter your account user name and password. Enter the following test credentials:

  • Username: user_good
  • Password: pass_good

For additional test cases per institution, including Multi-factor Authentication please refer to Plaid's Sandbox Test Credentials.

Testing User/UserIntent States

Quickstart with Examples

To jumpstart integration testing, we have provided example payloads that can be leveraged to create user intents that will land in specific statuses.

User Intent Examples

User Intent Examples

When creating a user intent you can select one of the following examples which will pre-populate the parameters with values that will produce the desired status:

Example NameUser Intent Status Result
Example Approved User Intentapproved
Example Rejected User Intentrejected
Example Retry Status User Intentretry
Example Document Status User Intentdocument

📘

Note when using one of the examples above, you must provide your own values where specified. For example, include your email where you see YOUR_EMAIL, and a real testable phone number where you see YOUR_PHONE. Please refer to Further Details for specific information on repeated testing using the same email and phone number.

Further Details

When Astra processes a User/UserIntent profile for security and KYC assessment, a resulting User Status for the User/UserIntent will be applied. To test these scenarios, you can use the following options for the User/UserIntent details (phone, first_name, ip_address, etc.)

📘

Note that you may only attempt to create 3 UserIntents per email address. If you reach this limit while creating UserIntents in your Sandbox Environment, you will receive an error.

📘

Note that you may create as many UserIntents with a single phone number as you'd like. However, once this UserIntent becomes converted_to_user and a User profile is created, this phone number cannot be used for another User profile. If you attempt to authenticate with a phone number that is already associated with a User profile, you'll automatically be logged into the User profile that the phone number is associated with. To free up this phone number, you'll need to delete the User profile via the User tab in your Developer Dashboard.

📘

There is a “logout” button for rejected user sessions in Sandbox Environments so you can more easily test different User statuses. This enables you to quickly clear a persisting rejected user session, whether intentionally or unintentionally created. Note that this feature is not available in production.

Phone Number

The UserIntent object as well as the Authentication step in our OAuth Module require a US-based phone number that can receive SMS text messages. For testing purposes, we recommend having more than one US-based phone number available as this will make it easier for you and your team to manage test Users. If you do not have more than one US-based phone number, we recommend creating virtual US-based phone numbers via services such as Google Voice or Twilio. These virtual numbers have the abilty to recieve SMS messages.

It's important to note that due to persisting User sessions, if you do use the same phone number for two different Users/UserIntents, it is likely that you'll be logged in as the previous User/UserIntent upon authenticating.

If you are unable to receive SMS messages from Astra, check the following:

  • Is your phone a US based mobile phone capable of receiving SMS messages? Landlines cannot be used in Sandbox or Production as SMS messages can only be delivered via Text.
  • Does the phone number you are authenticating with match the phone number of the UserIntent? These two numbers must match.
  • Are you located outside of the United States? If yes, we recommend that you use a virtual US based phone number with an IP address that is within the United States.
  • Are you on a VPN? If so, we recommend you turn off your VPN.
  • Are your Chrome Settings blocking 3rd party cookies? If yes, we recommend adjusting your settings.

Scenario 01: Approved

  • Create a UserIntent with any phone number, except for phone number in Scenario 02.
  • The UserIntent status will be approved
  • Note: approved means the User/UserIntent is in good standing

Scenario 02: Rejected

  • Create a UserIntent with the following phone number: 1-202-555-1111
  • The UserIntent status will be rejected
  • Note: This phone number cannot be used for authenticating. There is no corresponding SMS / OTP for this phone number and it can only be used to create a rejected UserIntent.
  • Note: rejected means the User/UserIntent failed our security and/or KYC check and the end-user has been rejected from using the Astra Platform

📘

Note that you can also create a rejected status for a UserIntent if you use the following DOB: 1970-01-01

First Name

Scenario 01: Approved

  • Create a UserIntent with any first name, except for the two outlined in the scenarios below
  • This will result in a successful authorization and the end-user will be able to proceed with actions such as connecting bank accounts and creating routines and transfers

Scenario 02: Retry

  • Create a UserIntent with the following first name: retry
  • Once this UserIntent is submitted, the end-user will be brought to a Retry screen, which will prompt them to provide additional profile information to verify their identify, such as their first name, last name, dob, ssn, and address
  • OAuth URL: https://app-sandbox.astra.finance/verify/personal
  • Note: additional attempts that fail may result in requiring the user to provide documentation or user suspension

Scenario 03: Document

  • Create a UserIntent with the following first name: document
  • Once this UserIntent is submitted and the end-user attempts to Authorize, they will be brought to a Document screen, which will prompt them to upload an official photo ID (Driver License, ID Card, or Passport) to aid in validating their identity
  • Specify the document type and then choose a file to upload. For testing purposes, any test .jpeg, .jpg, .png that are less than 10MB in size and in color will suffice. If additional business documentation is required, they can be uploaded in a .pdf file format
  • OAuth URL: https://app-sandbox.astra.finance/verify/document

IP Address

Scenario 01: Approved

  • Create a UserIntent with any IP Address, except for the three outlined in Scenario 02.
  • We recommend that you use your real IP Address, which can be found here: https://whatismyipaddress.com/
  • This will result in a successful authorization, which will result in an approved user intent status and enable the end-user to proceed with the remaining OAuth steps.

Scenario 02: Rejected

  • Create a UserIntent with one of the following IP Addresses listed below. Each of these test IP addresses will trigger a response, which will result in a rejected user intent status and prevent the end-user from proceeding with the remaining OAuth steps.
    • 127.0.0.1
    • 127.0.0.2
    • 127.0.0.3

📘

Note that you can also create a rejected status for a UserIntent if you use the following DOB:1970-01-01

Document Submission

As a part of Astra's KYC process, certain Users / UserIntents may be placed in a document status, requiring the submission of a government-issued ID. Accepted forms of identification include licenses, ID cards, and passports. Below, you'll find example license documents for triggering approved or failed states for document uploads. To learn more about document uploads, please refer to the chapter on Users and reference the Documents section.

📘

Note that when you download either of these images, the size, format, and name of the image must remain unchanged to trigger the desired response.

Sample Document Approved Image

test-document-upload-success.png

test-document-upload-success.png

Sample Document Rejected Image

test-document-upload-fail.png

test-document-upload-fail.png

Deleting Users

Our Sandbox Environment is designed to be as close to production as possible. This means certain actions in the Sandbox environment are not as flexible as one might expect. For example, you can only use one unique phone number per user, since in production, this relationship is one to one.

For testing purposes, we do allow you to delete users in the Sandbox Environment, which is something you cannot do in production.

To delete a user, navigate to the Users table, locate the user you wish to delete, and select the delete (trash can) icon. Deleting a user will delete all of the user's data from the system.

However, there are several reasons why you may not be able to delete a user. If you are unable to delete a user, review the following information:

  • Refresh your dashboard: your developer dashboard has an authorization token which periodically expires. Try refreshing the User table and try again.
  • Pending Transaction: if a user has any pending transactions, the transactions will need to process before you are able to delete the user. Locate the user and navigate to the Transfer table to see if any transactions are pending.
  • Different OAuth Client: If a Sandbox user also belongs to different OAuth Client (a different Sandbox Env.), only the original OAuth Client who added this user has the ability to delete them. If a user belongs to a different OAuth Client, you'll receive the following error message when attempting to delete them: "User was not created by provided client". If this happens, consult with your teammates to see if someone else on the team created another sandbox environment.

Issuing Test Debit Cards

If you are integrating Astra's Instant Funding solution, you may create client-issued debit cards via our POST /v1/cards endpoint using a test BIN provided by your card issuer. You'll need to reach out to your designated Astra Integration contact to register the BIN with your client. You may also leverage the below example debit cards for the same purpose or to test connecting an external debit card via our SDK.

Visa Debit Card Example

  • Type: Visa
  • Card BIN: 400005
  • Card #: 4000056655665556
  • CVC: Any 3 digits
  • Exp. Date: Any future date, e.g. 02/25

Mastercard Debit Card Example

  • Type: Mastercard
  • Card BIN: 520082
  • Card #: 5200828282828210
  • CVC: Any 3 digits
  • Exp. Date: Any future date, e.g. 02/25